[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Ryan Sleevi]

On Tue, Aug 27, 2019 at 1:41 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> We know that at least Apple and Mozilla have implemented an acceptable (to
> the ecosystem) solution for revocation checking so your strong statement
> about revocation being "unacceptably broken" does not entirely hold. I am
> not so familiar with Microsoft's or other browser's implementations.
>

Apple's solution does, at present, involve a substantial sacrifice of
privacy and performance. As Apple's repeatedly noted, there's a 2% false
positive, and for users on that false positive list, it requires going to
check an OCSP responder - i.e. disclosing the user's information.

I don't say this to criticize Apple, but to highlight the inherent value
here. Mozilla's implementation is, as I'm given to understand, not yet
shipped, and has its own set of tradeoffs.

With respect to "Certificate Status Services" and privacy in general, there
are a host of concerns beyond this privacy angle, but the privacy angle is
the most salient to the existing technologies, OCSP and CRLs, that some
members, such as HARICA, have stated are suitable. If the view is that OCSP
and CRLs are not sufficient, and the ecosystem needs something different,
then I'm sure we can unabashedly agree that CAs have not contributed much,
or even attempted to understand, the issues at play. Similarly, the
assumption of revocation as functioning simply externalizes those costs
onto Relying Parties and Relying Party Software. For example, the solutions
implemented by Apple and Mozilla are completely and wholly unsuitable for,
say, an application like curl or wget. However, a reduction in certificate
lifetime benefits such clients equally.

This perhaps captures the most salient piece: An important and inherent
recognition of SC22 is that, from the browser and ecosystem perspective,
Certificate Status Services come with significant ecosystem harms, privacy
among them, and places significant burdens on Relying Parties to address
situations like CAs' failures to abide by the Baseline Requirements (again,
among a host of reasons). A reduction in lifetime reduces the risks, to the
ecosystem, from many of these harms, and at a marginal-to-no cost to the
ecosystem, including those who would "like" longer certificates.

Even if clients could check revocation data, we know that results in a
suboptimal experience for Subscribers. Multiple CAs have shared the
challenges in communicating changes to their customers, while regular
contacts - such as renewals - provide streamlined means to communicate
about upcoming changes. That was one of the clear lessons from the SHA-1
deprecation, including that of the exception process: CAs need more contact
with their customers, and need to continually have relationships adopting
to the best practices. Lifetimes are the single greatest means to
accomplish this, as we see time and time again, most recently with the
deprecation of trust in Symantec.

Revocation can't answer this. Revocation makes something just stop working
- and that harms Subscribers and that harms Site Operators. Yes, there's a
risk that certificate expiration can also cause stuff to stop working, but
the nice thing about expiration is that it's predictable and expected. I
would think a responsible CA would want to afford their user that
predictability, rather than just insisting on the opportunity to be able to
break them whenever, and often for no fault of the Subscriber, but the CA.

So there's no reasonable way you can argue revocation works, and even if it
did, that it's the best answer. Users deserve better. Sites deserve better.
CAs need to do better by the ecosystem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190827/c2739e1e/attachment.html>