On Wed, Jan 24, 2018 at 6:52 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> We don't allow customers to set the notBefore date into the past. > > And regarding the Mozilla checks for > https://bugzilla.mozilla.org/show_bug.cgi?id=908125, perhaps the > "notBefore" date used in the check should be the earlier of the certificate > NotBefore or the date the included SCT was created. This has a variety of both technical problems (e.g. when logs are disqualified) and policy problems (using CT as a trusted timestamping service rather than disclosure) that makes this, as a practical matter, non-viable. I don't know how Chrome would handle this certificate, but if it marks it > as invalid, it would be good to know so we can relay this to customers that > have set the notBefore date after March 1st. As of Chrome 66, It will be rejected as an invalid certificate and users will be forced to click through. I would have included this in Chrome 65 or earlier, but in general, I try to land enforcement code in a way that it rolls out approximate to the transition date, in the event of any issues. The use of the notBefore as a proxy for issuance date has been a behavior of a Chrome for nearly 5 years now, and was originally behavior contributed by Opera, which had similar checks even longer. In general, a certificate with a given notBefore is minimally expected to comply with all of the policies as of that date. NotBefore backdating attempts to circumvent that, which is problematic, but notBefore forward-dating runs the risk that the certificate will be unusable at the time it is valid, because it does not comply with the policies of its validity period. > > Doug > > > -----Original Message----- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+doug.beattie=globalsign....@lists.mozilla.org] On Behalf Of > Gervase > > Markham via dev-security-policy > > Sent: Wednesday, January 24, 2018 5:05 AM > > To: David E. Ross <nobody@nowhere.invalid>; mozilla-dev-security- > > pol...@lists.mozilla.org > > Subject: Re: GlobalSign certificate with far-future notBefore > > > > On 24/01/18 04:57, David E. Ross wrote: > > > I am not sure about prohibiting forward-dating the notBefore date. I > > > can picture a situation where an existing site certificate is going to > > > expire. The site's administration decides to obtain a new certificate > > > from a different certification authority. Because of various > > > administrative processes, the switch to the new site certificate > > > cannot be accomplished quickly (e.g., moving the server); so they > > > establish a notBefore date that is a month in the future. > > > > Why would that be _necessary_? What would go wrong if the cert was cut > > with a notBefore of the current date, apart from the fact that they'd > need to > > renew it a month earlier? > > > > Gerv > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
