{"id":11523,"date":"2019-09-11T14:26:52","date_gmt":"2019-09-11T18:26:52","guid":{"rendered":"https:\/\/www.thesslstore.com\/blog\/?p=11523"},"modified":"2020-08-25T10:18:43","modified_gmt":"2020-08-25T14:18:43","slug":"ssl-certificates-one-year-max-validity-ballot-fails-at-the-ca-b-forum","status":"publish","type":"post","link":"https:\/\/www.thesslstore.com\/blog\/ssl-certificates-one-year-max-validity-ballot-fails-at-the-ca-b-forum\/","title":{"rendered":"SSL Certificates: One Year Max Validity Ballot fails at the CA\/B Forum"},"content":{"rendered":"\n

Ballot SC 22\u2019s failure highlights the dysfunction at the CA\/Browser Forum.<\/h2>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n

For now, at least, SSL\/TLS certificates will still have a maximum validity period of two years (or 27 months). The CA\/Browser Forum ballot that sought to shorten the maximum lifespan of SSL\/TLS certificates to one year failed when the voting ended yesterday afternoon. The final tally was 20 opposed, 18 in favor and two abstentions. The vote wasn\u2019t that close though, it fell well short of what was needed to pass from the Certificate Authorities.<\/p>\n\n\n\n

This is now the second time the initiative to shorten certificate validity to a single year has been rejected. The last time shortening validity was discussed, two years was the compromise<\/a>. This time around the only compromise extended to the CAs was delaying the ballot\u2019s effective date back a month, from March to April 2020.<\/p>\n\n\n\n

Citing business disruptions and the pain points of their\ncustomers, as well as 4,000 customer survey aggregate results from three CAs\nshowing website owners opposed the change by 83%, the CAs voted down this\nmeasure by a count of 20-11. The seven browser vendors joined in supporting the\nballot, but ultimately it didn\u2019t matter on account of the CA vote. <\/p>\n\n\n\n

But while that might seem like it\u2019s the whole story \u2013 it\u2019s\nreally just scraping the surface. This process laid bare the CA\/B Forum\u2019s flaws\nand likely deepened the divide between the browsers and the CAs. So, today\nwe\u2019re going to discuss the ballot, the CA\/B Forum and the absolute breakdown in\ncivility that\u2019s unfolding right now in this industry. Then we\u2019ll talk about\nwhat needs to change to fix it.<\/p>\n\n\n\n

Let\u2019s hash it out.<\/span><\/p>\n\n\n\n

Max Validity & the CA\/B Forum (and a quick word on EV)<\/h2>\n\n\n\n

For those that aren\u2019t terribly familiar \u2013 and admittedly, we\ndo sometimes forget that our singular focus on PKI isn\u2019t shared by the masses \u2013\nthe CA\/B Forum is the industry body that collaborates on the \u201cbest practices\u201d baseline\nrequirements that govern Certificate Authorities and the issuance of public-facing\ndigital certificates.<\/p>\n\n\n\n

Here\u2019s the way the Forum is described in its own bylaws<\/a>:<\/p>\n\n\n\n

The Certification Authority Browser Forum (CA\/Browser Forum) is a voluntary gathering of leading Certificate Issuers and vendors of Internet browser software and other applications that use certificates (Certificate Consumers).<\/em><\/p>

Members of the CA\/Browser Forum have worked closely together in defining the guidelines and means of implementation for best practices as a way of providing a heightened security for Internet transactions and creating a more intuitive method of displaying secure sites to Internet users.<\/em><\/p><\/blockquote>\n\n\n\n

Now, before we go any further, a quick aside. There\u2019s a real debate over the future of Extended Validation UI. There are some very vocal parties at the Forum that argue it\u2019s not effective so it should be completely eliminated. There\u2019s also a strict adherence to bylaws. They\u2019re regarded as an artifact and are so sacrosanct they can upend a ballot over something as trivial as numbering, or the editorial process.<\/p>\n\n\n\n

<\/span><\/span><\/p>\n\n\n\n

And yet, eliminating EV UI with no eye towards a viable\nreplacement seems to contradict the CA\/B Forum\u2019s own bylaws. Or at least the\nspirit of them. We haven\u2019t even gotten to the third sentence of the bylaws and\nalready it\u2019s obvious the Forum is only handling half of its stated purpose.\nYes, it\u2019s working towards a more secure web. No, it\u2019s not even making an\nattempt to find a \u201cmore intuitive method of displaying secure sites to internet\nusers,\u201d which is one stated purpose of the Forum. The browsers are finding a\nbetter way to display \u201cunsecure\u201d sites, but that\u2019s not what the bylaws say, is\nit?<\/p>\n\n\n\n

Anyway, that\u2019s not what we came here to talk about. <\/p>\n\n\n\n

We\u2019re here to talk about max validity, and the fact that this is the second time the push to shorten certificate lifespans to a single year<\/a> has failed. As we stated earlier, the first time there was a compromise. This time? Not so much. Ballot SC 22 was introduced by Google\u2019s Ryan Sleevi in August and came up for a vote from September 3-9.<\/p>\n\n\n\n

Why did SC 22 Fail?<\/h2>\n\n\n\n

If you go back and read the comments from the CAs \u2013 and not\nwith a cynical, suspicious predisposition \u2013 you see that most of the Certificate\nAuthorities didn\u2019t object to the idea of shorter validity so much as the timing\nand the changes to how long validation information could be re-used. There were\ntwo major timing factors:<\/p>\n\n\n\n

  1. It wasn\u2019t that long ago that SSL\/TLS certificate\nlifespans were shortened to two years. Customers don\u2019t care about deliberations\nat the CA\/B Forum, they care that they\u2019re now being asked to renew certificates\ntwice as often. That drives up their costs, not just financially but in terms\nof time spent and resources used, and potentially poses security challenges and\na greater risk of outages by requiring more frequent replacement.<\/li>
  2. The effective date for the ballot was March 1,\nthen it was amended to April 1, which really wasn\u2019t a help so much as it was a\nsarcastic act of passive aggression. CAs were requesting at least a year before\nthe change became effective. Google\u2019s rep gave them an extra month. Read into\nthat whatever you like.<\/li><\/ol>\n\n\n\n

    Beyond that, enterprise customers were concerned that replacing certificates yearly, at that scale, was too large an undertaking to be ready by next Spring. Automating<\/a> by then just isn\u2019t feasible. According to one CA\u2019s customer survey, when it comes to major enterprises, 75% of the customers use no automation today and 9% only use \u201c1% to 10% automation.\u201d  Another CA whose customer base is mostly small businesses, found out that among its 2,732 respondents 22% had never heard of any automation tools, another 36% used no automation, and 17% were \u201cnot sure.\u201d That created another debate that quickly devolved into name-calling, but we\u2019ll get to that in a minute.<\/p>\n\n\n\n

    The less discussed side of SC22<\/h3>\n\n\n\n
    \"\"<\/figure><\/div>\n\n\n\n

    Then there was the less obvious intention of the ballot, which was to reduce the amount of time CAs could re-use validation data. Now, there\u2019s a little bit of subtext here. There are elements of the Forum that feel that validation, specifically business authentication, is broken. That\u2019s part of the whole EV debate. <\/p>\n\n\n\n

    One of the dynamics at work in the discussion of validation is that the non-CA members (browsers) of the Forum generally have a theoretical knowledge of validation, whereas the CAs are actually performing it and have a different perspective owing to their experience with the process. Neither viewpoint is wrong. In a truly collaborative environment, the two differing perspectives could even be a strength. But as it stands, even validation is a contentious topic at the Forum.<\/p>\n\n\n\n

    Right now, you can re-use validation data for 27 months (13 months for EV). After the initial validation, a CA can issue any certificate you order with only a domain control check if you ask for a new domain. That means it\u2019s near instant. For large organizations this is a godsend. Reducing the amount of time that validation information stays \u201cfresh\u201d and can be re-used means organizations and CAs must validate more often. That consumes time and resources from both the CA and the organization getting the certificate. It\u2019s also another move that devalues higher-validation certs because the re-validation process is more burdensome.<\/p>\n\n\n\n

    As we stated earlier, it wasn\u2019t the max validity that was\nthe problem for many CAs so much as it was the validation restrictions. And the\ntiming. <\/p>\n\n\n\n

    CA\/B Forum Ballot SC22 \u2013 The Voting<\/h3>\n\n\n\n

    When push came to shove, the ballot failed with CAs 20-11.\nTo pass, this ballot needed two-thirds of the CAs and a majority of the browser\nvoters. It didn\u2019t even come close with the CAs. Here\u2019s the final breakdown of\nthe voting:<\/p>\n\n\n\n

    \"\"<\/figure><\/div>\n\n\n\n

    The measure was overwhelmingly supported by the browsers.\nAll seven votes were in favor:<\/p>\n\n\n\n