Subject: [Trans] Comments on Sections 3.2 and 3.3

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

*Section 3.2*

This section discusses how to accommodate an enterprise that wants 
(end-entity) certificates issued by its own CA to be accepted by 
CT-enabled clients, but does not want these certificates to appear in a 
(publically-accessible) log. The words used here are not as clear as I 
think they could be. Also, is it true that the only context in which the 
mechanisms defined here are applicable is that of a CA certificate 
issued to an enterprise? Do governments count as enterprises?

*Section 3.2.1*seems intended to explain why logging a wildcard 
certificate is not a general solution to the problem. If that's the 
intent, the text should say so more clearly.

*Section 3.2.2*introduces a mechanism to enable a pre-certificate to be 
logged while redacting one or more DNS domain labels. The intent is to 
cause CT-enabled clients to accept a certificate with a DNS-ID that 
matches the non-redacted portion of the log entry, and that contains 
exactly as many labels as this newly-proposed extension indicates have 
been redacted. The text here notes that DNS labels in a CN-ID are not 
redacted. An explanation for this exclusion should be provided. The 
proposed literal string uses parentheses, which are not part of the 
usual ASCII character set for DNS labels (as per RFC 1034), although RFC 
4343 notes that DNS labels may be any octet value. Also, DNS labels are 
compared as case insensitive values when used in the DNS, but IA5 
strings are case sensitive. So "PRIVATE" may confuse folks, and add to 
the complexity of this part of the specification.

*Section 3.2.3*states that it's OK to log a CA certificate (or 
pre-certificate) if that certificate is name constrained in a specific 
fashion. I think this is the first place where the document indicates 
that a CA certificate, vs. an end-entity certificate, is a valid log 
candidate. It's very late in the document to introduce this exception. A 
brief discussion of why this exception does not undermine the CT 
security model belongs here. The introduction section should to be 
changed to note this exception up front.

*Section 3.3 *

This section defines the structure of the SCT. Since this is a data 
structure that will be signed, the structure requires a canonical 
representation. Is there no need for a canonical encoding spec for the 
data notation used here? RFC 5246 was cited as the data structure 
reference in Section 1.2, but that RFC does not seem to explicitly 
define a canonical encoding. Also, the RFC says that the notation 
defined there is for use in TLS, exclusively. An SCT exists outside of 
TLS, e.g., it can be embedded in a certificate. So, why is that notation 
used here? As I noted earlier, it might be preferable to use ASN.1 for 
the SCT, if an SCT is to be carried in a certificate and/or OCSP extension.

The text says that "the entry_type may be implicit from the context in 
which the SCT is presented." Does this mean that he entry type may be 
omitted from the SCT structure? Please clarify.

Since version 1 of the SCT format does not define any extensions, it's 
not clear why there is an extensions field present in this version. The 
text says that "... future extensions to this protocol version (v1)" are 
to be carried in that field; that seems very odd. Was the intent to say 
that future versions of the SCT may have extensions defined? If so, then 
the extensions data element will appear then. It does not seem to be 
appropriate to include it now.