That's a good point, thank you. I think I would lean towards making this an end-entity only requirement until we've thought through the details for other certificates.
We've been burned by this before (requirements for OCSP related certificates were under-specified during the SHA1->SHA2 transition). -Tim > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert....@lists.mozilla.org] On Behalf Of Jakob > Bohm via dev-security-policy > Sent: Wednesday, January 24, 2018 12:11 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: GlobalSign certificate with far-future notBefore > > Please also consider the practice of having an off-line CA (typically a > root) pre-issue CRLs, OCSP responses, intermediary CAs and OCSP responder > certificates for the period until the next root-key-usage ceremony. > > This practice will naturally involve forward-dating of all of these items. > > On 24/01/2018 19:03, Tim Hollebeek wrote: > > With respect to the action item, I'll add it to next week's VWG agenda. > > > > -Tim > > > >> -----Original Message----- > >> From: Doug Beattie [mailto:doug.beat...@globalsign.com] > >> Sent: Wednesday, January 24, 2018 11:02 AM > >> To: Tim Hollebeek <tim.holleb...@digicert.com>; Rob Stradling > >> <rob.stradl...@comodo.com>; Jonathan Rudenberg > >> <jonat...@titanous.com>; mozilla-dev-security-policy > > <mozilla-dev-security- > >> pol...@lists.mozilla.org> > >> Subject: RE: GlobalSign certificate with far-future notBefore > >> > >> Can we consider this case closed with the action that the VWG will > >> propose > > a > >> ballot that addresses pre and postdating certificates? > >> > >> Doug > >> > >>> -----Original Message----- > >>> From: dev-security-policy [mailto:dev-security-policy- > >>> bounces+doug.beattie=globalsign....@lists.mozilla.org] On Behalf Of > >>> bounces+Tim > >>> Hollebeek via dev-security-policy > >>> Sent: Wednesday, January 24, 2018 11:49 AM > >>> To: Rob Stradling <rob.stradl...@comodo.com>; Jonathan Rudenberg > >>> <jonat...@titanous.com>; mozilla-dev-security-policy > >>> <mozilla-dev-security- pol...@lists.mozilla.org> > >>> Subject: RE: GlobalSign certificate with far-future notBefore > >>> > >>> > >>>>> This incident makes me think that two changes should be made: > >>>>> > >>>>> 1) The Root Store Policy should explicitly ban forward and > >>>>> back-dating > >>> the > >>>> notBefore date. > >>>> > >>>> I think it would be reasonable and sensible to permit back-dating > >>>> insofar > >>> as it is > >>>> deemed necessary to accommodate client-side clock-skew. > >>> > >>> Indeed. This was discussed at a previous Face to Face meeting, and > >>> it was generally agreed that a requirement that the notBefore date > >>> be within +-1 week of issuance would not be unreasonable. > >>> > >>> The most common practice is backdating by a few days for the reason > >>> Rob mentioned. > >>> > >>> -Tim > > > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. > https://clicktime.symantec.com/a/1/w3EBVE2BUeC8MLN64pffPHe_ALFM8rW > FtYSZz0xKgUQ=?d=0cp29hFCr5Urpdzx- > Mfh962Yi0YHT8LIyoz29Y64zpxMuZ5acgO3veRerXVznnhS8okM5L2iK7Cfn- > QM7GjRJRKhm9VLVunmzxGFY3ZEBLSt1WL9J_pv6EL3P9LWZ2hVLFetfoezYOko > 0x-zSINeQfcGEdm1mIF6ToqUHA6FT-PImc0BUUM0RYQrHLClDEtxX9- > CxA7_Q5Hi- > dY_G2jx0s6sq6K5ezLrkKQ3gAzBEza0Zh3b1wW58ngKVU5vpeJvvlR_imWg- > ZYQ3krbn6QKzJDxbo- > uRsICLMequfXT4i7CTjcmzrWZ6i4wFJ_YwP7494F9dwa63QJ04UWu1VpygY_FO > 9yp5t7UHK6F0Gm6dZv- > Dbs0rvQeyRhJcD76INT9CIRVg0NYqzetnqGr_FXERUBlZySFZ5JHbXWLIq7YkZCEB > 0bzP5csI62QM1CdL8dKJuEkEICGDDorGrSz8TIvahk%3D&u=https%3A%2F%2Fw > ww.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public > discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/kC_2afz6- > xbFBgJiUlml8gw9eo6BNgViMVS2LeeuzvE=?d=0cp29hFCr5Urpdzx- > Mfh962Yi0YHT8LIyoz29Y64zpxMuZ5acgO3veRerXVznnhS8okM5L2iK7Cfn- > QM7GjRJRKhm9VLVunmzxGFY3ZEBLSt1WL9J_pv6EL3P9LWZ2hVLFetfoezYOko > 0x-zSINeQfcGEdm1mIF6ToqUHA6FT-PImc0BUUM0RYQrHLClDEtxX9- > CxA7_Q5Hi- > dY_G2jx0s6sq6K5ezLrkKQ3gAzBEza0Zh3b1wW58ngKVU5vpeJvvlR_imWg- > ZYQ3krbn6QKzJDxbo- > uRsICLMequfXT4i7CTjcmzrWZ6i4wFJ_YwP7494F9dwa63QJ04UWu1VpygY_FO > 9yp5t7UHK6F0Gm6dZv- > Dbs0rvQeyRhJcD76INT9CIRVg0NYqzetnqGr_FXERUBlZySFZ5JHbXWLIq7YkZCEB > 0bzP5csI62QM1CdL8dKJuEkEICGDDorGrSz8TIvahk%3D&u=https%3A%2F%2Fli > sts.mozilla.org%2Flistinfo%2Fdev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy