*Section 3.4 *
This section describes how a server conveys SCT data to a client during
the TLS handshake. It explicitly refers to SCT data only for an
end-entity certificate, in apparent conflict with the option to log a
name-constrained or redacted CA certificate, as per Section 3.2.3.
Please reconcile this text with that in 3.2.3. (Also, the "must" in the
first sentence of the first paragraph of this section should be a
"MUST", right?) Also, this requirement needs to be stated in context,
i.e., a CT-enabled TLS server that has received a Client Hello that
includes ..."
This section introduces the notion that one can convey SCT data via
OCSP. It's very late in this document to introduce a third way to convey
SCT data. This use of OCSP should be mentioned in the introduction; any
other places in the document that refer to conveying SCT data also need
to be modified to note this third option. Introducing the format for
OCSP transport of SCT data at this juncture seems out of place. This too
might better be collected in a normative appendix (and the OID changed
to one from an IETF-managed arc.)
The text in this subsection says: "At least one SCT MUST be included.
Server operators MAY include more than one SCT." A operator of a web
server cannot include multiple SCTs in an OCSP response; only the OCSP
server can do this. Thus the wording above is potentially confusing with
respect to which "server" is being discussed.
Describing the SCTL here also seems out of place. The text says that the
use of the "serialized TLS structure" to convey SCTs enables a
CT-enabled client to decode each SCT independently, e.g., skipping over
SCT versions that it does not support. I think this statement needs to
be supported by a detailed processing description of an SCTL by a client.
This subsection states that clients MUST support all three mechanism for
conveying SCT data; whereas (web) servers need support only one of their
choosing. Again, this imposes a bigger burden on clients vs. servers.
This design decision should be explained here.
The subsection ends with the following guidance: "TLS servers should
send SCTs from multiple logs in case one or more logs are not acceptable
to the client (for example, if a log has been
struck off for misbehavior or has had a key compromise)." First, do you
want to make the "should" be a "SHOULD"? Second, the text suggests that
clients will choose which logs to accept, a feature not mentioned
previously. Since selection of log servers may impact which certificates
are accepted/rejected, there needs to be some discussion of what the CT
designers envision with respect to management of the log servers
accepted by users (or by browser vendors). Not saying anything about
this critical element of the design leaves a reader wondering.
There also is no indication how a TLS-enabled web server could decide
which log servers to use, to reduce the likelihood that one or more may
become unacceptable to some set of clients. Absent a lot more
background, it's not clear that this advice is useful. Finally, the
quoted text refers to a log having been "struck off". This seems to be
an implicit statement about a log management interface capability, for a
TLS client user or browser vendor. There should be an explicit statement
about how "bad" or compromised logs are removed from a TLS client,
rather than this indication in a parenthetical phrase given as an example.
*Section 3.4.1*explains how a client notifies a server that the client
is CT-enabled. The text here says "Servers MUST only send SCTs to
clients who have indicated support for the extension in the ClientHello,
in which case the SCTs are sent by setting the "extension_data" to a
"SignedCertificateTimestampList"." This wording seems misleading, since
the SCT data is actually sent via an explicit SCT list, or via a server
certificate, or via an OCSP extension. So, for example, this seems to
suggest that it is an error for a server to send a server certificate
containing an SCT unless the client sends the indicated extension in the
ClientHello. That would seem to pose a problem for servers that have
just one certificate, which contains an SCT extension, right? What is
the intent here?
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
