We've made some great progress in the TLS and PKI ecosystem in recent years, driven largely by the actions of browser vendors. We could have just taken another step forwards with Ballot SC22 at the CA/B Forum, but too many CAs voted against the ballot.


The CA/B Forum

For those who aren't familiar, I will give a quick explanation of a few things. The Certificate Authority / Browser Forum, or CA/B Forum, is a self regulated body that governs many of the actions of Certificate Authorities. You can see the current membership of the forum and see that it is largely made up of CAs. One of the main purposes of the CA/B Forum is to produce the Baseline Requirements, a document that governs the "Issuance and Management of Publicly-Trusted Certificates". This is basically the rule book that CAs must play by and you can view the current version (v1.6.6) if you like. Amongst the things this document governs is the maximum validity period of a certificate.



Ballot 193 - 825-day Certificate Lifetimes

The last time we changed the maximum validity period on a certificate was back in March 2017 with Ballot 193. In that successful ballot, certificates were taken from a maximum validity of 39 months down to 825 days. Here are the results of that ballot:


Voting by CAs – 27 votes total including abstentions
24 Yes votes: Entrust Datacard, TurkTrust, Izenpe, Certinomis, DigiCert, Amazon, CNNIC, HARICA, GlobalSign, GDCA, Disig, Trustwave, Let’s Encrypt, Quo Vadis, SHECA, CFCA, OATI, Comodo, Buypass, Logius PKIoverheid, Cisco, Symantec, Certum, SwissSign

0 No votes:

3 Abstain: ANF Autoridad de Certificación, Secom, Actalis

100% of voting CAs voted in favor

Voting by browsers – 6 votes total including abstentions
5 Yes votes: Apple, Qihoo 360, Microsoft, Opera, Google

0 No votes:

1 Abstain: Mozilla

100% of voting browsers voted in favor


That ballot had great support and passed without issue, but there was something else. There was a previous ballot to try and make the jump from ~3 year certificates down to ~1 year certificates, prior to the one I'm talking about today.


Ballot 185 - Limiting the Lifetime of Certificates

That's right, SC22 isn't the first time we've tried to reduce certificate lifetimes to ~1 year, it's the second time. It's the second time we've tried, and it's the second time we've failed... Ballot 185 took place back in Feb 2017 and the results were not great.


Voting by CAs – 25 votes total plus abstentions
1 Yes vote: Let’s Encrypt

24 No votes: DigiCert, Entrust, AS Sertifitseerimiskeskus, Izenpe, ANF Autoridad de Certificación, Comodo, Certinomis, HARICA, GlobalSign, Quo Vadis, GoDaddy, Actalis, Symantec, Trustwave, CFCA, Secom, TWCA, GDCA, Certum, OATI, Buypass, SHECA, CNNIC, Cisco

3 Abstain: Logius PKI, SwissSign, Chunghwa Telecom

4% of CAs voted in favor

Voting by browsers – 4 votes total plus abstentions

2 Yes votes: Google, Mozilla

2 No votes: Microsoft, Qihoo 360

1 Abstain: Apple

50% of browsers voted in favor


That ballot got absolutely hammered by the CAs and with the exception of Let's Encrypt, not a single one would show support. The question is, have things changed since then?


Ballot SC22: Reduce Certificate Lifetimes

As I'm sat writing this blog post, there are 47 minutes left for CA/B Forum members to cast their votes and it's all but inevitable that this ballot will also fail. It seems that whilst the idea of 1 year certificates has gained some support amongst the CAs, it's still nowhere close enough for a ballot to pass. With ballots in the forum there is a requirement that 66% of voting CAs vote YES and that 50% (+1 browser) of the browsers must vote in favour. While we did get 100% of browsers voting in support, we got only 35% of CAs.



Now, there were many reasons given by CAs on why they voted against this ballot. Some voted against it without so much as a reason why, but others tried to explain their actions. The number one reason cited is that server operators are just not ready for 1 year certificates and by reducing the lifetime of certificates we will increase the burden on those renewing them manually.


Why did 1 year certificates fail again?

My view is that CAs have their motives all wrong. Some CAs did poll their customers on what they thought about the ballot, but the questions seemed either loaded or vague. I expressed concerns throughout the process online, often catching heat for my views.




Similar things can be seen on the mailing list and other CAs also polled their users and concluded similar results. All CAs sang the same chorus. Our customers are not ready for 1 year certificates, it will be too difficult for them.

Maybe it would be. Maybe renewing your certificates manually would be a bit of a burden, but it seems to be more so in large enterprise and the finance sector, where there's a lot of legacy. Another common argument was about legacy devices and software that couldn't support automation of renewal and would need manual steps. Sites on hosted platforms don't suffer these issues, nor do sites using a good CDN provider like my blog behind Cloudflare. These are big organisations that move slowly and they're holding back the rest of us, but they have the ear of CAs who they spend a lot of money with. CAs should not be resisting changes that make the ecosystem better, they should be supporting them. What do their customers need to get ready and how can the CA help? What can they do to earn their keep? Instead, they resist change and stagnate progress.

