On Wed, Oct 1, 2014 at 10:08 AM, Ben Laurie <[email protected]> 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.) _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
