With respect to the action item, I'll add it to next week's VWG agenda. -Tim
> -----Original Message----- > From: Doug Beattie [mailto:[email protected]] > Sent: Wednesday, January 24, 2018 11:02 AM > To: Tim Hollebeek <[email protected]>; Rob Stradling > <[email protected]>; Jonathan Rudenberg > <[email protected]>; mozilla-dev-security-policy <mozilla-dev-security- > [email protected]> > 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- > > [email protected]] On Behalf Of > > bounces+Tim > > Hollebeek via dev-security-policy > > Sent: Wednesday, January 24, 2018 11:49 AM > > To: Rob Stradling <[email protected]>; Jonathan Rudenberg > > <[email protected]>; mozilla-dev-security-policy > > <mozilla-dev-security- [email protected]> > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
