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- > bounces+tim.hollebeek=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> > 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&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 > 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
