Subject: [Trans] comments on Section 3.4

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Jun 2014 10:51:30 -0400

*Section 3.4 *

This section describes how a server conveys SCT data to a client during 
the TLS handshake. It explicitly refers to SCT data only for an 
end-entity certificate, in apparent conflict with the option to log a 
name-constrained or redacted CA certificate, as per Section 3.2.3. 
Please reconcile this text with that in 3.2.3. (Also, the "must" in the 
first sentence of the first paragraph of this section should be a 
"MUST", right?) Also, this requirement needs to be stated in context, 
i.e., a CT-enabled TLS server that has received a Client Hello that 
includes ..."

This section introduces the notion that one can convey SCT data via 
OCSP. It's very late in this document to introduce a third way to convey 
SCT data. This use of OCSP should be mentioned in the introduction; any 
other places in the document that refer to conveying SCT data also need 
to be modified to note this third option. Introducing the format for 
OCSP transport of SCT data at this juncture seems out of place. This too 
might better be collected in a normative appendix (and the OID changed 
to one from an IETF-managed arc.)

The text in this subsection says: "At least one SCT MUST be included. 
Server operators MAY include more than one SCT." A operator of a web 
server cannot include multiple SCTs in an OCSP response; only the OCSP 
server can do this. Thus the wording above is potentially confusing with 
respect to which "server" is being discussed.

Describing the SCTL here also seems out of place. The text says that the 
use of the "serialized TLS structure" to convey SCTs enables a 
CT-enabled client to decode each SCT independently, e.g., skipping over 
SCT versions that it does not support. I think this statement needs to 
be supported by a detailed processing description of an SCTL by a client.

This subsection states that clients MUST support all three mechanism for 
conveying SCT data; whereas (web) servers need support only one of their 
choosing. Again, this imposes a bigger burden on clients vs. servers. 
This design decision should be explained here.

The subsection ends with the following guidance: "TLS servers should 
send SCTs from multiple logs in case one or more logs are not acceptable 
to the client (for example, if a log has been

struck off for misbehavior or has had a key compromise)." First, do you 
want to make the "should" be a "SHOULD"? Second, the text suggests that 
clients will choose which logs to accept, a feature not mentioned 
previously. Since selection of log servers may impact which certificates 
are accepted/rejected, there needs to be some discussion of what the CT 
designers envision with respect to management of the log servers 
accepted by users (or by browser vendors). Not saying anything about 
this critical element of the design leaves a reader wondering.

There also is no indication how a TLS-enabled web server could decide 
which log servers to use, to reduce the likelihood that one or more may 
become unacceptable to some set of clients. Absent a lot more 
background, it's not clear that this advice is useful. Finally, the 
quoted text refers to a log having been "struck off". This seems to be 
an implicit statement about a log management interface capability, for a 
TLS client user or browser vendor. There should be an explicit statement 
about how "bad" or compromised logs are removed from a TLS client, 
rather than this indication in a parenthetical phrase given as an example.

*Section 3.4.1*explains how a client notifies a server that the client 
is CT-enabled. The text here says "Servers MUST only send SCTs to 
clients who have indicated support for the extension in the ClientHello, 
in which case the SCTs are sent by setting the "extension_data" to a 
"SignedCertificateTimestampList"." This wording seems misleading, since 
the SCT data is actually sent via an explicit SCT list, or via a server 
certificate, or via an OCSP extension. So, for example, this seems to 
suggest that it is an error for a server to send a server certificate 
containing an SCT unless the client sends the indicated extension in the 
ClientHello. That would seem to pose a problem for servers that have 
just one certificate, which contains an SCT extension, right? What is 
the intent here?