*Section 2*
I suggest that most of Section 2 might be placed in an appendix. The
details of hash trees will not be of interest to most readers, and
having a lot of text in this document devoted to those details may
distract many readers. The details are critical to ensure
interoperability and security, but a high level description of Merkle
hash trees, audit paths, consistency proofs, etc. would suffice to
explain to most readers how CT works. Moving details to a normative
appendix would make the document easier to read.
Section 2.1.4 says that a log operator MUST use one of two specified
signature algorithms with SHA-256. This implies that all clients MUST
support both algorithms. I think it's important to justify this
requirement, i.e., why are all clients forced to support both
algorithms, while log operators get to choose which one they want to
implement? Also, in many (thought not all) recent security area protocol
designs, we have been separating the algorithm specs from the rest of
the design, to accommodate algorithm agility. This document (or a
companion) needs to address algorithm agility, irrespective of whether
the algorithms are included here or elsewhere. I recall that the
algorithm agility topic was raised but deferred in discussions on the
list; I think it needs to be addressed, either here or in a companion
document that is accepted by the WG as an essential element of the CT
architecture. Also, there should be a discussion of how key rollover for
logs is managed, once the topic of how to acquire log public keys is
resolved.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
