On 1 October 2014 15:40, David Leon Gil <[email protected]> wrote: > 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?)
Probably. > 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.) 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... > > (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
