Subject: [Trans] Comments on Section 2

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Jun 2014 21:45:30 -0400

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