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

[Martin Duke via Datatracker <[e-mail]>]

Martin Duke has entered the following ballot position for
draft-ietf-trans-rfc6962-bis-39: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document; I found it very interesting and enjoyed working
through the Merkle Tree algorithms. Some non-blocking comments:

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

- 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.

Which is to say that log IDs should change quite frequently. I'm not very
knowledgeable about the OID hierarchy, but it might be valuable for log IDs to
have enough structure for a given provider to be given one tier of log IDs
(e.g. 1.3.101.80.x.y, where "x" is assigned to an operator via IANA and "y" is
a version number incremented by that operator).

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.

3. One nit: 4.1.1 and 4.1.2 have broken markdown tags.