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