Eran,
Responses to your edits, below:
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.
Changed.
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.
Would it help to say that for all intents and purposes an observer of
a CT log can assume a CA has intended to issue a certificate denoted
by a precertificate observed in the log?
Yes, that's a good characterization.
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.
I believe the first sentence does. At least, I can't see any
dis-ambiguity here.
Which first sentence? 4.1 begins:
A certificate containing a DNS-ID [RFC6125] of "*.example.com" could
be used to secure the domain "topsecret.example.com", without
revealing the string "topsecret" publicly.
This says nothing about the ability to log such a cert. It just says
that such a cert can be issued by a CA without revealing the domain
names represented by "*".
The next paragraph provides further rationale why a redacted name cert
is desirable, but, again, it does not say that q wildcard cert can be
logged. It cites RFC 6125, which tells TLS client (not just CT-aware TLS
client) how to match a wildcard cert to a DNS name in a cert.
Both of the cited texts do what I said, i.e., they are providing
rationale for redacted name certs, without stating, explicitly, that
wildcard certs are legitimate for submission to logs.
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.
That's likely to change with the simplified redaction suggestion.
agreed.
RFC 5280 states that name constraints is a critical extension, so
the text in 4.3 conflicts with that RFC.
Seeking feedback here - one possible option is to remove the 'critical
or non-critical' part of the sentence.
yes, removing that would address the issue I noted.
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.
IIRC the plan was to restrict submission, that text is about getting
data from logs.
5.1 says that a log MUST accept any cert that meets 5280 and was issued
by one of the trust anchors associated with the log. I'm still not
certain that matches what Rich indicated, but I may be mistaken.
Hopefully Rich can clarify, and address the submission vs. retrieval
constraints question at the same time.
Section 5.1 should include a statement that the list of trust
anchors accepted by a log is part of the log’s metadata.
What is the goal behind such a statement? I'm failing to see what it
would add to the reader (it's already mentioned that the list can be
obtained by calling get-anchors).
Whoops, I missed that interface when it was added in ver 12. sorry.
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.
How about the following text as the first sentence:
Each log is identified by an OID which MUST be unique.
That's clearly the goal, but why not mandate use of one of the two
registries? The primary reason for creating an IANA registry is to help
ensure uniqueness for IDs in a fashion that promotes, dare I say,
transparency :-).
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).
You're right - they depend on the metadata dissemination mechanism,
which isn't currently specified.
It think it's more of an issue than what I have complained about
previously. The first requirement mandates a way to contact every TLS
client. I presume that the intent is that this will be done by having
browse vendors make changes in config data that is made available to
users. Studies have shown that it may take a long while for users to
update to new versions of browser software. Also if one argues that CT
TLS Clients are not just browsers, but any users of TLS, then the
mechanism for distributing log metadata includes OS vendors too. Thus it
seems appropriate to declare, in this doc, what mechanisms are assumed
to achieve the stated requirements. Otherwise a reader might conclude
that we're sweeping this hard problem under the rug. perhaps this is a
topic to be discussed in the Security Considerations section. finally,
re-reading 5.11, I see these are just "suggested" actions, which means
that, again, we have no standard's-level description of what it means
for a log to safely shut down.
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.
Inclusion proofs can be included in the extension since an inclusion
proof is a particular type of TransItem and the extension carries a
list of TransItems.
It is not immediately obvious, though, so if you point to a particular
area of the text where this can be clarified I'll try to add some text.
Looking at section 5, 5.1, 5.2, and 5.3 mandate log support for the
structures defined in these subsections. For 5.4 (TransItem) I see no
MUSTs. So, it appears that log support for this structure is optional,
at best (though I didn't see a MAY here either). Text in 5.8 mandates
support for returning an STH, but consistency and inclusion proofs
don't seem to have any MUSTs. I think Section 5 needs to be revised to
ensure consistent treatment of what you guys feel are really mandatory
log interfaces and data types.
...
The transparency information extension MUST be non-critical, for
backward compatibility with TLS clients that are nopt CT-aware.
Done.
Note that an OCSP responder may be separate from a CA; the wording
in 9.1.1 needs to be revised to reflect that.
Can you suggest text? It'll help understanding in which way the
separation between CA and OCSP responder is important in the CT context.
_An OCSP responder_ MAY include a Transparency Information
X.509v3 extension in the "singleExtensions" of a "SingleResponse" in
an OCSP response.
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?
By the TLS feature extension. Andrew Ayer has suggested text to
clarify it which is under review
(https://github.com/google/certificate-transparency-rfcs/pull/173).
I looked at the page that the URL displayed and didn't see any text that
seems relevant to my question. is 9.2 trying to say that IF a CA
includes the indicated extension in its TA or an intermediate CA cert,
THEN a TLS client MUST reject any subordinate EE cert if there is not a
corresponding SCT, IF the client recognizes the extension? If that's the
intent, please say so directly. Also, why is this extension described as
SHOULD be non-critical? Under what circumstances ought as CA mark it
CRITICAL?
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?
Seems to me it follows from the protocol - if the client doesn't do
it, then it has no guarantee of inclusion (same as if it didn't check
the inclusion proof at all).
The phrase "has to" is not a substitute for MUST in a standards track
RFC. It's just a matter RFC style/clarity.
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?
How do you suggest merging the two?
I suggest a simple merge, removing redundant text:
A certificate not accompanied by any valid SCTs
MUST NOT be considered compliant by TLS clients.
If a TLS server presents a certificate chain that is non-compliant,
there are two possibilities.
o In the case that use of TLS with a valid certificate is mandated
by explicit security policy, application protocol specification,
or other means, the TLS client MUST refuse the connection.
o If the use of TLS with a valid certificate is optional, the TLS
client MAY accept the connection but MUST NOT treat the
certificate as valid.
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?”
I agree - wording was somewhat vague here, so I re-wrote this section.
see the pull request for the change.
...
The detailed description of monitors' operation in the threat analysis
document is very suitable and for this reason would like to keep the
section about monitors very brief.
I fear you may be confusing the threat analysis text with the text in
draft-kent-trans-monitor-auditor-01.txt. the text in the threat analysis
doc does not define the Monitor function in the requisite detail.
Additionally, the text describing Monitors here is not just brief, it's
in conflict with the way that several of us have said what we believe a
Monitor does.
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.
I agree that an element performing auditing must perform these checks
in a fashion that produces results identical to those that the
algorithms would yield.
I'm not sure how effective it would be to require it in the document
though - if the algorithm is wrong it would produce incorrect results,
no meaningful audit has been performed.
if the alg in this section is wrong it has no place in a standards doc
;-). The point of this doc is to define the functionality and behavior
of all elements of CT, right? If one cannot provide a definitive
description of required behavior for an element of a system, then one
has failed to specify it in enough detail to be part of a standard.
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.
Changed.
thanks.
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.
IIUC you suggest moving the reference to the threat analysis document
from 13.7 to the introduction in 13. I've made that change.
Re wildcard and name redaction, wouldn't a discussion on the threats
posed by those be more appropriate in the threat analysis document?
The introduction text is very general and it does not seem appropriate
to me to discuss wildcards/redacted names here.
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.
Removed that sentence.
thanks.
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.
I've tried fitting that in and it felt like fitting a square peg in a
round hole. There's already a section about monitors and it should be
straightforward to figure out how to watch a log for certificates of
interest.
If it's trivial, it should be easy to state in a few sentences. I note
that only recently did the WG become aware of the problems faced by
Monitors when trying to match redacted certs to reference data. So added
detail does seem to be needed, even if we have a new design for redacted
certs.
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.
How does it conflict? I agree it's a bit terse to say a client can
hand over observed SCTs to a trusted auditor, but I don't see the
conflict.
The conflict is that the gossip I-D has an auditor as an essential,
distinct function in the system. 6962-bis states "Audits are performed
by monitors or TLS clients." which suggests that there is no separate
Auditor. That is a conflict.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
