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