[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Jeremy Rowley]

There’s a problem with this ballot most people are ignoring and that’s that any CA voting is “damned if you do and damned if you don’t”. I suspect almost everyone will wait until the last minute to vote, to see how the ballot is going to turn out, for a couple of reasons.
First, CAs are getting a lot of different input and some CAs believe there are some business advantages to opposing this ballot, regardless of the outcome. Any CA that votes for this ballot will have other CAs use that as marketing material against the voting CA. We saw this with the last change (from 3 years to 2 years) and with the underscore character deprecation.  Regardless of outcome, with 85% of the customers answering the survey against the change in validity period, the risk is high that a CA will face some negative reaction if they vote in the affirmative.
On the other side, all of the browsers seem universally aligned with the change and the security reasons for the change are (imo) compelling. To avoid being dragged into the middle, the safest bet for a CA is to not vote. The second safest bet is to wait until the ballot draws out and then vote no if the ballot will pass.  I dislike the politics on the voting so I’m hoping calling attention to them will mix things up.
Second, voting “no” gives the CA someone to blame for the change that insulates the CA from ramification of the change. The blame then can be on the ballot voters for the shortened lifecycle. Angry customers can be deflected to the browsers/CAs who vote yes.  Waiting for the browsers to do this unilaterally is the safest CA action for any CA because then you can point to the browsers, even if you agree with the change. Anyway. That’s my two cents.
Strategy aside, the concerns we’ve heard from customers and internal people about the ballot run down as follows with the following solutions:

  1.  The timing.  The ballot is proposed for April. April is tax season. Since we have a lot of banks and government entities, tax season is hard for them. A shift to 1-year certs doesn’t present significant technical obstacles in making the change, but the problem in getting approvals is bureaucratic, meaning the change in policy needs to happen before the effective date. It’s not accurate to say we have until March 2021 to migrate people to 1-year certs because the approval to migrate to 1-year certs must happen in March 2020.  This also happens to coincide with when we are shutting down some legacy Symantec systems. When you combine the two, you end up with a very awkward month for several customers facing both a console migration and a profile migration, even though the profile migration is small.



  1.  Automation. Automation is closely tied to the timing issue imo. Many of our customers still haven’t deployed widespread automation in their environments. We have tools that some customers are using, but deployment still needs some work. We can tell you from our metrics that DigiCert customers aren’t using the tools we have available. Talking to people, we know this is because they want to control the end points, don’t want to open ports on their system, need audit approval before deploying automated solutions, or want to be able to control the automated tools better.  Whatever the reason, there are some subscribers that don’t want/need automated tools to manager their certificates.  For these subscribers, moving to 1-year certs effectively doubles the resources required to manage their certificates.  However, “automation” does not need to mean full automation. Instead, automation can mean faster cert deployment – really anything that simplifies the certificate process. So happens, we have a solution for these customers slated for mid-next year (June). Delaying until June allows us to address the problem with automation…. assuming the roadmap stays intact. 😊   I would have liked to release it sooner, but we wanted to shut down the legacy systems first. I realize other delays have not been favorably granted, but the reason for this delay is to kill two concerns with one stone – the approval process required by government entities/banks and to address the automation concerns.



  1.  Verification. Re-verification of entity information every year isn’t a significant obstacle except for the verification of authority. Calling a person’s supervisor to confirm their relationship to the organization takes a long time and places a significant burden on someone generally not part of the certificate enrollment process. I think we should add a new method to verify authority. We can do this from now through the effective date of the ballot.  We’ll need to work out the details, but anything that can ease the burden of requiring reconfirmation of employment annually would address this concern.  Tim and I will brainstorm on something and propose it to address this issue. If you can address authority, you address the complexity in issuance.





From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Tuesday, August 27, 2019 1:53 PM
To: Christian Heutger <ch at psw.net>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

On Tue, Aug 27, 2019 at 9:23 AM Christian Heutger <ch at psw.net<mailto:ch at psw.net>> wrote:
> For example, I don't think we'll ever find consensus when a CA is arguing that users should have to sacrifice their privacy and disclose their browsing activities to CAs to be secure online, which is what you've clearly advocated. That sort of fundamental misunderstanding suggests a misunderstanding of the role CAs play, and is not easily corrected, no matter how carefully dispelled.

OCSP stapling doesn’t require to do so.

I appreciate you raising OCSP stapling, because it's a great example of how a service-focused mindset ignores the ecosystem impact and challenges, and demonstrates the high costs involved with extract value, relevant to the high value available via certificate lifetimes.

