By practical means in an IT department of a large company, it is always easier to discuss about money, if such a plan is written down in a standard that can be referenced and shown (like the BRGs) than in the depths of the archive of a mailing list. So if there is a plan, I would like to suggest to add it to the standard.
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<https://siemens.com/ingenuityforlife> [www.siemens.com/ingenuityforlife] From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Montag, 2. April 2018 21:16 To: Buschart, Rufus (GS IT HR 7 4) Cc: Alex Gaynor; Tim Hollebeek; MozPol Subject: Re: 825 days success and future progress! 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<mailto: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<mailto:rufus.busch...@siemens.com> www.siemens.com/ingenuityforlife<http://www.siemens.com/ingenuityforlife> -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+rufus.buschart<mailto:dev-security-policy-bounces%2Brufus.buschart>=siemens....@lists.mozilla.org<mailto: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<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 > > bounces+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&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 > _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
