Subject: [Trans] Comments on Section 5

From: Stephen Kent <[email-masked]>
Date: Thu, 03 Jul 2014 12:01:14 -0400

*Section 5 *

This section discusses the different types of clients in the CT 
ecosystem. Saying that this section describes "typical" clients is 
rather open-ended, illustrative vs. normative. I suggest this section 
say that it enumerates the current set of clients that CT was designed 
to support, and note that other types of clients may be defined in the 
future.

The admonition that "All clients should gossip with each other, 
exchanging STHs at least;" is not suitable for a standard. First, since 
TLS Clients are an example of clients, this suggestion implies that 
every browser should "gossip" with every other browser. Do you really 
mean that? Also, since no protocol for "gossiping" is defined, this is 
not useful guidance. I suggest all references to "gossiping" be removed 
until the "separate document" mentioned here is written.

*Section 5.1*

The description of "Submitters" should list CAs and Web PKI certificate 
Subjects as the primary examples.

*Section 5.2 *

This section says that "TLS clients are not directly clients of the log 
..." This seems to contradict the statement in 5.4 that says an Auditor 
might be part of a TLS client. Do you really want to exclude TLS 
clients? If so, then there needs to be an explanation of how TLS 
clients, who are the ultimate beneficiaries of CT, become aware of bad 
certificates and reject them in the future. Or, does CT assume that bad 
PR will always deter a CA fro m issuing a bad certificate?

This section states "In addition to normal validation of the certificate 
and its chain, they should validate the SCT by computing the signature 
input from the SCT data as well as the certificate and verifying the 
signature, using the corresponding log's public key." Ought the "should" 
be "SHOULD"? More importantly, I don't recall seeing an algorithmic 
description of how a client matches a received end-entity certificate 
against an SCT(L). Given the variations allowed for SCT data (based on 
an end-entity certificate, end-entity pre-certificate, or 
name-constrained CA certificate) this really needs to be explained, in 
detail. You don't need to provide the algorithm details here; putting 
the details in a normative appendix might be fine.

The text also says "Note that this document does not describe how 
clients obtain the logs' public keys." I think the document does need to 
posit how the public key for a log is obtained, in a secure fashion, and 
how key changes for logs are managed.

*Section 5.3*

The introduction for this subsection says that a monitor "watches for 
certificates of interest" but provides no details of how this is 
effected. Is each certificate of interest defined by a DNS name and 
associated CA, for example? Since this function is not described as a 
MAY, it merits as detailed a description as the correctness checking 
function for which the algorithm is provided.

*Section 5.4 *

This section defines Auditors as taking "...partial information about a 
log as input and verify[ing] that this information is consistent with 
other partial information they have." This description seems too vague 
to be in a standard. A higher level description of what an Auditor does 
is needed, plus a description of what inputs it operates on, and what 
algorithms it uses (at a minimum) to do its job.