*Section 7*
The Security Considerations include some statements that worry me. It
says "If a server presents a valid signed timestamp for a certificate,
then the client knows that the certificate has been published in a log."
This is not quite true, since the certificate may be published later, or
never at all. Please try to be more precise here.
It also says "...the client knows that the subject of the certificate
has had some time to notice the misissue and take some action, such as
asking a CA to revoke a misissued certificate."Since the client doesn't
know, with certainty, that the Subject is monitoring for mis-issuance,
the client can't know how long it may be before the mis-issuance may be
remedied. The statement here needs to note that a client cannot assume
how long it may be before mis-issuance problems are detected and
remedied. The last sentence of the first paragraph of this section does
a good job of noting these limitations, but its message is diluted by
the preceding statements.
The final paragraph is good, although "transparency" may be too much of
a euphemism! The lack of a discussion of various scenarios with respect
to how mis-issuance may occur (see my comments on the Introduction)
makes it harder for a reader to understand the ways that CT is intended
to address the problem of certificate mis-issuance. Itmight be
appropriate to compare CT to key pinning
(draft-ietf-websec-key-pinning-17.txt) , for example, since both
mechanisms attempt to deal with some of the same attacks.
*Section 7.1*provides a good explanation of how MMD fits into the CT
scheme. But it begins with an absolute statement about TLS clients
rejecting certificates w/o an SCT. Absent a discussion of how to address
partial deployment, the first sentence does not seem reasonable.
*Section 7.3*seems to offer a warning that some examples of redacted
names could be dangerous, but it provides only a couple of examples.
Without a more precise definition of what constitutes a dangerously
"overly redacted" precertificate, the warning here is not adequate. The
statement "TLS clients MAY reject a certificate whose corresponding
precertificate would be overly redacted." seems impossible to implement,
based on the level of specification presented here. (If a certificate is
dangerously over-redacted, and we define what that means, maybe a SHOULD
is more appropriate.) This subsection needs work, and may be indicative
of a serious problem with respect to the security afforded by redacted
precertificates.
*Section 7.4*describes how two forms of log misbehavior can be detected.
The first type of misbehavior is a violation of the MMD. This
description is a bit worrisome as it specifies relying on a "trusted
auditor" (a new term) if a client does not want to reveal what
certificate is of interest. The alternative approach suggested (for a
client that does not want to reveal what certificates are of interest)
is to request proofs for a batch of certificates. A more algorithmic
description of the suggested behavior should be provided, either here or
in Section 5.4 (which probably needs to be re-written anyway), along
with a definition for a "trusted auditor" (or just delete the term
"trusted"). The second type of misbehavior, characterized as violating
the append-only property, is detected by "global gossiping." This is not
a reasonable explanation of a countermeasure, given the lack of any
detailed description of how such gossiping is to take place.
*Section 9*raises an important topic, i.e., key rollover. But saying
that this topic needs to be addressed in the future is worrisome. The WG
needs to decide if it's OK to postpone this critical aspect of the
design to a future document.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
