Re: [Trans] Martin Duke's No Objection on draft-ietf-trans-rfc6962-bis-39: (with COMMENT)

["Salz, Rich" <[e-mail]>]

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.