Here are my comments on 6962-bis:
Section 1.
Still no definition of mis-issuance here. Why not use the text I
supplied months ago, and cite the threat analysis document?
There ought to be a mentionof the residual vulnerabilities that arise
when usingname-redacted pre-certificates or wildcard certificates, in
light of the recent discussions. Specifically, the problems Monitors
face in trying to protect a Subject when the Subject’s name is
encompassed by SCTs associated with these certificates.
I thought the WG agreed, long ago, to not mandate behavior for TLS
clients with regard to the presence or absence of SCTs. Yet this section
says
“TLS clients can thus require that all certificates they accept asvalid
are accompanied by signed timestamps.”
which seems to be pretty close to that.
Section 3
The term “preannounce” seems odd. “Pre-register” might make more sense,
given that the action of submission to a log is a form of registration.
Online dictionaries that I queried gave definitions for preannounce that
didn’t seem to be a great match to this activity.
Saying that the submission of a pre-certificatesignifies a binding
intent to issue the certificate is slightly misleading. A CA might not
wind up issuing the associated certificate, for a variety of reasons. I
think it would be better to just drop the word “binding” here.
Section 4
Suggested re-wording:
We define a mechanism to allow these private labels to not appear in
public logs, *while still retaining the security benefits that accrue
from using certificate transparency mechanisms.*
In Section 4.1 wording is used to motivate the need for name-redacted
pre-certificates. It does not say, explicitly, that wildcard
certificates can be logged and used in the CT context. It also should
note the possible problems they represent for Monitors.
Given the recent debate about name-redaction, I’m not convinced that the
description in 4.2.2 provides sufficient detail for Monitors and TLS
clients to know precisely how to compare an SCT for a name-redacted
pre-certificate to a certificate.
RFC 5280 states that name constraints is a critical extension, so the
text in 4.3 conflicts with that RFC.
Section 5
The text still says
Log operators MUST NOT impose any conditions on retrieving or sharing
data from the log.
I asked if Rich’s on-list statement about how Akamai planned to operate
a log was consistent with this mandate, but never received a response.
Section 5.1 should include a statement that the list of trust anchors
accepted by a log is part of the log’s metadata.
Section 5.3 allows a log to create it’s own OID, instead of using one of
the log ID registries. This seems to allow for collisions, and is not
consistent with the general IETF rationale for creating registries.
The description for log shutdown is much improved from prior version
that I read. However, there are a couple of requirements here that don’t
have an associated explanation of how they can be achieved.
Make it known to clients and monitors that the log will be frozen
Keep the log running until the certificates in all of its entries have
expired or exist in other logs (this can be determined by scanning other
logs or connecting to domains mentioned in the certificates and
inspecting the SCTs served).
Section 8
The opening sentence is 5 lines long, which makes it a bit hard to read.
But, overall, this section is much improved over previous versions.
The description the benefits and disadvantages of the certificate
extensionto carry an SCT mentions inclusion proofs. This may be
confusing to readers, since the extension does not contain an
inclusionproof. It would be better to say that use of this method to
deliver an SCT requires that a TLS client use a different mechanism to
acquire an inclusion proof (and STH).
In Section 8.1 the discussion of collusion between a CA and a log ought
to cite the relevant section(s) of the threat analysis.
Section 9
The transparency information extension MUST be non-critical, for
backward compatibility with TLS clients that are nopt CT-aware.
Note that an OCSP responder may be separate from a CA; the wording in
9.1.1 needs to be revised to reflect that.
What does 9.2 means when it says
When a certificate chain includes such a certificate, this indicates
that CT compliance is required.
Required by what?
Section 10
The opening sentence is not very useful for a standards track document.
It suggests CT lacks a well-defined architecture.
The metadata list in 10.1 seems to omit the set of trust anchors
accepted by the log.
In 10.2.4 the text says “…The client then has to verify …” Did you mean
to say “MUST” here?
The language in 10.2.5 about compliance isn’t very useful, when
separated from the text in 10.2.7. Why have these as two separate
subsections?
The wording in 10.2.7 seems intended to skirt the prior agreement to not
mandate client behavior in the event of amissing SCT. Also, the wording
is sloppy. For example, the text says
In the case that use of TLS with a _valid_ certificate is mandated ...
Certificate _validity_ is defined by 5280 and profiles thereof. Do you
mean to say a _CT-compliant certificate_ here? The same comment applies
to the next bullet which describes what to do if use of a “valid
certificate” is optional. Also, what does it mean for a TLS client to
“not treat the certificate as valid?”
The definition of a Monitor still seems to be wrong, and the recent
debate about name-redacted certificates gives further evidence of that.
I think most folks believe the primary function of a Monitor is to
observe logs to detect when a certificate is logged that is not
consistent with the Monitor’s information about the Subject of the
logged certificate. The definitionof a Monitor provided here makes this
function optional. It attributes to a Monitor a function that is, I
believe, a function of Auditing.
The text here is not very precise in describing Monitor behavior re
looking for log entries that conflict with certificates the Monitor is
trying to protect. I suggest using text from
draft-kent-trans-monitor-auditor-01.txt. For example:
A Monitor observes a set of logs to detect certificate mis-issuance. A
Monitor notifies a Subject [CA-Subject] when a bogus (orerroneous)
certificate [draft-ietf-trans-threat-analysis] has been issued on behalf
of that Subject. Every CT-aware Subject is expected to either perform
self-Monitoring or to arrange with a third-party Monitor to detect
mis-issued certificates on behalf of the Subject.
Similarly, the description of how a Monitor does its job seems to omit
what I believe is its critical function. Again, the cited I-D above
provide a concise description in its introduction:
A Monitor performs its function by examining all entries from a set of
logs and comparing these entries to reference data for a set of one or
more Subjects. The reference data consists, at a minimum, of a list of
Subject and Subject Alternative Names and the pubic key information
associated with each, supplied by the Subject. If a Monitor detects a
log entry for a certificate that is inconsistent with the reference data
for a Subject, the Monitor notifies the Subject. A Subject may perform
self-monitoring.
Overall, this section seems inadequate as a description of Monitor
functionality.
Section 10.4 describes audit functions reasonably well, but presents a
view that there is no separate Auditor function in CT. That conflicts
with the design in draft-ietf-trans-gossip-02, and with
draft-kent-trans-monitor-auditor-01. I suggest that the first paragraph
of this subsection be reworded to characterize the Audit function as one
that may be performed by a client, Monitor, or by a separate entity.
This subsection also ends with a statement not appropriate for a
standard track document, as I have noted before:
The following algorithm outlines may be useful for clients that wish to
perform various audit operations.
The statement above should be revised to _require_ that an element
performing the Audit function MUST perform all of these checks in a
fashion that produces results identical to those that the algorithms
would yield. If the document doesn’t establish these algorithms as
authoritative it is not defining what the Audit function is, and the
text is not a very useful part of a standards track document.
Section 11
The last sentence here probably ought to be:
Certificates in the frozen log that have not yet expired and require new
SCTs _SHOULD_ be submitted to the new log and the SCTs from that log
used instead.
Section 13
The introduction text here is good, but it should be augmented with a
discussion of the problems for Monitors posed by wildcard and
name-redacted certificates (if the latter feature is retained). A
reference to the threat document also would be appropriate here, rather
than as a separate, trivial subsection (13.7). I suggest deleting that
subsection.
13.1 says that a TLS client _may_ (lowercase) decide to reject a
certificate w/o an SCT. This language is rather squishy compared to the
strict language in 9.2.
13.2 should refer to Monitors (10.3) as the entities that detect
mis-issuance. Monitors might be domain owners, as suggested, or CAs, or
third parties, but the text here mentions only the 1^st example.
13.3 notes an important consideration, and its advice to CAs is good.
Saying that clients may make a decision to reject such certificates
underlines the potential for interoperability problems. I guess that’s
OK for a statement in an SC section, but it seems a bit vague.
I note that 13.4 refers to a trusted Auditor, which conflicts with the
characterization of Auditing in Section 10. Making the chnges I suggest
to section would address this issue.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
