In past discussions, the proposal was 1 year to 2 years, and 1 year to 1 year after that. We're now at the midway point, so it seems appropriate to discuss how to get shorter.
On Mon, Apr 2, 2018 at 3:11 PM, Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi all! > > From the discussions we had in the last months internally at Siemens IT > department about the 825 days rule, I can report that our server operators > need a long term roadmap in this issue. The main point here is, that there > are a hell lot of applications out there that don't (easily) support > automated SSL/TLS certificate replacement (e.g. some SAP systems). To > enable those systems to support automated certificate replacement a > significant amount of money will need to be invested. To get approval for > such an investment, one needs to calculate a business case. And this > business case looks obviously much different, if a certificate on a system > needs to be replaced every 825 days, 731 days, 366 days or even 90 days. So > I would like to propose not to start discuss about the next reduction step > now, but agree on a clear (semi-)final goal (e.g. max life span of a > certificate is 45 days in 2023 (five years from now)) and then agree on the > intermediate steps to reach this goal. > > With best regards, > Rufus Buschart > > Siemens AG > GS IT HR 7 4 > Hugo-Junkers-Str. 9 > 90411 Nuernberg, Germany > Tel.: +49 1522 2894134 > mailto:rufus.busch...@siemens.com > > www.siemens.com/ingenuityforlife > > > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+rufus.buschart=siemens....@lists.mozilla.org] On Behalf Of Alex > Gaynor via dev-security-policy > Sent: Montag, 2. April 2018 20:51 > To: Tim Hollebeek > Cc: MozPol > 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> > 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- > > > bounces+tim.hollebeek=digicert....@lists.mozilla.org] On Behalf Of > > > bounces+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 > > > _______________________________________________ > 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
