Subject: [Trans] comments on draft-ietf-trans-rfc6962-bis-07

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 22 Mar 2015 23:38:30 -0400 (EDT)

[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)