Subject: Re: [Trans] Starting working group last call, draft-ietf-trans-rfc6962-bis

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Jun 2016 13:47:54 -0400

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.

---

From: Eran Messeri <[email-masked]>
Date: Tue, 21 Jun 2016 10:51:19 +0100

Addressed some comments, I've left some un-addressed as I'd like to hear
more feedback about them from the WG.
The changes are here:
https://github.com/google/certificate-transparency-rfcs/pull/174

On Thu, Jun 16, 2016 at 6:47 PM, Stephen Kent <[email-masked]> wrote:

> 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 mention  of the residual vulnerabilities that arise
> when using  name-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 as
> valid are accompanied by signed timestamps.”
>
>
>
Changed.

>
>
> Saying that the submission of a pre-certificate  signifies 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?

> 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.

> pre-certificate to a certificate.
That's likely to change with the simplified redaction suggestion.

>
>
> 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.

>
>
> 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.

> 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).

> 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.

>
>
> 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.
>
>
>
> 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.

> The description the benefits and disadvantages of the certificate extension
> to carry an SCT mentions inclusion proofs. This may be confusing to
> readers, since the extension does not contain an inclusion  proof.
>
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.

> 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.
>
Done.

> 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.

> 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).

>
>
>
>
> 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 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?

> mandate client behavior in the event of a  missing SCT. Also, the wording
> 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
> 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 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
> definition  of a Monitor provided here makes this function optional. It
> attributes to a Monitor a function that is, I believe, a function of
> Auditing.
>
>
>
> Monitor notifies a Subject [CA-Subject] when a bogus (or  erroneous)
> certificate [draft-ietf-trans-threat-analysis] has been issued on behalf of
> that Subject. Every CT-aware Subject is expected to either perform
> what I believe is its critical function. Again, the cited I-D above provide
> a concise description in its introduction:
>
>
>
> 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.
>
>
>
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.

> 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 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.

> SCTs *SHOULD* be submitted to the new log and the SCTs from that log used
> instead.
>
Changed.

> 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
Removed that sentence.

> third parties, but the text here mentions only the 1st 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.

> underlines the potential for interoperability problems. I guess that’s OK
> for a statement in an SC section, but it seems a bit vague.
>
Acknowledged.

> 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.

>
>
>
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 22 Jun 2016 16:06:35 -0400

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.
>
>     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.
>
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.
>
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.
>
>     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.
>
>     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.
>     ...
>     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.
>     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.
>
>     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.
> 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
>
>     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.
>
>      ...
>
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.
>
>     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.
>     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.
>
>     certificate w/o an SCT. This language is rather squishy compared
>     to the strict language in 9.2.
>
> Removed that sentence.
thanks.
>     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 
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