Re: [Trans] Proving certificate freshness

[Daniel Kahn Gillmor <[e-mail]>]

On 09/30/2014 11:56 PM, David Leon Gil wrote:
> Something that is rather difficult to prove, at present, is that a
> certificate has been used after it has expired or been revoked.

To be clear, this is a concern because it's otherwise possible to claim
abuse of a revoked/expired cert without being able to substantiate the
claim.

That makes reports of cert misuse less trustworthy, which makes it
harder to act on them.

However, CT is designed to detect (and hopefully deter) misissuance, not
misuse.  Is this scope creep?

How would a certificate holder act on a report of misuse of a
revoked/expired certificate?  clearly, revoking the certificate isn't
sufficient :)  Maybe such a proof could be used to get browsers to push
the key into their internal blocklist instead of relying on our existing
flawed network-based revocation mechanisms?

Would we want to do anything else besides "revoke harder" upon proof of
certificate/secret-key misuse?

> If servers were required to include a signature over a recent STH (or
> STH+OCSP staple) along with their SCT, this would provide an easy way
> of showing that a *server* was behaving incorrectly. 

I think you're talking specifically about the end-entity doing this, and
not any of the CAs in the CA chain.  My comments below are based on that
assumption.

> E.g., as a TLS extension:
> 
> struct {
>   STH;
>   sign(SignedCertificateTimestamp || OCSP || STH);
> } FreshnessProof;

Are your || symbols here "or"s or concatenation operators?

> This seems rather better than signing a timestamp; the STH isn't
> predictable without a colluding log, so it isn't possible to
> "accidentally" sign a future time.

I agree that signing a recent STH or OCSP response is better than
signing a raw timestamp on its own.  Is there a reason that this needs
to be an STH, though?  Put another way, should this be discussed on the
[e-mail] instead of [e-mail]?

If a certificate is required to staple a recent-enough OCSP response
(e.g. via one of the proposed "must-staple" x.509v3 extensions), and it
is expired/revoked, no OCSP response is available.  Presumably, clients
would simply not accept connections from a host offering such a certificate.

So what does this signature add?

Performance-wise, at worst it's an additional secret key operation per
TLS handshake, but the same signature could be cached and reused until
the next scheduled OCSP or STH fetch, which should be minimal.

	--dkg