[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

Thu Aug 22 13:41:44 MST 2019

  *   Again, there is zero requirement to adopt any form of automation - whether automation of certificate deployment (e.g. Puppet) or through automation of issuance (e.g. RFC 8555). While both are recommended, it's not correct to suggest this ballot does anything to require them. Organizations are more than capable of making a change on an annual basis.

Not yet, but I remember also the question in this discussion, if the reduction to 1 year is the final goal and it has been declined. On the other hand, if 1 year would be the goal, it won’t provide you with the results, you’re looking for, as therefor it’s still a too long period. Although 3 year cycle are somehow usual for any kind of certificates or similar products and a reduction to 2 year was already not necessary, I still don’t see the advancing results, I could accept, that it brought DV, OV and EV validation periods in line, but 1 year I see no reason and for your reasons, 1 year is too long and for no automation requirements, 1 year is the absolute minimum before any other possibilities need to be considered.

  *   Everything we do, within the CA/Browser Forum, that improves security is a preventative measure. The Baseline Requirements are a preventative measure to prevent CAs from issuing certificates that harm users, by describing how to correctly issue certificates. Reactive measures, sometimes called "detective" measures, do not reduce probability nor improve security - they merely deal with harm once it has been caused.

Reactive measures are about to reduce the impact, detective measure are before any impact arise. Preventive measure are somehow preventive and need always to be weighted if the cost of the measure meets the risk, they try to mitigate.

  *   As the Ballot notes, this is the starting point for discussion. As noted by supporters of the ballot, there's real security risk in the reuse of validation of information, and so I would expect that it's not unreasonable to see that time period further reduced - potentially on an increment of allowing the reuse of domain validation for 30 days, initially (as we do for Random Numbers and Response Tokens), and then, eventually, requiring a unique domain validation for certificates issued. However, that should not be conflated with requiring automation nor reducing lifetimes - that's something entirely separate.

So why then reduce, if you believe its valuable, the reuse of validation information without reducing the certificate lifetime. You will have the “golden middle way” then. This could also be adopted much easier by companies, e.g. getting them to streamline their renewal processes by a particular timeframe of e.g. 30-90 days for all of their certs or do a validation “window” for 30-90 days possibility to get certificates issued in this frame.

  *   I agree, and many other browsers do as well, that there are many concerns with the current scheme. Audits can be used for many things. In your example, you discussed certification audits, but those should be recognized as different from attestation audits, or from second-party audits, or from the many other types of audits that exist. While the Root Program members of the CA/Browser Forum happen to use a particular approach presently, it's been well discussed in the Forum that such approaches may need to change.

So again remember on my “low hanging fruits” analogy, then changing the audit scheme is a primary goal than any preventive measurement on secondary topics, just for in case. As I’m sure, if valid measuremenst will exist, you won’t increase the validity period? I’m a bit wondering, why this audits are such different, they are third party audits, the third party auditor needs to be enabled to audit WebTrust or ETSI and the biggest players in there like KPMG, PWC, EY are well known and established on the markets and also do accredited certification audits, I won’t believe, that such companies will do their job well there and will do a shame of a job on WebTrust or ETSI audits?

  *   Our approach to security is to treat it as a holistic problem. There are many benefits to improving audits. However, those improvements will not reduce the risks that reducing lifetimes does, nor will it provide the necessary agility. As with any system, one should approach it with a holistic mindset. Similarly, one should not let the perfect be the enemy of the good, nor should one let other areas wither in order to improve just one. We're all in this together to improve.

As mentioned already, I don’t be able to follow your argumentation on a reduction to 1 year and I as well can’t see any benefits yet in reduction to 2 years. Although stated many times, you weren’t able to provide yet proven information, that the recent reduction (or increased agility) improved anything, which an additional reduction should (and won’t) improve as well.

  *   Yup. This is a well studied problem of public key infrastructures, and has been known for decades. My favorite work to reference on this topic is is Dan Geer's talk on this: https://cseweb.ucsd.edu/~goguen/courses/275f00/geer.html In the end, Browser root programs are all about managing risk to users. Right now, the long lifetimes represent an unacceptable risk, and so they will be reduced. The challenges of that reduction - such as requiring annual replacement of certificates instead of once every 27 months - are worth it.
  *   Part of this evaluation is recognizing that the ecosystem is already well on its way. For example, 94.2% of the still valid certificates and precertificates are issued with a period less than or equal to 13 months. Only 6.43% of certificates & precertificates are potentially affected. The ecosystem is well on its way for recognizing long-lifetime certificates are a huge risk, and unfortunately, the only way to reduce that risk for everyone is to mandate a maximum.

Two year lifetime is long? So what is short then? They will be reduced, so whatever will be the outcome of this ballot, Google will enforce?

That’s not because of many already accept and performed a reduced validity period as they see it as valuable, it’s just the ones, who want to have it for free and if looking at the Top Websites in the world, the percentage of such certificates (or finally Let’s Encrypt) is going really fast down.

  *   Browsers, and users, have seen huge benefits from the reduction in lifetime. I can understand that, as a server operator, those benefits may not be obvious, despite the protection against certain risks. For example, the ecosystem was able to move away from trusting an incredibly risky CA in a timely fashion, in part, because as certificates came up for renewal, they could be replaced with certificates from a CA not being distrusted. We'll continue to see benefits like those outlined in the original post.

You mean the replacement of the Symantec certs by Digicert certs? But you also remember, that this replacement happened before the two year validity got active? So I’m still lack of an example, there the reduced lifetime really helped.

  *   You're correct, these benefits continue to accumulate as we reduce further, and thus, it's always good to invest in automation of issuance or, if automatically issued certificates is undesirable, automation in deployment. Organizations will find their costs lowered and their systems more secured through this.

Again automation is non secure, and automation of issuance is required as just automation of deployment won’t help (and is a risk factor as well).

  *   As I noted earlier, the next steps will be to reduce the reuse of domain validation information. Luckily, many solutions exist for this, and automation is not required here, even if it was reduced to NO reuse of information. That's great news!

Agree and I have no problem with that, as mentioned above, go further with reducing the information reuse, if you see problems here, getting BR changes adopted earlier could be performed by that (although misissued certs could still be revoked and reissued, but for improvements, I agree).

  *   I'm sure, as the ecosystem evolves, it may also be necessary to revisit further reductions in the maximum lifetime. However, based on the current information, that doesn't seem necessary to start worrying about right now. As always, though, the important thing to remember is that the Internet evolves and moves on as new threats and new understanding comes about.

That sound different in the recent discussion two years ago, so I won’t believe. It was like negotiating loan, two years ago 1 year has been asked for, 2 years was the deal. Now 1 year gets asked for and I’m unsure of the outcome, however, I’m sure, in two years we will discuss again about any shorter timeframe below 1 year, I would expect 180 days or directly 90 days.

  *   Thanks for your active engagement here! It's been a great opportunity to share and educate some of why this is an important next step that browsers need to take to help secure users, and how sites will benefit from the improved security and reduced risk that is afforded by reduced lifetimes!

I’m just a concerned user of the impacts of this change and try to reflect, that it won’t be the right measurement for the goal expected. I’m also concerned about the reasons behind. I prefer streamlined solutions and working on risks at their root cause, getting a reliable set of measure based on the risk instead of the lowest hanging fruit. I try to negotiate the effectiveness and efficiency of a measurement against the risk. So therefor again, I can’t follow your argumentation, if it’s not finally thought. Finally thought, it will end up in day-certs and that brings additional impact as mentioned before with all the side effects mentioned before.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190822/a4eb148e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3860 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190822/a4eb148e/attachment-0001.bin>