Subject: [Trans] Section 3 + 3.1 comments

From: Stephen Kent <[email-masked]>
Date: Thu, 26 Jun 2014 12:20:13 -0400

*Section 3*

Much of this section also should be moved to a normative appendix, as it 
describes details that are critical for interoperability, but which may 
distract a reader from gaining a solid understanding of the CT design.

In this section the term log often refers to both a data structure and 
to the entity responsible for operating the logging service. I suggest 
using the phrase "log operator" for the second meaning, for clarity, 
throughout the document.

The section begins by stating that "Anyone can submit certificates to 
certificate logs for public auditing; ..." Why is this a requirement? 
It's easy to see why a certificate Subject or the issuer of a 
certificate may wish to get an SCT. But why is it important for anyone 
to be able to do so? I think this requirement should be explained, 
preferably before this point in the document. (If a certificate could be 
submitted only by its issuers or by the Subject of the certificate, a 
log operator might be able to require a signed challenge/response as 
part of submission, and thus reject what might be a DoS attack.)

A log operator MUST return an SCT "immediately." Is there a reasonable 
way to bound "immediately?" A MUST with such an imprecise description of 
a requirement is worrisome.

The term "Maximum Merge Delay (MMD)" is introduced here, and cited in 
four other places. But, I didn't find an indication of how a log 
operator conveys to clients the MMD for a given log. What is the plan 
for making this information available to clients? (Also, will this 
document, or some other document, provide guidance for log operators 
with respect to suitable MMD choices?) Might the MMD become part of the 
STH? Also, the term "Auditor" is used here. A forward reference to the 
description of what an Auditor does should be included, or a back 
pointer to the definition of the term if a terminology section is added 
earlier.

Again, the text uses the future optimistic tense when it says that "... 
clients MUST reject certificates that do not have a valid SCT for the 
end-entity certificate." (I am not concerned by the mandate for servers 
to include an SCT because a CT-enabled server will send this information 
only if a CT-enabled client asks during the handshake.) Also, the 
wording here is confusing. How about: ""... a client MUST reject an 
end-entity certificate that does not contain or is not accompanied by a 
valid SCT."

Precisely which checks is a TLS client required to perform with respect 
to an SCT? Presumably it checks the signature on the SCT (using the 
public key for the log in question), decodes the SCT, checks the syntax, 
and then performs a comparison between the certificate being verified 
and the SCT signed entry. Is this correct? I think there is a need for a 
subsection that describes exactly what a TLS client does with an SCT. 
That text will need to deal with the simple end-entity certificate and 
stand alone SCT case, as well as the more complex cases involving an SCT 
computed on a pre-certificate, which may be an end-entity certificate or 
an intermediate CA certificate. It also needs to discuss how a client 
maps a LogID to a log pubic key, etc.

There is a sentence here about how an Auditor can verify that a 
certificate was added to the log within the MMD. This probably should 
appear in the discussion of what an Auditor does, either in lieu of this 
mention, or in addition to it. (The description of the Auditor in 5.4 is 
very, very vague, so it needs this sort of concrete functional 
description. And, it might be better to use some normative text, e.g., 
make the MMD check a MUST or SHOULD.)

The final sentence/paragraph of this section says "Log operators MUST 
NOT impose any conditions on retrieving or sharing data from the log." 
That leaves open the question of whether a log operator can discriminate 
when accepting requests to create log entries (i.e., generate an 
SCT).The next section suggests that a log operator is allowed to 
discriminate, i.e., it may choose to accept certificates issued by only 
some TAs. A quick rationale for this asymmetric, mandated aspect of log 
operator behavior would help here.

*Section 3.1 *

This section begins by repeating the opening sentence from 3, which 
seems redundant. There is a mandate to "... publish the list of 
acceptable root certificates ..." Section 4.7 describes the message used 
by a client to acquire the list of root certificates accepted by a log. 
This is not what I would call "publishing" the list; it is making it 
available upon request.

The allusion to the "... union of root certificates trusted by major 
browser vendors" may not be appropriate.It begs the question of which 
browser vendors are "major." Also, the term "might" is not a good choice 
for a standard. Each log operator is free to choose which TAs is 
supports, and this document says how clients learn which TAs are 
supported; that's good. If you want to say that you expect most log 
operators to support the set of TAs accepted by the major browser 
vendors, then this sounds like a CABF issue, and a reference to that 
forum seems appropriate. You might even say that you expect the CABF to 
maintain a TA list so that log operators have a central reference point, 
rather than expecting each log operator to analyze the TA list in each 
of the "major" browsers.

The notion of a Precertificate is introduced here. This is a fairly 
complex feature of CT, which seems to make life harder for clients and 
log operators. It sounds like an SCT issued for an existing certificate 
is computed on the TBS part of that certificate, in its entirety. An SCT 
issued from a precertificateis computed over the TBS certificate, minus 
the poison extension, and minus any other SCT's that have been included 
as extensions. Is this correct? It was not entirely clear (to me) from 
the text. Also, if an SCT is to be included as a certificate extension, 
or as an OCSP extension, it's syntax probably should to be defined in ASN.1.

