Subject: [Trans] comments on section 1

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Jun 2014 12:14:58 -0400

*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."