Sorry for losing the original message and therefore the References, etc., headers.
* Thanks for this document; I found it very interesting and enjoyed working * through the Merkle Tree algorithms. You are a glutton for punishment. * 1. I have some concerns about the scalability of this proposal and the Log ID registry. If I understand correctly, there are at least two reasons an operator would choose to shut down their log and start a new one, which requires a new log ID: * - to refresh the signature algorithm and/or key The signature algorithm is unlikely to change until we have to deal with post-quantum signatures, and that is years away. As for the key being rotated, this is not a short-term WebPKI TLS key, but rather a long-term data signing key. So far none of the logs being used (I hesitate to say “in production”) have had to do either. * - As certificates expire and are renewed over time, the log has to retain an ever-expanding listing of useless, expired certificates and chains. While the Merkle tree makes this computationally inexpensive, pruning the storage requirements would require a refresh. Perhaps. But again, it hasn’t happened yet, and there are multiple logs that record all of LetsEncrypt output, all the certs currently found on the Web via crawling, and so on. * Which is to say that log IDs should change quite frequently. As I’ve tried to show above, this seems not to be the case. Certainly none of the logs currently being used have had to do it. (Yes, some used a different ID when going from “practice” to “deployment,” but that’s a different matter.) * 2. Would it be valuable to have a new "certificate revoked" object type in logs that could provide some assurance that entries hadn't been revoked? I can think of some ways this might work, but am not familiar enough with the use cases to say if it'd be valuable. Revocation in the WebPKI doesn’t work; instead clients do OCSP status checks to see if the certificate is still valid. That is a separate problem from what TRANS is doing, knowing if the certificate was properly issued. >3. One nit: 4.1.1 and 4.1.2 have broken markdown tags. Ben Kaduk fixed this. Tnx.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
