Yes, if we wanted to go to 13 months quickly, we would have gone directly there. Getting to 13 months quickly is not a goal. That’s not having it both ways, that having an understanding of how the ecosystem actually works.
The majority of the CAB forum, and not just CAs, but also many browsers, believe this sort of change so quickly after the most recent change, which came very quickly after the change before that, would be unnecessarily disruptive and unhelpful to the ecosystem. -Tim From: Alex Gaynor [mailto:agay...@mozilla.com] Sent: Monday, April 2, 2018 2:51 PM To: Tim Hollebeek <tim.holleb...@digicert.com> Cc: MozPol <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: 825 days success and future progress! Hi Tim, I'd have suggested an even shorter period, say 13 months, except I anticipated CAs would object that it was too great a change too suddenly, precisely as they did when this subject was last discussed! While I appreciate that changing BRs can be difficult for customer communications, the fact that we are doing this in multiple steps instead of in one fell swoop is a result of CAs saying such a big leap was too disruptive. Frankly, you can't have it both ways. Alex On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek <tim.holleb...@digicert.com <mailto:tim.holleb...@digicert.com> > wrote: 18 months is not significantly different from 825 days. So there's really no benefit. People have to stop wanting to constantly change the max validity period. It's difficult enough to communicate these changes to consumers and customers, and it really drives them nuts. I can only imagine what a non-integral number of years will do to various company's planning and budgeting processes. I would propose, instead, a minimum one year moratorium on proposals to change the max validity period after the previous change to the max validity period goes into effect. That would make much more sense. -Tim > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > <mailto:dev-security-policy-> > bounces+tim.hollebeek=digicert....@lists.mozilla.org > <mailto:digicert....@lists.mozilla.org> ] On Behalf Of Alex > Gaynor via dev-security-policy > Sent: Monday, April 2, 2018 1:07 PM > To: MozPol <mozilla-dev-security-pol...@lists.mozilla.org > <mailto:mozilla-dev-security-pol...@lists.mozilla.org> > > Subject: 825 days success and future progress! > > Afternoon all! > > A month ago a new BR rule went into effect, putting a maximum validity period > of 825 days on newly issued certificates. > > Truthfully, I was expecting tons of CAs to screw up, forget to implement it, or > have no technical controls, and there to be tons of miss-issuance. > To me delight, the results have been pretty good: > https://crt.sh/?zlint=1081 > <https://crt.sh/?zlint=1081&minNotBefore=2018-03-01> &minNotBefore=2018-03-01 > the majority of > violations have been from the US Government (whose PKI isn't remotely BR > compliant, nor trusted by Mozilla). > > In light of this incredible success, I think it's time to begin a discussion on what > the next in this chain is. While obviously actually encoding this in the BRs will > be a function of the CABF, as mdsp is the premier public discussion forum for > the PKI, I wanted to start here. > > I propose that our next target should be a max validity period of 18 months > (~550 days), starting in ~6 months from now. > > The value of shorter-lived certificates has been discussed many times, but to > rehash: They afford the ecosystem significantly more agility, by allowing us to > remove mistakes in shorter periods of time without breaking valid certificates. > It also encourages subscribers to adopt more automation, which further helps > with agility. > > Alex > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> > https://lists.mozilla.org/listinfo/dev-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