I do worry that a CA may find it difficult to issue a precertificate 
with a serial number and validity interval that is preserved when the 
final certificate is issued, with one ort more SCT extensions. For 
example, the FIPS 140-1 Level 3 HSM we used to sell assigned the serial 
number to each certificate that it signed, a nice security feature that 
would have enabled the DigiNotar folks to detect the attack they 
suffered, and revoke the bogus certificates. If a CA uses an analogous 
HSM capability, it would not be able to create a precerertificat5 and a 
final certificate with the same serial number. There may be other 
examples where analogous problems arise.

A quick explanation of why the specific precertificate design was 
adopted might help readers understand the need for this complexity. 
Also, a more precise description of what certificate fields and 
extensions are signed is needed. For example, it's not completely clear 
whether the serial number and validity interval for the certificate must 
be the same in a precertificate vs. the final, issued certificate. (It 
might be hard for some CAs to make thiswork, given that the 
pre-certificate is not the final, issued certificate.)

It seems that there are two separate reasons for the precertificate 
design. A CA can't know the value of the time stamp or the log operator 
signature that will be in the SCT when the pre-certificate is submitted; 
thus it cannot include an SCT extension in the submitted certificate. 
Also, if a CA wants to include SCTs from more than one log, the problem 
is even worse. This suggests that if the SCT were computed on a subset 
of the fields/extensions in a certificate, it might be possible to 
simplify the overall CT design.

If the SCT signature was computed on a subset of the certificate 
content, a CA could submit that data to one or more log operators, and 
incorporate the resulting SCTs into the final certificate. This would 
avoid the need for some of the precertificate complexity.

For example, in 3.2.2 it appears that an SCT for a redacted 
pre-certificate will not be compared against DNS name data in the 
Subject field (vs. the SubjectAltName extension). If that represents a 
safe exclusion, what other fields might be excluded and still preserve 
the security properties of CT? Why not go back, examine each field of a 
certificate (and the set of standard extensions), and say which ones 
need to be covered by an SCT. This might allow SCTs for certificates and 
precertificates to be processed uniformly (by clients). It might even do 
away with the need for the poison OID, e.g., by not having a CA submit 
the required data as a certificate.

The comment that another data structure might equally well be used for a 
precertificate is inappropriate for a standards track document; this 
document is specifying the format. But, as I noted above, it might be 
good to revisit the precertificate design and ask whether an alternative 
format is needed.

The text notes that the "poison" extension is included to ensure that 
the precertificate is not accepted as a legitimate certificate. It would 
help to explain what class of attacks arise if the precertificate lacked 
that extension.

The text describing acceptable ways to sign the precertificate needs to 
be revised; a certificate is never used to sign anything; the private 
key corresponding to the public key in the certificate is used. You 
might substitute "issued under" for "signed with" to fix this problem.

The text in this subsection says that a log MAY accept certificates that 
do not meet some X.509/PKIX validation criteria, to accommodate "... 
quirks of CA certificate-issuing software." First, it's not clear if the 
provided list of quirks is intended to be complete, or if the list is 
merely illustrative. Second, is accommodating broken CA software 
something that we want to codify in a standards track RFC? Finally, if 
different log operators adopt different policies with respect to what is 
and is not checked in a submitted (pre-) certificate, life becomes 
confusing for submitters. Specifically, a CA or certificate Subject may 
receive an SCT from one log operator, but be rejected by another because 
the latter was more stringent in its checking. That sort of inconsistent 
behavior is something we ought not encourage in a standard.

The parenthetical comment about self-signed certificates and DANE 
suggests that the rationale for their exclusion is "spam." It would be 
good nice to discuss the rationale for excluding DANE certificates in 
greater depth. Also, since the document already said that a log operator 
publishes the list of root CAs for which it is willing to create log 
entries, it would appear that self-signed certificates are already 
excluded on that basis. Please clarify.

In the log entry format discussion, the following sentence appears: 
"Future revisions of this protocol version may add new LogEntryType 
values." I presume this should say that "new versions of the protocol 
may add ..." One ought not revise an existing protocol version to add 
new stuff, right?

The end of this subsection describes the precertificate chain, and says 
that the final certificate in the chain MUST be a root certificate 
accepted by the log. But at the beginning of this subsection the text 
said: "The root certificate itself MAY be

omitted from the chain submitted to the log server." Please reconcile 
these two statements.

The text notes that a Log operator may limit the length of the chains it 
accepts. I agree with Russ that this comment ought to be normative, 
e.g., a SHOULD.I suggest this limit become part of the data returned by 
the Retrieve Accepted Root Certificates message (perhaps renamed)? Any 
entity submitting a certificate chain would presumably want to fetch 
this information before submission, to avoid wasting time.