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