[Why yes, I did have a printout of trans documents to read on the plane.] In section 2.1, hash function agility has not quite been inserted, since "[t]he output is a single 32-byte Merkle Tree Hash."
In section 3.4.1, "TLS clients that support the extension SHOULD send a ClientHello extension with the appropriate type", is "the appropriate type" ever anything other than "signed_certificate_timestamp"? If not, maybe it's best to just spell it out. The specific contents of the "timestamp" field are only written out in its description in section 3.3, but not in any subsequent descriptions (whether TLS data structures or JSON). Perhaps there should be a small section at the beginning noting that CT represents times as milliseconds since the epoch, ignoring leap seconds, to clarify for all occurrences. In section 4, maybe the extra fields SHOULD be ignored? This seems relevant for interoperability... At the bottom of page 19, should "synchronization" be written out in full? In section 4, describing the "error_code" field, only one generic code is given, but the running text is written as if multiple were provided. Here, and elsewhere, there seems to be inconsistency about whether a colon is used after the hang text for the itemized list. In section 4.1, my comment about the base64-encoded 'extensions' data from the binary codes document also seems applicable here. At the bottom of page 21, the paragraph about avoiding forcing v1 clients to upgrade is a little confusing to me. Perhaps this scenario could be spelled out in more detail to reduce the potential for confusion. In the subsections of section 4, I don't know whether we feel a need to specify that arrays of things are JSON arrays (as opposed to some other sort of array; I'm not really sure what this misreading would look like). I guess it's probably fine to leave it alone. In 4.3, I think the document's convention should have us explicitly say that the tree_head_signature element is base64 encoded. In 4.4, the "Note that no signature is required on this data" seems to only apply to the 'consistency' output, and not the others (since a signature is supplied for them). Probably best to just avoid the pronoun entirely. Also, the description for 'consistency' should be more clear about the order in which the base64 encoding and array creation is performed, just to be sure. The document seems to play a bit fast and loose with claiming that (leaf?) hashes and STHs can be "before" and "after" each other (sometimes written as "<" or ">"). We can compare both the timestamps or the tree size from which a STH is generated, and I think we should be clear about when which (or both!) checks are performed, throughout the document. -Ben (the other one) _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
