[cmeacham98]

> All certificate revocation-checking schemes "fail open" and proceed happily on their way if the MITM blocks their communications with the revocation lists.

Incorrect, firefox implements OCSP Must-Staple and treats a failure there as equivalent to a certificate validation failure. Now if only we could ever get chrome(ium) to implement it...

[octoberfranklin]

OCSP Must-Staple is just another name for "really short certificate expiration periods"

Must-Staple with a timeout of X seconds is functionally equivalent to a certificate with a validity time of X seconds. In either case you need to go fetch something from the CA every X seconds, or else get booted off the net. The only difference is what you call that thing.

   HN is doing its silly "slow down" nonsense, so I will reply to the reply below by editing here.

To @cmeacham98: I'm not moving the goalposts; all practical revocation schemes fail open. OCSP Must-Staple isn't actually a form of revocation; it is just expiry with a fancy name and lots of extra complexity.

The implementation quirks of one particular CA (LE) are not features of these protocols; they are features of that particular CA's policies.

To @mhils: CAs could easily stand up simple servers that let you ask for the most recent certificate (if any) issued to a given domain and public key.

They don't want to do this because it's a burden. The only reason they run OCSP servers is that they're under pressure from insurers, regulators, and auditors to participate in the whole revocation theater game. Saying "we don't do revocation" would cause people to freak out, and setting up an OCSP server takes effort, but less effort than explaining to the insurers/regulators/auditors that revocation doesn't actually work.

As for CT, the log could simply include an extra (issuer-signed) field which amounts to "I will auto-renew this certificate until $DATE" and omit all the additional certificates issued to that same public key and domain name between the log entry and $DATE. Of course the browser would need to understand this field in order to validate the CT log entry.

I'm not sure super-short expiration is really preferable; it makes the Web even more fragile than it already is. Frankly I think Web PKI is sort of a big mess at this point. Most of it only makes sense when viewed through the lens of "(a) governments will always control DNS for the the two-letter TLDs, (b) Google cannot get all governments to supplicate to Google, therefore (c) we must conjure up an extra layer of entities (the CAs) that can be bullied around by manipulation of browser engine code". This is basically the only reason why DANE (or a modernized revision of it) isn't used.

[mhils]

I absolutely agree that shorter lifetimes are likely preferrable over the additional complexity that comes with OCSP Must-Staple. That being said, one benefit of OCSP Must-Staple is that you don't need to authenticate yourself to get the OCSP response. Another benefit is that Certificate Transparency Logs remain smaller, which in turn also benefits CRLite filter sizes.

[cmeacham98]

> I'm not moving the goalposts; all practical revocation schemes fail open. OCSP Must-Staple isn't actually a form of revocation; it is just expiry with a fancy name.

Of course it is revocation, it allows you to revoke a certificate before its normal expiration (90 days for LE).

I could make this argument in reverse: "very short lifetimes are functionally equivalent to OCSP Must-Staple, and thus is a form of revocation". Of course, this is ridiculous both ways: being similar or even 'functionally equivalent' does not make two things the same.

[xg15]

But that's just semantics. GP's point was that with Must-Staple, the "real" expiration period becomes pretty much irrelevant - instead, the lifetime of the OCSP response becomes the new effective lifetime of the certificate.

If you compare (1) a short-lived certificate and (2) a long-lived certificate with Must-Staple and short-lived OCSP responses, the benefits, security properties and failure modes of both are exactly the same*. You're just putting the timestamp into different fields.

(* Or almost: Some notable practical differences are described in the sibling comments - but those are mostly a property of LE's current policies, not the protocol itself)

[cmeacham98]

This is moving the goalposts. You claimed that all certificate revocation methods fail-open, I pointed out that OCSP Must-Staple is a fail-closed revocation method that is implemented in a popular browser.

Regardless, even if "functionally equivalent", there is a practical difference: LE does not allow me to issue a certificate every minute, but does allow the OCSP Must-Staple extension.