The thesis of Dimitris' argument is that if we had a perfect revocation system, we would not need to address validity periods. My response to Dimitris indicates why a perfect revocation system is unrealistic and impractical. If I understand your argument, it is that OCSP stapling could be that perfect revocation system, at least with respect to privacy.

Recall that the objective of reducing certificate lifetimes is to protect users and serve users needs. Users want to ensure the information is fresh, accurate, and reliable, because that ensures that their information is adequately protected in transit.

There is no way these users can "force" servers to support OCSP stapling. The user's options are:
1) Fetch an OCSP response or CRL, both of which compromise privacy and performance
2) Refuse to connect to a server that does not support OCSP stapling.

We can assume that #1 is unacceptable for privacy and performance reasons. #2 is impractical, for a variety of reasons:
1) The majority of servers do not support OCSP stapling today
2) The majority of server software does not support OCSP stapling today in a way that meets user needs
  - I'm only aware of two servers that support OCSP stapling robustly: Microsoft IIS and Caddy Server.
  - All other implementations create the risk of significant service disruptions or would result in severe configuration errors

Now, if you were to ask any server operator individually, you'd likely find that the cost of getting OCSP Stapling working for their server, and working in a way that would not disrupt their site (e.g. serving expired responses, handling timeouts/retries when fetching, working behind their firewalls aka against best security practice), they'd argue that the benefit is very low to them. Individually, they'd not be concerned about their certificate being revoked, and they might argue (incorrectly) that it's the client's responsibility to check the status, and not theirs to provide it.

Similarly, imagine you're a server operator that does opt in to OCSP stapling, and you did everything right. However, you don't benefit from doing this if the client doesn't require (or perform) OCSP checking themselves. That's because if an adversary gets a certificate, then even if you detect it and revoke it, the adversary doesn't have to support OCSP stapling.

Now, a naive suggestion might be to say "Ah hah, this is what OCSP Must-Staple solves!". Except OCSP Must-Staple similarly works against users and site operators. Unless all CAs set OCSP Must-Staple, which they absolutely should not do without robust OCSP Stapling solutions not only implemented (which they aren't today) but also deployed (which they definitely aren't today), or all clients require Stapling, OCSP Must-Staple doesn't actually solve anything for the Defender, because the Attacker will just get a certificate without this.

So we're in a situation where:
1) A well-informed site that wants to defend against maliciousness cannot, because:
  a) Other sites' behaviours negatively impacts them (e.g. the lack of their support for Stapling, preventing clients from implementing stapling)
  b) Other CAs' behaviours negatively impact them (e.g. CAs issuing without Must-Staple)
  c) Their own CA's behaviours with respect to the OCSP responses negatively impacts them (e.g. OCSP responses that are 10K in size, as some CAs' responses are), and absent collective action or requirements by browsers, a single site operator cannot convince any CAs to change or improve.
2) A user that wants to defend against maliciousness cannot, because:
  a) Sites don't have incentives to adopt OCSP stapling (e.g. it's all cost to them, with no benefit from Attackers)
  b) CAs don't have incentives to adopt OCSP stapling (e.g. deploying Must-Staple would simply break clients, because the server situation is awful)

To support OCSP stapling, you'd need
1) Server software to be updated to actually support robust OCSP stapling
2) Server operators to deploy updated web servers (which can be very hard)
3) Browsers willing to break any site that didn't comply, which requires a majority of #1 and #2 to be solved.

Now, in all of this, we haven't talked about the role CAs could be playing, but to date, have not, in addressing some of those concerns. It should be obvious that CAs could be doing stuff here, but even more than expiration, the articulation of benefits here is hard.

And equally important is that even with this perfect solution, of ubiquitous and reliable OCSP stapling, it:
1) Doesn't address all of the issues highlighted that expiration does address
2) Requires significantly more investment from a significantly larger amount of sites and players

The Web PKI is full of stories like this, where users and well-meaning server operators are harmed by the CAs and the recalcitrant customers, such as yourself, and wholly rely on Browsers to do the Right Thing by the user and to protect their interests. I understand why technologies like OCSP-Stapling or OCSP Must-Staple seem appealing, and while I've only focused on a small section of revocation, the reality is that there is nothing that meaningfully addresses the problems.

You've suggested, previously, that it's short-sighted or not weighing the costs versus benefits. I can only assure you that in the years that we've been talking about this, these concerns have been carefully weighed, and they've absolutely been communicated to CAs in the past. We need to move forward, and we need to do the right thing for users. Certainly, Chrome will do the right thing for users, but our hope is that as an industry, we can recognize that our inaction is causing harm and that nothing as comprehensive, as beneficial, and as low cost exists to address so many of these issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190827/9086d567/attachment-0001.html>