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

Attachment: 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

Reply via email to