Subject: Re: [Trans] Proving certificate freshness

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 01 Oct 2014 09:45:43 -0400

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
[email-masked] instead of [email-masked]?

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

---

From: Ben Laurie <[email-masked]>
Date: Wed, 1 Oct 2014 14:59:41 +0100

On 1 October 2014 04:56, David Leon Gil <[email-masked]> wrote:
> of showing that a *server* was behaving incorrectly. E.g., as a TLS
> extension:
>
> struct {
>   STH;
> Any thoughts?

Interesting idea. Note that even with a colluding log, predicting a
future STH is tricky, since the log has to include any certs it's
signed SCTs for within the MMD...

---

From: Ben Laurie <[email-masked]>
Date: Wed, 1 Oct 2014 15:08:37 +0100

> misuse.  Is this scope creep?

It doesn't require anything from CT, though, so not really scope creep
for CT itself.

That said, clearly an append-only log can be used for timestamping
directly, so if people think this is a good idea, then it could be
implemented using a log that, say, issues a timestamp for certs
periodically - and you require from the server a reasonably fresh
timestamp.

However, if you're prepared to modify servers, then you might as well
go the whole hog and implement revocation transparency, which would
make it impossible to use a revoked certificate from some short-ish
time after revocation.

Outline protocol: server periodically goes to an RT server and gets
proof of non-inclusion in the list of currently revoked certificates
(this proof would use a verifiable map, as documented in
http://www.links.org/files/RevocationTransparency.pdf - note that our
current thinking on verifying maps is you have a CT-like log of state
changes, which the verifiable map is required to be consistent with,
rather than maintaining a log of root hashes as suggested in that
paper).

---

From: David Leon Gil <[email-masked]>
Date: Wed, 1 Oct 2014 10:40:56 -0400

> make it impossible to use a revoked certificate from some short-ish

Generally agreed; the proposal is mainly intended as a stop-gap until
then. It doesn't require any new transparency server infrastructure.
(It also is essentially free gossip about STHs for clients.)

> note that our

This seems an improvement. Could this log be integrated with CT
issuance logs? (That is, have a single "certificate event" log?)

Also, a question about RT: Why not require all RT logs to be
identical? That is, simply require that they reach consensus on a
tree-head hash. (This requires using, e.g., an order on (domain,
time), of course.)

(Perhaps this came up in the early days of CT design, but I wasn't
able to find discussion of it.)

---

From: Ben Laurie <[email-masked]>
Date: Wed, 1 Oct 2014 16:07:15 +0100

> issuance logs? (That is, have a single "certificate event" log?)

Probably.

> tree-head hash. (This requires using, e.g., an order on (domain,

It doesn't seem like a particularly useful thing to do, and it
obviously adds a lot of complexity. In fact, Akamai had an interesting
suggestion around pools of logs which may not have quite identical
contents...