*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.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
