Subject: [Trans] comments on Sections 3.5 + 3.6

From: Stephen Kent <[email-masked]>
Date: Tue, 01 Jul 2014 13:23:30 -0400

*Section 3.5 *

This section defines the hash algorithm for the Merkle Tree as SHA-256. 
Is there a plan for agility for this algorithm? If so, what is it? If 
not, why not? Also, this section contains the confusing phrasing re 
version number: "Future revisions of this protocol version may add new 
MerkleLeafType types." Presumably the intent is to say that future 
versions (not revisions of this version), may add new leaf types.

*Section 3.6 *

This section defines the Signed Tree head data structure. The data 
definitions don't make it clear that the version number is an integer 
(vs. the string "v1") not is the format of the timestamp obvious.

The end of this subsection says "Each log MUST produce on demand a 
Signed Tree Head that is no older than the Maximum Merge Delay." This 
makes it sound as though a log operator has to generate an STH whenever 
one is requested by any client. The description in 4.3 suggests that a 
log operator generates STHs when it wants (within the MMD interval), and 
sends the most recent one in response to a request for an STH. I assumed 
that a log operator would generate an STH on a periodic basis, as 
described at the beginning of Section 3, and provide that STH to every 
client until a new STH is generated. Please clarify the wording here.

Why isn't the MMD encoded in the STH, so that and Auditor can determine 
whether a log operator is adhering to its advertised MMD? Another option 
might be to adopt the CRL (v2) model, and have each STH include the 
time/date when the next STH will be published. Just a thought.