On 1 October 2014 14:45, Daniel Kahn Gillmor <[email protected]> wrote: > 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?
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). _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
