*Section 1*
The informal introduction seems too informal in places J. And there
appears to be no more formal introduction later, so I have a number of
suggestions for this section.
It might be better if this section began with a description of the
problem of Web PKI certificate mis-issuance. (The mechanisms are clearly
focused on the Web PKI environment, so the problem should be described
in that context.) For example, one might say that mis-issuance may arise
due to an error by a well-meaning Web PKI CA, or as a result of an
(undetected) attack on such a CA (c.f., DigiNotar), or as a result of
malfeasance by a not-so-well-meaning CA. An analysis of how CT is
expected to effectively address each of these three different forms of
mis-issuance would help readers understand why CT is a good idea. That
analysis could appear in the Security Considerations section, or maybe
an appendix.
I agree that CT is potentially more generally applicable than just the
Web PKI and browsers, but it behooves us to describe a comprehensive
solution for the context that has motivated CT development, before we
addresses others. I suggest this document not mention broader
applicability. We can re-charter and produce other documents when we get
to that point.
If the abstract text I offered above is not suitable for this document's
abstract, maybe it, or some variant thereof, could be appear near the
beginning of this section.
"Correctness" of log operation is not defined here. It is discussed to
some extent in the description of Monitor operation (Section 5.3). I
suggest a forward pointer to that section. The focus here is on
independent verification of log correctness. That seems to be a
secondary matter; the first goal of the logs is to enable Subjects and
RPs to determine if a certificate has been logged, right? Verifying that
logs are being operated correctly is important only because of the
primary goal of the logs. So, the 1^st paragraph here seems to place the
log correctness cart before the certificate issuance transparency horse,
so to speak.
The second paragraph of Section 1 begins by saying that anyone can
submit a certificate chain for logging. But it later states that not all
certificate chains may be accepted by every log operator. These two
statement are not contradictory, but they are a bit confusing;
technically anyone can submit a certificate chain but not some
certificate chains that are submitted may not be accepted. This should
be reworded to be more precise.
This paragraph says "Each log consists of certificate chains ..."
Wouldn't it be more accurate to say that each log consists of a set of
log entries; each log entry is a certificate chain. (This might also be
a good place to explain why a log entry is a certificate chain, not just
a certificate.) The entries in a log are grouped into epochs, based on
the frequency at which the log operator issues a Signed Tree Head (STH).
The structure of the log, based on the use of Merkle Trees [provide a
cite, maybe the USENIX reference.], enables third parties to detect
manipulation of a log by a log operator (or an external attacker), thus
reducing the level of trust that clients must place in LOs. (Do you
agree that this is a more precise characterization of a log?)
The second paragraph also talks about "public CAs" but I think "Web PKI
CAs" is a more accurate characterization. (After all, CAs that are
"private" but which make use of the Web PKI are accommodated in Section
3.) The fact that Web PKI CAs and (Web PKI) certificate Subjects can
both contribute certificate chains to logs is noted here, but without an
explanation of why both need to be able to do this. I think readers will
better understand the CT model if the rationale for this dual submission
capacity is explained (especially since CA submissions based on
pre-certificates add considerable complexity).
The text refers to logs being "... spammed into uselessness ..." Since
the certificate chain submission interface is via HTTP, not e-mail, the
term "spam" seems inappropriate. Also, the sentence in which this phrase
appears states that this DoS concern requires that each "chain be rooted
in a known CA certificate." This is only part of the requirement, as
described later, i.e., the root for the chain has to be one acceptable
to the log operator in question. The text would be clearer if the two
separate elements of the anti-DoS design were described, and justified.
Also, there are other attacks that an adversary might employ to effect
DoS against a log. They should be addressed somewhere in this document,
to justify the decision to focus on this one avenue of attack.
The term "clients" is introduced here, without definition. (I didn't
count its use in the abstract since it is common to use terms there
before defining them in the body of an RFC.) Perhaps a terminology
section should be added, where the various classes of clients are
defined, and a forward pointer to that definition could be inserted here.
The end of this paragraph states: "TLS clients can thus require that all
certificates they see have been logged." Later, in Section 3, there is
analogous direction: " ... since certificates will not be accepted by
TLS clients unless logged, ..." and later, using with normative text:
"TLS clients MUST reject certificates that do not have a valid SCT for
the end-entity certificate." And in Section 7.1 the text says "In
addition, if TLS clients will not accept unlogged certificates, ..." (I
assume the first two sentences above are examples of the future
optimistic tense J.) A tricky part of writing this RFC is to accurately
express what one expects of a compliant, CT-enabled TLS client in a
world where not all Web PKI CAs have elected to adopt CT. The RFC should
address this topic up front; this section seems like a good place to
discuss this non-trivial issue.
The introduction should note that a client that implements CT will
inform a server during the handshake, and that a CT-enabled server will
send an SCT only if so informed. (This is described in 3.4.1, but that's
rather late in the document.) But, that alone does not address the
question of incremental deployment with respect to Web PKI CAs and
servers. For example, is the plan to have users or system administrators
specify which CAs, TAs, or web sites MUST provide SCTs? There needs to
be a credible description of how CT will be incrementally deployed. (I
doubt if a flag day would be viewed as credible.)
Separate from the issue of when lack of a valid SCT becomes a basis for
treating a certificate as invalid, the text in this paragraph says that
"all newly-issued certificates" will be logged. Is it really _all
certificates_ that are processed by TLS clients, or only EE (aka "leaf")
certificates (as discussed in Section 3), or name-constrained
intermediate CA certificates, or ...? If we ignore "private"
certificates as described in Section 3.2, it seems that only EE
certificates need to be logged for the mechanism to work. I was just
wondering what the precise requirement is here. Also, I suggest
replacing "they see" with "they accept as valid."
The third paragraph of this section says: "Those who are concerned about
mis-issue can monitor the logs, asking them regularly for all new
entries, and can thus check whether domains they are responsible for
have had certificates issued that they did not expect." This sounds like
the function of a Monitor. If so, then a forward reference to Section
5.3 would make sense, and this would be a good place to introduce the term.
"What they do with this information, particularly when they find that a
mis-issuance has happened, is beyond the scope of this document, but
broadly speaking, they can invoke existing business mechanisms for
dealing with mis-issued certificates." This is an important statement
about one aspect of the means by which CT is intended to remedy
certificate mis-issuance. But, absent an exploration of the different
ways that mis-issuance may occur (see my comment above), this statement
is not very compelling. Perhaps an appendix is needed, in which you
discuss different mis-issuance scenarios and then describe how CT
addresses each of them. That sort of analysis may be needed to convince
readers that CT is a good solution to the mis-issuance problem.
There is a statement here about monitoring and remediation that seems
redundant: "Of course, anyone who wants can monitor the logs and, if
they believe a certificate is incorrectly issued, take action as they
see fit." The previously quoted sentence already says that parties other
that Web PKI certificate Subjects can monitor logs and seek redress, so
what is this sentence intended to convey?
The next paragraph notes that anyone who has received a signed timestamp
_can_ request proof that the certificate in question was, in fact,
logged. The principle recipients of SCTs seem to be TLS clients, so why
not say that immediately? Also, this statement does not make it clear
whether a TLS client MUST perform this check (asynchronously) or if it
is merely optional. If a TLS client never performs the check, it will
not detect a misbehaving log operator. I don't recall seeing a
specification of how TLS clients would acquire information about bad
logs from Monitors, so there does not seem to be a well-defined feedback
path for dealing with this concern. (Stating that anyone who monitor
logs and determines that a certificate has been mis-issued can "take
action as they see fit" does not address this issue.)
The next sentence refers to monitor's (not capitalized?) copies of logs.
The description of a monitor says that it may (MAY?) choose to maintain
a copy of logs that it watches. So, the statement here ought to be
revised to be consistent with the text in Section 5.3 (or 5.3 should be
revised). The next sentence says "The checking operation is asynchronous
to allow TLS connections to proceed without delay, despite network
connectivity issues and the vagaries of firewalls." This seems to
confirm that a TLS client is presumed to be the primary entity checking
that an SCT corresponds to an log entry. But it fails to say what the
client is expected to do if there is no matching log entry. This seems
like an important omission.
This section ends with a paragraph that begins "The append-only property
of each log is technically achieved using Merkle Trees, which can be
used to show that any particular version of the log is a superset of any
particular previous version." Since the term "version" is used
throughout this document to refer to versions of data structures,
perhaps it would, be better to use the term "instance" above. I suggest
the following rewording: "The append-only property of each log is
achieved using Merkle Trees, which can be used to show that every
instance of the log is a superset of every prior instance."
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
