[cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

Ryan Sleevi sleevi at google.com
Tue Sep 4 17:22:06 UTC 2018

On Tue, Sep 4, 2018 at 1:08 PM Dimitris Zacharopoulos <jimmy at it.auth.gr>

> On 4/9/2018 5:53 μμ, Ryan Sleevi wrote:
> I do not believe there is any justifiable or defensible reason to extend
> the 5 days requirement, nor do I believe the CA should be expected to have
> a 'clean' audit should they chose to do so.
> CAs facing challenges of their own creation should not be exploring "How
> do I keep these certs working", but "How do I make sure I don't issue
> violating certs to begin with". Anything less is gross negligence, and not
> the system we should be striving to build.
> Ryan, it's fine we disagree, however allow me to clarify one more thing. I
> had a very different picture for the CA that got this case. It was not "How
> do I keep these certs working" but "How do I balance the need for RPs to
> access a service ("Availability" in terms of C-I-A), which is also a
> pressing matter for Subscribers, and "the requirement to revoke the
> certificate in 24 hours or 5 days".

I disagree that this is the correct prioritization. A bad CA should not be
prioritizing availability - that sort of perverse incentive structure is
one that several now-distrusted CAs have argued, precisely because it sets
the wrong expectations. We've seen CAs unsuccessfully argue that even
though they didn't validate the domain properly, or could not demonstrate
that validation, it's still more important to availability.

This is no different than if your website is made inaccessible because your
hosting provider failed to pay their power bill. I can understand it's
inconvenient to lack availability, but your service provider is the one
that failed, and they don't get to steal power in order to optimize your

> The CA will still get an "unclean" report anyway because of the RFC5280
> violation or the mis-issuance per se, we are not debating that. I am only
> pointing out the requirement to revoke within 24 hours or 5 days. Does this
> make it clearer?

You are, though, because that's not accurate to suggest the CA is
guaranteed to get a modified opinion / qualified report. If the BRs endorse
this, as you propose, then it's no longer a BR violation. If the
information was, say, inaccurate (the domain ownership was lost due to
court order), but the CA determined to optimize for availability, then the
CA isn't in violation of the BRs or RFC 5280 if they decide not to revoke.

There is no safe way to do what you ask, nor is it reasonable to do what
you ask. For a system built on trust, it requires trust in the competencies
of CAs. The reality of SSL/TLS is that the cost for mistakes is
externalized on the ecosystem - on to Subscribers, Relying Parties, and
Application Providers - while the profits from those mistakes are
centralized with the CA. That's a fundamentally imbalanced system, yet the
reality we live it, but that doesn't mean we should further seek to
exacerbate those imbalances.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180904/52440c6d/attachment-0003.html>

More information about the Public mailing list