Re: 825 days success and future progress!
On 04/04/2018 04:16, Matt Palmer wrote: On Tue, Apr 03, 2018 at 03:16:53AM +0200, Jakob Bohm via dev-security-policy wrote: On 03/04/2018 02:35, Kurt Roeckx wrote: On Tue, Apr 03, 2018 at 02:11:07AM +0200, Jakob Bohm via dev-security-policy wrote: seems to be mostly justified as a poor workaround for the browsers and certificate libraries not properly implementing reliable revocation checks. The problem is not in the libraries, or even the applications making use of them, it's that actually trying to check them is not reliable. There are just too many cases where trying to check it results in an error. OCSP stapling should at least help with this. We should really encourage people to use this, and have software enable this by default. According to ssl-pulse 31% of the sites enable it. There might also be library or application bugs. At least firefox for me is annoying that if it for whatever reasons fails, it says it's an internal server error (which as far as I know is never the case), and then even doesn't seem to retry it and just give that same error again. Most of the remaining 69% of servers run software libraries that don't include a good enough OCSP stapling implementation. This includes the omnipresent OpenSSL 1.0.2. Automatically scheduled CRL downloads, though currently bandwidth inefficient, would be much more reliable, as they are done and retried in advance, with typically at least a day to recover from server glitches. Also, CRL download servers are much more reliable than OCSP servers as they don't need to run special software with high CPU capacity and a secure private key, any basic redundant HTTP server can do the job. Delta CRLs, with some systematic enhancements, could further speedup CRL downloads to a viable bandwidth level. Bandwidth, whilst a big problem (not everyone has phat pipes, nor even *always connected* pipes), isn't the only problem with CRLs. You also need to be able to store them all, and generate and store the indexes to make searching them sufficiently fast. Oh, and because CRL distribution points aren't embedded in the root certificates, you're still going to stumble across certs that you don't have the CRL for, which kills the "oh you'll definitely have all the CRLs in advance" argument, bringing us back to the same problem we've already got, that of "what do you do when you can't access timely revocation information?" while *also* having all the other problems of CRLs. But the problem of a never-before or not-recently seen CRL will be a lot rarer than the problem of a not-recently queried OCSP status, thus representing a much smaller risk of either maliciously blocked checking causing a fail open or unexpected damage from failing closed. As for indexing, some requirements above and beyond the current RFCs could make that a lot easier, for example: - CRLs must be sorted by certificate serial number (DER sorting rules), alternatively security libraries (like NSS) could create an index file for each cached CRL. - A combination of issuing CA and actual certificate signing algorithm must have exactly one CRL, no sharding etc. allowed. - Delta CRLs must contain enough data to allow the client to deterministically reconstruct the latest CRL without actually downloading it. - CRL URLs must be listed in CCADB allowing participating browsers to distribute an initial preload list, further reducing the frequency of needing an uncached CRL. Alternatively define some other way for clients to enumerate relevant CRLs. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 825 days success and future progress!
On Tue, Apr 03, 2018 at 03:16:53AM +0200, Jakob Bohm via dev-security-policy wrote: > On 03/04/2018 02:35, Kurt Roeckx wrote: > > On Tue, Apr 03, 2018 at 02:11:07AM +0200, Jakob Bohm via > > dev-security-policy wrote: > > > seems > > > to be mostly justified as a poor workaround for the browsers and > > > certificate libraries not properly implementing reliable revocation > > > checks. > > > > The problem is not in the libraries, or even the applications > > making use of them, it's that actually trying to check them is not > > reliable. There are just too many cases where trying to check it > > results in an error. > > > > OCSP stapling should at least help with this. We should really > > encourage people to use this, and have software enable this by > > default. According to ssl-pulse 31% of the sites enable it. > > > > There might also be library or application bugs. At least firefox > > for me is annoying that if it for whatever reasons fails, it says > > it's an internal server error (which as far as I know is never the > > case), and then even doesn't seem to retry it and just give that > > same error again. > > Most of the remaining 69% of servers run software libraries that don't > include a good enough OCSP stapling implementation. This includes the > omnipresent OpenSSL 1.0.2. > > Automatically scheduled CRL downloads, though currently bandwidth > inefficient, would be much more reliable, as they are done and retried > in advance, with typically at least a day to recover from server > glitches. Also, CRL download servers are much more reliable than OCSP > servers as they don't need to run special software with high CPU > capacity and a secure private key, any basic redundant HTTP server can > do the job. > > Delta CRLs, with some systematic enhancements, could further speedup CRL > downloads to a viable bandwidth level. Bandwidth, whilst a big problem (not everyone has phat pipes, nor even *always connected* pipes), isn't the only problem with CRLs. You also need to be able to store them all, and generate and store the indexes to make searching them sufficiently fast. Oh, and because CRL distribution points aren't embedded in the root certificates, you're still going to stumble across certs that you don't have the CRL for, which kills the "oh you'll definitely have all the CRLs in advance" argument, bringing us back to the same problem we've already got, that of "what do you do when you can't access timely revocation information?" while *also* having all the other problems of CRLs. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 825 days success and future progress!
On 03/04/2018 02:35, Kurt Roeckx wrote: On Tue, Apr 03, 2018 at 02:11:07AM +0200, Jakob Bohm via dev-security-policy wrote: seems to be mostly justified as a poor workaround for the browsers and certificate libraries not properly implementing reliable revocation checks. The problem is not in the libraries, or even the applications making use of them, it's that actually trying to check them is not reliable. There are just too many cases where trying to check it results in an error. OCSP stapling should at least help with this. We should really encourage people to use this, and have software enable this by default. According to ssl-pulse 31% of the sites enable it. There might also be library or application bugs. At least firefox for me is annoying that if it for whatever reasons fails, it says it's an internal server error (which as far as I know is never the case), and then even doesn't seem to retry it and just give that same error again. Most of the remaining 69% of servers run software libraries that don't include a good enough OCSP stapling implementation. This includes the omnipresent OpenSSL 1.0.2. Automatically scheduled CRL downloads, though currently bandwidth inefficient, would be much more reliable, as they are done and retried in advance, with typically at least a day to recover from server glitches. Also, CRL download servers are much more reliable than OCSP servers as they don't need to run special software with high CPU capacity and a secure private key, any basic redundant HTTP server can do the job. Delta CRLs, with some systematic enhancements, could further speedup CRL downloads to a viable bandwidth level. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 825 days success and future progress!
On Tue, Apr 03, 2018 at 02:11:07AM +0200, Jakob Bohm via dev-security-policy wrote: > seems > to be mostly justified as a poor workaround for the browsers and > certificate libraries not properly implementing reliable revocation > checks. The problem is not in the libraries, or even the applications making use of them, it's that actually trying to check them is not reliable. There are just too many cases where trying to check it results in an error. OCSP stapling should at least help with this. We should really encourage people to use this, and have software enable this by default. According to ssl-pulse 31% of the sites enable it. There might also be library or application bugs. At least firefox for me is annoying that if it for whatever reasons fails, it says it's an internal server error (which as far as I know is never the case), and then even doesn't seem to retry it and just give that same error again. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 825 days success and future progress!
Furthermore in IT departments of smaller companies, setting up new automations or upgrading otherwise functioning systems to ones that include automation is much harder than it is for a mastodon like Siemens. The main arguing for ever shorter validity periods seems to come from very few mega-companies with 100% automated computer systems, and seems to be mostly justified as a poor workaround for the browsers and certificate libraries not properly implementing reliable revocation checks. From a small IT depeartment perspective, a much more usable further plan would be: 1. NO MORE REDUCTIONS IN MAX LIFETIME. 2. A rule that CAs periodically check for conflicting whois changes or other changes in underlying public records, and revoke affected certificates with a reasonable warning to the affected entities (just in case the detected change is erroneous and the certificate contents is still true). 3. A *requirement* that participating browsers implement fully working revocation checks for both OCSP and CRL cases. 4. Work to create improved (more efficient) privacy preserving revocation protocols, such as redundant delta CRLs over HTTPS. 5. Once revocation is actually working industry wide, work to reintroduce certificate lifetimes comparable to domain registration periods (1, 2, 3, 5 years). On 02/04/2018 21:20, Buschart, Rufus wrote: 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 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 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 co
RE: 825 days success and future progress!
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 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 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 > > 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
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> 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 > 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 > > > 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 propos
Re: 825 days success and future progress!
Tim, I think it's far more productive to help clarify misunderstandings. For example, based on your statement, it sounds like you're actually opposed to any change - and the objection that it's not "significantly different" is simply a misleading objection. If that's not the case, then can you please explain why you raise it as an objection and what constitutes a change that would be "significantly different" such that you'd support. On Mon, Apr 2, 2018 at 2:59 PM, Tim Hollebeek wrote: > Ryan, I’ve warned you several times, do not put words in my mouth. I > support the status quo, for now. We can talk about future changes in the > future. > > > > -Tim > > > > *From:* Ryan Sleevi [mailto:r...@sleevi.com] > *Sent:* Monday, April 2, 2018 2:58 PM > *To:* Tim Hollebeek > *Cc:* Alex Gaynor ; MozPol < > mozilla-dev-security-pol...@lists.mozilla.org> > *Subject:* Re: 825 days success and future progress! > > > > > > > > On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > 18 months is not significantly different from 825 days. So there's really > no benefit. > > > > So it sounds like you're supportive of 13 months, then, so that we arrive > at an effective and meaningful maximum. > > > > People have to stop wanting to constantly change the max validity period. > > > > This is an entirely unproductive line of reasoning. The only reason that > we're at a point of discussing incremental approaches seems to be because > CAs resisted making meaningful steps all at once, and instead preferred a > phase-in, like SHA-1. Proposals were put forward to make it a significant > and meaningful difference, and there appeared to be wide browser support in > spirit - and the only question being about the timing of the phase in. > Thus, it seems reasonable to begin discussing how to approach that - and it > doesn't seem productive to suggest the community should not discuss this. > > > > 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. > > > > So this argues in favor of 13 months, rather than 18 months. The > communication difficulties are not expanded upon here, but it seems that if > CAs spent more time investing in interoperable automation, these > communication issues would evaporate, because they'd no longer be an issue. > > > > 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. > > > > I'm sure to a CA it makes sense, especially if the argument is that change > is hard for them to do. Yet, at the same time, attempts to propose > moratoriums on misissuance by CAs have consistently failed. A moratorium on > discussions on how to reduce risk only seems valuable if would also imposed > a moratorium on trust for those CAs that have issues. Since I'm sure that's > not desirable for CAs, I hope we can agree that discussions of how to > reduce the risk of such issues is highly relevant and necessary to resolve. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: 825 days success and future progress!
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 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 > > 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
RE: 825 days success and future progress!
Ryan, I’ve warned you several times, do not put words in my mouth. I support the status quo, for now. We can talk about future changes in the future. -Tim From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Monday, April 2, 2018 2:58 PM To: Tim Hollebeek Cc: Alex Gaynor ; MozPol Subject: Re: 825 days success and future progress! On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: 18 months is not significantly different from 825 days. So there's really no benefit. So it sounds like you're supportive of 13 months, then, so that we arrive at an effective and meaningful maximum. People have to stop wanting to constantly change the max validity period. This is an entirely unproductive line of reasoning. The only reason that we're at a point of discussing incremental approaches seems to be because CAs resisted making meaningful steps all at once, and instead preferred a phase-in, like SHA-1. Proposals were put forward to make it a significant and meaningful difference, and there appeared to be wide browser support in spirit - and the only question being about the timing of the phase in. Thus, it seems reasonable to begin discussing how to approach that - and it doesn't seem productive to suggest the community should not discuss this. 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. So this argues in favor of 13 months, rather than 18 months. The communication difficulties are not expanded upon here, but it seems that if CAs spent more time investing in interoperable automation, these communication issues would evaporate, because they'd no longer be an issue. 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. I'm sure to a CA it makes sense, especially if the argument is that change is hard for them to do. Yet, at the same time, attempts to propose moratoriums on misissuance by CAs have consistently failed. A moratorium on discussions on how to reduce risk only seems valuable if would also imposed a moratorium on trust for those CAs that have issues. Since I'm sure that's not desirable for CAs, I hope we can agree that discussions of how to reduce the risk of such issues is highly relevant and necessary to resolve. 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
Re: 825 days success and future progress!
On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 18 months is not significantly different from 825 days. So there's really > no benefit. > So it sounds like you're supportive of 13 months, then, so that we arrive at an effective and meaningful maximum. > People have to stop wanting to constantly change the max validity period. > This is an entirely unproductive line of reasoning. The only reason that we're at a point of discussing incremental approaches seems to be because CAs resisted making meaningful steps all at once, and instead preferred a phase-in, like SHA-1. Proposals were put forward to make it a significant and meaningful difference, and there appeared to be wide browser support in spirit - and the only question being about the timing of the phase in. Thus, it seems reasonable to begin discussing how to approach that - and it doesn't seem productive to suggest the community should not discuss this. > 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. > So this argues in favor of 13 months, rather than 18 months. The communication difficulties are not expanded upon here, but it seems that if CAs spent more time investing in interoperable automation, these communication issues would evaporate, because they'd no longer be an issue. > 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. > I'm sure to a CA it makes sense, especially if the argument is that change is hard for them to do. Yet, at the same time, attempts to propose moratoriums on misissuance by CAs have consistently failed. A moratorium on discussions on how to reduce risk only seems valuable if would also imposed a moratorium on trust for those CAs that have issues. Since I'm sure that's not desirable for CAs, I hope we can agree that discussions of how to reduce the risk of such issues is highly relevant and necessary to resolve. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: 825 days success and future progress!
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 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 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 <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
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 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 Alex > > Gaynor via dev-security-policy > > Sent: Monday, April 2, 2018 1:07 PM > > To: MozPol > > 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
RE: 825 days success and future progress!
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 > 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
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