Re: [Trans] Proving certificate freshness

[David Leon Gil <[e-mail]>]

On Wed, Oct 1, 2014 at 10:08 AM, Ben Laurie <[e-mail]> wrote:
> 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.

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
> 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).

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.)