Another thing that came to my mind was whether the CAs voting against ~1 year certs were actually ready for it themselves and whether their customers were a nice scapegoat. As we continue to reduce certificate lifetimes, the value proposition of automation becomes greater and greater. The catch is, you can only automate if your CA supports automation, hopefully via something like ACME. If you're pushed to 1 year certs as a website operator, and your current CA doesn't support ACME, what are you going to do?.. To the best of my knowledge their are only around 5 CAs that currently support ACME, so perhaps there was a worry about their own readiness to automate and not that of their customers?



The last point is when all of this would come into effect. Those worrying about the lack of automation in the ecosystem seemed to skip over the fact that this change wouldn't come into effect until April 2020. That means that the first time you'd find yourself renewing and getting a 1 year certificate wouldn't be until at least then, 7 months from now. You could also work around that problem by renewing your current 2 year certificate before then, which gives you the ability to push that out to April 2022! But, let's play out the worst case scenario, you renew in April 2020 and you get your 1 year certificate. That still means you have 19 months, from now, to look at getting automation in place if you need to, or to simply renew manually if it's not so much of a problem. 19 months to get automation in place...


What's next?

I was disappointed to see the ballot fail by such a large margin and whilst we did fall a long way short on the CA vote, the overall vote was 47% in favour, which is a distinct improvement from the last attempt. Many suggest we try again 1 year from now and see if there is enough support for the vote to pass then. The last step we took to reduce lifetime was in 2017 and that was because the 3y -> 1y jump was too big and we split the different at 3y -> 2y instead. My concern with that idea is that without the incentive we won't make any progress. If organisations can renew manually on a 2 year renewal, which they currently do, what reason do they have to automate? Pushing the certificate lifetime down would be the reason to automate! As a result, I don't think that hoping organisations will automate and do the right thing has a realistic chance of success. Who knows, maybe it will be 3rd time lucky? I don't think so...

Looking at the votes back in 2017 and the votes now, it's clear that there are key players who want to reduce certificate lifetimes. I have my own views on why we need to do this, and you can read them here with links to further blog posts, but there are clear benefits. There have been 2 attempts to do this through the CA/B Forum now and both have failed. We're looking at another lengthy wait before we can take another shot at it. I don't think the trust store operators or browsers will wait that long and risk failing again. Yes, the CA/B Forum, through the Baseline Requirements, controls the maximum lifetime a certificate can be issued for, but this isn't the only control over CAs that the browsers have. In order to be recognised as a CA, the CAs have to play by the rules of the trust store operators. Organisations like Microsoft and Apple who include a CA in their program give a CA their power, and to get that power there's another pretty strict set of rules to adhere to. If those rules were to change, a CA would also have to abide by those and that could be an alternative avenue that is considered now that the route through the CA/B Forum has failed twice after a 2.5 year period.


Other thoughts

As I mentioned above you can read all of the emails from the CA/B Forum but there were a few things that stood out to me alongside the resistance to the use of shorter certificates.

Revocation

Regular readers may know about the issues with revocation and how it's broken. If an attacker manages to steal your key, they can use your certificate until it expires. The difference between a 2-year and a 1-year cert is a lot of exposure to risk. A shorter certificate undeniably reduces that risk. The worrying part is seeing several CAs on the mailing list argue that revocation is not broken. TrustCor went so far as to say "We are not convinced that any certificate validity system based on revocation is broken, as indicated in the ballot." I'd have hoped that organisations like a CA would have a firm grasp on these things by now.

Certificate Transparency

One CA made the argument that reducing certificate lifetimes will of course increase the rate of issuance which will put a burden on CT logs. That'd imply some kind of systemic issue with CT logs and that simply isn't the case. We're adopting HTTPS and deploying certificates faster than at any point in history and the CAs selling the certs have never had a concern about CT logs thus far.

The SHA1 deprecation

Back in 2017 we had to deprecate SHA1 faster than had been allowed for. Certificates using SHA1 stopped being issued 1st January 2016 and the maximum lifetime of a cert was 39 months. SHA1 did not survive 39 months and only 12 months later Chrome and other browsers dropped it. One CA made the argument "the Forum has learned its lessons and will not delay future algorithm deprecation the way it did for SHA1", completely missing that the CA/B Forum did not delay SHA1, it was industry push-back, ironically the same push-back we got on SC22...

Resisting further change

Throughout the thread there were highlights of the same sentiment, that CAs were concerned that SC22 was a sign of things to come. There's no secret that it is. Certificates have only ever been reduced in length and at no point in history has the maximum lifetime of a certificate been increased. Since the beginning it has been reduced and it will continue to be reduced for all of the same reasons. Better agility. Better security.

All in all, this process really highlighted some of the issues we have in this ecosystem and just how deep they run. The browsers tried to change this twice through the forum and if I were a gambling man, my money would be on the 3rd attempt being taken elsewhere.