Subject: [Trans] proposed CA/Subject changes

From: Karen Seo <[email-masked]>
Date: Mon, 11 Jan 2016 12:31:37 -0500

Folks,

I agree with the approach discussed on the list of simplifying 6962-bis 
to focus only on specifications for the CT log by moving the detailed 
specifications for other components of the CT system to other documents. 
This is in line with a message from Melinda on July 2 re: client 
behavior, and amessage from Rich Saltz on July 6 re: the Auditor 
function. To facilitate moving requirements for the CA/Subject part of 
the system, I propose that we make the changes below with regard to 
statements about CT requirements for CA and Subject behavior.  These 
changes will also help to address some of the concerns that have been 
cited elsewhere aboutthe text of 6962-bis (e.g., issues 139, 140, 144).

Karen

*_Changes to 6962-bis_*

_/**/_/*Section 3. Submitters*/

    *_From: _*Submitters submit certificates or pre-certificates to logs
    for public auditing, as described below. In order to enable
    attribution of each logged certificate or pre-certificate to its
    issuer, each submission MUST be accompanied by all additional
    certificates required to verify the chain up to an accepted root
    certificate. The root certificate itself MAY be omitted from the
    submission.

    If a log accepts a submission, it will return a Signed Certificate
    Timestamp (SCT) (see Section 5.6). The submitter SHOULD validate the
    returned SCT as described in Section 9.2 if they understand its
    format and they intend to use it directly in a TLS handshake or to
    construct a certificate.

    *_To:_*
    A Submitter sends a certificate or pre-certificate (see Section 3.1
    below) to one or more logs. This enables public monitoring of
    certificates to facilitate detection of certificate mis-issuance. If
    a log accepts a submission, it will return a Signed Certificate
    Timestamp (SCT) (see Section 5.6). This document specifies the
    interface to a log that a Submitter uses to log a certificate or
    pre-certificate (see Section 3). A detailed specification of how a
    Submitter should choose to submit a certificate vs. a
    pre-certificate and how it should process the SCT that is returned,
    will be described in a separate specification to be published later.

/*Sections 3.1 and 3.2*/

    *_From:_*
    3.1. Certificates
    Anyone can submit a certificate (Section 6.1) to a log. Since
    certificates may not be accepted by TLS clients unless logged, it is
    expected that certificate owners or their CAs will usually submit them.

    3.2. Precertificates
    Alternatively, (root as well as intermediate) CAs may pre-announce a
    certificate prior to issuance by submitting a pre-certificate
    (Section 6.2) that the log can use to create an entry that will be
    valid against the issued certificate. The CA MAY incorporate the
    returned SCT in the issued certificate.

    *_To: _*
    3.1 Certificates and Pre-certificates
    Anyone can submit a certificate to a log (see Section 6.1). It is
    expected that certificate owners (Subjects) or their CAs will
    usually submit certificates. Alternatively, (root as well as
    intermediate) CAs may log a certificate prior to issuance by
    submitting a pre-certificate.  The log will use this to create an
    entry and return an SCT that can be used to verify that the issued
    certificate was logged (see Section 6.2). The CA may incorporate the
    returned SCT in the issued certificate.

    /[The rest of 3.2 defines both what the log should accept for a
    pre-certificate and what the CA must do. So it should remain here
    but also be duplicated in a requirements document for CAs. ]/**

/*Section 4 Private Domain Names*/
/**/

    _*From: *_
    Some regard some DNS domain name labels within their registered
    domain space as private and security sensitive. Even though these
    domains are often only accessible within the domain owner's private
    network, it's common for them to be secured using publicly trusted
    TLS server certificates. We define a mechanism to allow these
    private labels to not appear in public logs.

    _*To: *_
    Some organizations regard some of the DNS domain name labels within
    their registered domain space as private and security sensitive.
    Even though these domains are often only accessible within the
    domain owner's private network, it's common for them to be secured
    using publicly trusted TLS server certificates. A detailed
    description of mechanisms that a CA could use to support this will
    be described in a separate specification to be published later.

/*Sections 4.1 Wildcard Certificates, 4.2 */***/Redacting Domain Name 
Labels in Precertificates, and /*/*4.3 Using a Name-Constrained 
Intermediate CA*/**
**

    /[The text in these sections applies only to CAs and should be moved
    to a requirements specification for CAs]/

***/Possible new section/*
**

    If the log checks the syntax of a pre-certificate, then that should
    be described in a new section called something like  "Checking
    Certificate Syntax ."  Any syntax checking done by the CA should be
    put in a requirememts specificatio/n/ for CAs.

/*Section 7 TLS Servers*/
/**/

    *_From:_*
    TLS servers MUST use at least one of the three mechanisms listed
    below to present one or more SCTs or inclusion proofs from one or
    more logs to each TLS client during TLS handshakes, where each SCT
    or inclusion proof corresponds to the server certificate or to a
    name- constrained intermediate the server certificate chains to.
    Three mechanisms are provided because they have different tradeoffs.

    *_To:_*
    A CT-aware TLS server (certificate Subject) can present one or more
    SCTs or inclusion proofs from one or more logs to each TLS client
    during a TLS handshake. (A TLS server is considered to be CT-aware
    if it is configured to send certificates with embedded SCTs or
    inclusion proofs during a TLS handshake, or to convey SCTs
    separately during the handshake.) Each SCT or inclusion proof
    corresponds to the server certificate or to a name-constrained
    intermediate CA certificate to which the server certificate chains.
    The mechanisms by which the TLS server presents the SCTs or
    inclusion proofs to a TLS client will be described in a TLS server
    requirements specification that will be published later.

    /[The rest of 7 and all of 7.1 should be moved to the//above
    mentioned TLS server requirements specification.//]/

/*Section 8 (Certification Authorities), 8.1. (Transparency Information 
X.509v3 Extension), 8.1.1. OCSP Response Extension, 8.1.2. Certificate 
Extension*/**

    /[These sections defines only CA actions/behavior. They should be
    moved to a requirements specification for CAs./*]
    *

/*Section 12.3 (Redaction of Public Domain Name Labels*/

    /[This subsection applies only to CAs.  It //should be moved to a
    requirements specification for CAs.]//*
    */

/**//**//*Section 12.5 Multiple SCTs*/
/**/

    /[This//subsection applies only to CAs and clients. The text should
    be moved to a requirements specification for CAs and a specification
    for browsers.]/**********************

---

From: Melinda Shore <[email-masked]>
Date: Mon, 11 Jan 2016 10:01:21 -0900

We'd be very grateful for some discussion of this so
that we can close it (one way or the other) and move
forward.

Thanks,

Melinda

On 1/11/16 8:31 AM, Karen Seo wrote:
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 11 Jan 2016 19:14:54 +0000

> We'd be very grateful for some discussion of this so that we can close it (one
> way or the other) and move forward.

I'm in favor.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 14 Jan 2016 15:10:57 +0000

On 11/01/16 17:31, Karen Seo wrote:
> Folks,
>
> I agree with the approach discussed on the list of simplifying 6962-bis to focus only on specifications for the CT log by moving the detailed specifications for other components of the CT system to other documents.
<snip>
>     but also be duplicated in a requirements document for CAs. ]/**

I don't see how duplicating text in multiple documents helps the goal of 
"simplifying".

BTW, keeping "the rest of 3.2" would mean keeping section 3.2's 
reference to section 4.2, but...

<snip>
>     to a requirements specification for CAs]/

...you're proposing to move section 4.2 to another document, which would 
be written later.

For -10 of 6962-bis, I spent many hours moving text around so that each 
component of the CT system has its own section in that document, rather 
than all of the requirements for all of the components being mixed up. 
I think that had the effect of "simplifying 6962-bis", and I don't think 
that any further "simplifying" work is necessary.

IMHO, the idea of splitting 6962-bis into a separate doc for each 
component just seems like unnecessary editorial work.

<snip>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Karen Seo <[email-masked]>
Date: Fri, 15 Jan 2016 08:27:46 -0500

Hi, Rob,

     [The rest of 3.2 defines both what the log should accept for a
> I don't see how duplicating text in multiple documents helps the goal 
> of "simplifying".
This is the one place where I felt the text pertained to both the log 
and the CA.  How about if we put the text in the CA document and put a 
pointer in 6962-bis to the CA document?
> reference to section 4.2, but...
Good point.  The above would address this.
> For -10 of 6962-bis, I spent many hours moving text around so that 
> each component of the CT system has its own section in that document, 
> rather than all of the requirements for all of the components being 
> mixed up. I think that had the effect of "simplifying 6962-bis", and I 
> don't think that any further "simplifying" work is necessary.
I appreciate the effort you've made to separate the text by component.  
It does clarify the specification and makes it easier to comprehend.   
It also makes splitting out the text for each component pretty 
straightforward.
> component just seems like unnecessary editorial work. 
There are a number of issues (for the non-log components) that WG 
members have asked be addressed that the existing 6962-bis text doesn't 
cover.   To address these issues we could add text to 6962-bis; but that 
would make a 40+ page document much longer and add to the time it's 
going to take to get 6962-bis out the door. The individual IDs submitted 
so far for the non-log components (CA/Subject , Browser , 
Monitors/Auditors) attempt to cover these issues and average about 10 
pages each, for a total of 30 pages, so far, that would need to be added 
to 6962-bis (assuming that the WG approved the text or something similar.)

Karen

---

From: Melinda Shore <[email-masked]>
Date: Fri, 15 Jan 2016 10:57:44 -0900

On 1/15/16 4:27 AM, Karen Seo wrote:
> cover.

It's becoming extremely difficult to gauge consensus because
we're getting so few comments on these proposals, and I
think we're getting so few comments because it probably seems
to many participants that we (the working group) are being
pecked to death by ducks.  I'm particularly concerned that
we're being asked to do work that is technically correct but
unlikely to be actually helpful to implementers (who, it
should be pointed out, have implementations underway without
these documents).

I am generally skeptical of the value of non-specification
documents, particularly given that we're living in a time
where working group charter proposals are getting scrupulous,
detailed review.  My actual concern, however, is that this is
precisely the sort of thing that is slowing down the production
of implementable specifications and causing palpable harm to the
IETF and to individual working groups.

We have said on some number of occasions that our plan is to
get the -bis document through working group last call and backfill
any parts that are missing.  I'm not seeing a compelling reason
to revisit that decision.  Changes to the -bis draft should
be ones that address problems with the technical correctness
of the existing contents.  Asking the authors to restructure
the -bis draft so that you can produce some other document
does not fall within this framework.

Also, to be clear, we are not going to treat silence as support.
We need review and comments from working group participants.

Melinda

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Jan 2016 21:08:39 +0000

Hi Melinda,

> We need review and comments from working group participants.

Speaking as AD for this wg, I completely agree with you and
with the plan to get the -bis document done soon.

S.

---

From: Karen Seo <[email-masked]>
Date: Tue, 19 Jan 2016 00:03:10 -0500

Folks,
> does not fall within this framework.
I agree that getting the -bis document out soon is desirable/important; 
but I'm concerned by this paragraph.

 1. I did not submit the proposed changes with the goal of producing
    other documents. Re-moving the non-log text from the -bis draft is
    aimed at helping speed the -bis along by removing the topics/text
    where many of "the problems with the technical correctness of the
    existing contents" reside and where more work/review is needed.  The
    idea is to leave in the -bis only the log part of the system because
    this is the part that the WG seems to be the most concerned with
    getting out quickly to the implementers and this is the furthest
    along in terms of completeness/correctness. Irrespective of how the
    "backfill"ing is done -- aonother -bis? other documents? -- removing
    the non-log parts will simplify the -bis and speed its progress.
 2. IMHO, the suggested edits for the CA/Subject text have been pretty
    clearly described and could be done in a short time. I did not
    intend to make a lot of work for the authors and would be happy to
    make these changes if the authors/WG wanted me to do so.
 3. Could the WG please review/consider the drafts on CA/Subject,
    Browsers, and Monitor/Auditor?  These "backfill" many of the missing
    pieces.  Also, putting all the text on a given topic in one place
    should make things easier for the reviewer and eventually for the
    implementer.
 4. IMHO, pushing the -bis document through with "missing parts" and/or
    sections/text that are present but incomplete will be
    confusing/misleading.  It would be better to explicitly note where
    the additional work is needed and to say that the issue will be
    addressed later.

Thank you,
Karen

---

From: Melinda Shore <[email-masked]>
Date: Mon, 18 Jan 2016 20:52:21 -0900

>     should make things easier for the reviewer and eventually for the

If people who've got implementations underway could weigh in
on this, we'd be grateful.  That would include BBN, if you've
got one in development.

Thanks,

Melinda

---

From: Eran Messeri <[email-masked]>
Date: Fri, 22 Jan 2016 11:20:22 +0000

Having reviewed Rob's changes that moved the text relevant to each
component to a separate section, I can attest it makes 6962-bis much
simpler to read. 6962-bis is long, but my opinion it is due to features
added to the protocol we've found necessary when deploying RFC6962.

There's also mention of issues (for non-log components) that 6962-bis
doesn't cover. Can these issues be explicitly stated? The only issue I can
think of is the methods TLS clients, monitors and auditors exchange
information gleaned from the log, and that is addressed by the Gossip
draft. The threat analysis document does an excellent job of describing the
dependency between gossiping mechanisms and the overall security properties
of the protocol, and it is all properly separated from 6962-bis.

>From an implementation perspective, based on a colleague's experience,
having the specification for all components in one place is handy as the
same data structures are used in the TLS client, log and on the CA side
(e.g. both logs and CA client software have to process precertificates).In
particular, moving the name redaction mechanism to a separate document
means it won't be tested as a part of 6962-bis implementation, which is a
bad idea, given it's a completely new functionality in 6962-bis that
pertains to CAs, logs and TLS clients.

I strongly support Melinda's request for comments from people who've got
implementations - at this stage I believe insights from implementations of
6962-bis should guide further changes (aside from the issues already
captured in the issue tracker).

---

From: Stephen Kent <[email-masked]>
Date: Fri, 22 Jan 2016 11:17:38 -0500

Melinda,

> IETF and to individual working groups.
Not sure to which documents you are referring in the paragraphs above.
The threat analysis is not a requirements spec, but it is an 
already-accepted
WG doc and I will post changes to it base on the feedback from Rich and 
Eran.

The architecture doc also is not a requirements spec and it has not been 
adopted by
the WG. However, the comments from Rich and Eran were mostly very 
positive and a new
version of it also will be posted next week, with changes based on their 
comments.

The three docs that Karen, David, and I wrote and posted at the end of 
last year are
requirements specification docs, addressing the CT system elements that 
we feel are not
well-addressed in 6962-bis. They are companions to the architecture doc. 
We have provided
specific, suggested  edits for 6962-bis so that its discussions of 
non-log components
do not use requirements language, leaving that to the three docs that we 
posted. We have
yet to receive comments on these docs; Eran, at the end of his comments 
on the architecture
doc even asked what was preventing us from writing them!

Finally, in response to your query about who is implementing what: BBN 
has explored
design aspects of the Monitor and Auditor functions, as well as browser 
behavior.
In my role as a member of the technical advisory board for Let's Encrypt 
I have
discussed these CT system element design issues with some of the Let's 
Encrypt folks.
They are planning to implement Monitor and Auditor functions. The 
Mozilla folks
with whom I communicate are interested in the browser behavior topics 
that we have
described in our browser/browser-vendor spec.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Mon, 25 Jan 2016 12:00:56 +0000

On 11 January 2016 at 17:31, Karen Seo <[email-masked]> wrote:

> Folks,
>
> I agree with the approach discussed on the list of simplifying 6962-bis to
> focus only on specifications for the CT log by moving the detailed
> specifications for other components of the CT system to other documents. This
> is in line with a message from Melinda on July 2 re: client behavior, and a
> message from Rich Saltz on July 6 re: the Auditor function. To facilitate
> moving requirements for the CA/Subject part of the system, I propose that
> we make the changes below with regard to statements about CT requirements
> for CA and Subject behavior.  These changes will also help to address
> some of the concerns that have been cited elsewhere about the text of
> 6962-bis (e.g., issues 139, 140, 144).
>

The tag "client behaviour" is an unfortunate choice, because it mixes up
various different concerns. The particular concern that was intended to be
separated was what clients do UI-wise in response to the presence of lack
of transparency information.

Other client behaviour, such as following the protocol, is _not_ out of
scope for 6962-bis. Indeed, it seems counter-productive to remove it, since
that's the document implementers have to actually read in order to
implement CT. It makes no sense to define one side of a protocol in one
document and the other in another.

>
>
> Karen
>
> *Changes to 6962-bis*
>
> *Section 3. Submitters*
>
> *From: *Submitters submit certificates or pre-certificates to logs for
> public auditing, as described below. In order to enable attribution of each
> logged certificate or pre-certificate to its issuer, each submission MUST
> be accompanied by all additional certificates required to verify the chain
> up to an accepted root certificate. The root certificate itself MAY be
> omitted from the submission.
>
> returned SCT as described in Section 9.2 if they understand its format and
> they intend to use it directly in a TLS handshake or to construct a
> certificate.
>
> *To:*
> A Submitter sends a certificate or pre-certificate (see Section 3.1 below)
> to one or more logs. This enables public monitoring of certificates to
> facilitate detection of certificate mis-issuance. If a log accepts a
> submission, it will return a Signed Certificate Timestamp (SCT) (see
> Section 5.6). This document specifies the interface to a log that a
> Submitter uses to log a certificate or pre-certificate (see Section 3). A
> detailed specification of how a Submitter should choose to submit a
> certificate vs. a pre-certificate and how it should process the SCT that is
> returned, will be described in a separate specification to be published
> later.
>
>
Clearly this does not pertain to UI and so is in scope.

> *Sections 3.1 and 3.2*
>
> *From:*
> 3.1. Certificates
> Anyone can submit a certificate (Section 6.1) to a log. Since certificates
> may not be accepted by TLS clients unless logged, it is expected that
> certificate owners or their CAs will usually submit them.
>
> 3.2. Precertificates
> certificate prior to issuance by submitting a pre-certificate (Section 6.2)
> that the log can use to create an entry that will be valid against the
> issued certificate. The CA MAY incorporate the returned SCT in the issued
> certificate.
>
> *To: *
> Anyone can submit a certificate to a log (see Section 6.1). It is expected
> that certificate owners (Subjects) or their CAs will usually submit
> certificates. Alternatively, (root as well as intermediate) CAs may log a
> certificate prior to issuance by submitting a pre-certificate.  The log
> will use this to create an entry and return an SCT that can be used to
> verify that the issued certificate was logged (see Section 6.2).  The CA
> may incorporate the returned SCT in the issued certificate.
>
> *[The rest of 3.2 defines both what the log should accept for a
> pre-certificate and what the CA must do. So it should remain here but also
> be duplicated in a requirements document for CAs. ]*
>
>
This change seems fine.

>
> *Section 4 Private Domain Names*
>
> *From: *
> Some regard some DNS domain name labels within their registered domain
> space as private and security sensitive. Even though these domains are
> often only accessible within the domain owner's private network, it's
> common for them to be secured using publicly trusted TLS server
> certificates. We define a mechanism to allow these private labels to not
> appear in public logs.
>
> *To: *
> Some organizations regard some of the DNS domain name labels within their
> registered domain space as private and security sensitive. Even though
> these domains are often only accessible within the domain owner's private
> network, it's common for them to be secured using publicly trusted TLS
> server certificates.  A detailed description of mechanisms that a CA
> could use to support this will be described in a separate specification to
> be published later.
>
> *Sections 4.1 Wildcard Certificates, 4.2 **Redacting Domain Name Labels
> in Precertificates, and **4.3 Using a Name-Constrained Intermediate CA*
>
> *[The text in these sections applies only to CAs and should be moved to a
> requirements specification for CAs]*
>
>
Disagree. Clients need to know how to validate such certificates/SCTs.

>
> *Possible new section*
>
> If the log checks the syntax of a pre-certificate, then that should be
> described in a new section called something like  "Checking Certificate
> Syntax ."  Any syntax checking done by the CA should be put in a
> requirememts specificatio*n* for CAs.
>
>
> *Section 7 TLS Servers*
>
> *From:*
> TLS servers MUST use at least one of the three mechanisms listed below to
> present one or more SCTs or inclusion proofs from one or more logs to each
> TLS client during TLS handshakes, where each SCT or inclusion proof
> corresponds to the server certificate or to a name- constrained
> intermediate the server certificate chains to. Three mechanisms are
> provided because they have different tradeoffs.
>
> *To:*
> A CT-aware TLS server (certificate Subject) can present one or more SCTs
> or inclusion proofs from one or more logs to each TLS client during a TLS
> handshake. (A TLS server is considered to be CT-aware if it is configured
> to send certificates with embedded SCTs or inclusion proofs during a TLS
> handshake, or to convey SCTs separately during the handshake.) Each SCT or
> inclusion proof corresponds to the server certificate or to a
> name-constrained intermediate CA certificate to which the server
> certificate chains. The mechanisms by which the TLS server presents the
> SCTs or inclusion proofs to a TLS client will be described in a TLS server
> *[The rest of 7 and all of 7.1 should be moved to the** above mentioned
> TLS server requirements specification.**]*
>
> *Section 8 (Certification Authorities), 8.1. (Transparency Information
> Extension*
> *[These sections defines only CA actions/behavior. They should be moved to
> a requirements specification for CAs.*
> *] *
>
> *Section 12.3 (Redaction of Public Domain Name Labels*
>
> *[This subsection applies only to CAs.  It **should be moved to a
> requirements specification for CAs.]*
>
> *Section 12.5 Multiple SCTs*
>
> *[This** subsection applies only to CAs and clients. The text should be
> moved to a requirements specification for CAs and a specification for
> browsers.]*
>
>
Disagree with all of these for the reasons mentioned above.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 25 Jan 2016 13:29:25 +0000

On 25/01/16 12:00, Ben Laurie wrote:
<snip>
>         certificates may not be accepted by TLS clients unless logged,
>         it is expected that certificate owners or their CAs will usually
>         submit them.
>
>         3.2. Precertificates
>         Alternatively, (root as well as intermediate) CAs may
>         pre-announce a certificate prior to issuance by submitting a
>         pre-certificate (Section 6.2) that the log can use to create an
>         entry that will be valid against the issued certificate. The CA
>         MAY incorporate the returned SCT in the issued certificate.
>
>         *_To: _*
>         Anyone can submit a certificate to a log (see Section 6.1). It
>         is expected that certificate owners (Subjects) or their CAs will
>         submitting a pre-certificate.  The log will use this to create
>         an entry and return an SCT that can be used to verify that the
>         issued certificate was logged (see Section 6.2). The CA may
>         incorporate the returned SCT in the issued certificate.
>
>         ____/[The rest of 3.2 defines both what the log should accept
>         for a pre-certificate and what the CA must do. So it should
>         remain here but also be duplicated in a requirements document
>         for CAs. ]/**
>
> This change seems fine.

I don't see any advantages to conflating sections 3.1 and 3.2.  Are 
there any?

In -10, I deliberately moved the certificate requirements and 
precertificate requirements into two separate sections.
It's likely that some implementers will have no interest in implementing 
precertificates.  I think that conflating sections 3.1 and 3.2 would 
make it harder for those implementers to figure out which paragraphs 
they don't need to read.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 25 Jan 2016 13:33:32 +0000

On 25 January 2016 at 13:29, Rob Stradling <[email-masked]> wrote:

> I don't see any advantages to conflating sections 3.1 and 3.2.  Are there
> any?
>
> precertificates.  I think that conflating sections 3.1 and 3.2 would make
> it harder for those implementers to figure out which paragraphs they don't
> need to read.

Fair point, it was the wording I was OK with (not that I particularly think
it is needed, though, so I'd also be OK with not making any change).

---

From: Stephen Kent <[email-masked]>
Date: Tue, 26 Jan 2016 11:09:01 -0500

Ben,

>
> On 11 January 2016 at 17:31, Karen Seo <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Folks,
>
>     I agree with the approach discussed on the list of simplifying
>     6962-bis to focus only on specifications for the CT log by moving
>     the detailed specifications for other components of the CT system
>     to other documents. This is in line with a message from Melinda on
>     July 2 re: client behavior, and a message from Rich Saltz on July
>     6 re: the Auditor function. To facilitate moving requirements for
>     the CA/Subject part of the system, I propose that we make the
>     changes below with regard to statements about CT requirements for
>     CA and Subject behavior.  These changes will also help to address
>     some of the concerns that have been cited elsewhere aboutthe text
>     of 6962-bis (e.g., issues 139, 140, 144).
>
>
> The tag "client behaviour" is an unfortunate choice, because it mixes 
> up various different concerns. The particular concern that was 
> intended to be separated was what clients do UI-wise in response to 
> the presence of lack of transparency information.
I agree that the phrase "client behavior" is too broad. But, I also 
think that not all of what
a client does in the lack of valid CT info is strictly a UI issue. For 
example, Eran noted that the architecture doc distinguishes between what 
a client does in the absence of an SCT vs. what
it does if there is an SCT but the sig fails. This, IMHO, is a 
legitimate protocol issue that the
WG has not addressed.  David took a position on this in his browser 
spec, but that's just an
initial proposal that needs to be reviewed and discussed by the WG. 
However, at least the issue is
clearly stated in that doc and thus provides a basis for discussion.
> Other client behaviour, such as following the protocol, is _not_ out 
> of scope for 6962-bis. Indeed, it seems counter-productive to remove 
> it, since that's the document implementers have to actually read in 
> order to implement CT. It makes no sense to define one side of a 
> protocol in one document and the other in another.
The text in 6269-bis is still rather odd in discussing client behavior 
in the protocol context.
It makes comments (not using standards language) about clients requiring 
all connections to
be accompanied by SCTs:

    TLS clients can thus require that all certificates they accept as
    valid are accompanied
    by signed timestamps.

If I were implementing a client this would sound like a requirement, 
especially in the absence
of any RFC that purports to be a client spec. The text above is an 
example of why I feel we
need an separate client spec that is clear about requirements.

Similarly vague text appears elsewhere, e.g.,

    Since certificates may not be accepted by TLS clients unless logged, ...

The question of whether a (TLS) client is expected to contact a log 
directly to acquire an STH is also
not clearly described with text like:

    When a client requests a log's latest STH ...

Since the next sentence refers to "marking clients" a reader may infer 
that TLS clients
are required to acquire STHs.  This is a more subtle issue than 
suggested by this text.

In general, 6962-bis uses the term "client" to refer to all log clients, 
but usage is
sometimes inconsistent, leading to ambiguity wrt TLS client (aka bowser) 
requirements.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Wed, 27 Jan 2016 13:50:37 +0000

On 26 January 2016 at 16:09, Stephen Kent <[email-masked]> wrote:

>> message from Rich Saltz on July 6 re: the Auditor function. To
>> facilitate moving requirements for the CA/Subject part of the system, I
>> propose that we make the changes below with regard to statements about CT
>> requirements for CA and Subject behavior.  These changes will also help to address
> I agree that the phrase "client behavior" is too broad. But, I also think
> that not all of what
> example, Eran noted that the architecture doc distinguishes between what a
> client does in the absence of an SCT vs. what
> it does if there is an SCT but the sig fails. This, IMHO, is a legitimate
> protocol issue that the
> WG has not addressed.  David took a position on this in his browser spec,
> but that's just an
> The text in 6269-bis is still rather odd in discussing client behavior in
> the protocol context.
> TLS clients can thus require that all certificates they accept as valid
> are accompanied
> by signed timestamps.
>
> of any RFC that purports to be a client spec. The text above is an example
> of why I feel we

Well, the reason this whole conversation started is because I don't believe
the IETF is in a position to say what clients should do, which is why the
language above is not normative (and appears in the introduction, so it
seems pretty obvious to me it is explanatory in nature), and why I have
very little interest in a client spec that says more than how to process CT
information and what it means - which should be specified in 6962-bis.

> Since certificates may not be accepted by TLS clients unless logged, ...
How could that be less vague? That is the reality of the situation...

> When a client requests a log's latest STH ...
Whether you need an STH depends on what you are trying to do. TLS clients
may or may not need STHs, depending whether they care about verifying
proofs... the I-D does explain when STHs are needed...

> are required to acquire STHs.  This is a more subtle issue than suggested
> by this text.
>

A reader would be wrong to infer that, the point is that STHs could be used
to mark individual clients, TLS or otherwise. Which is what the text says.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 29 Jan 2016 16:57:16 -0500

Ben,

>     a client does in the lack of valid CT info is strictly a UI issue.
>     For example, Eran noted that the architecture doc distinguishes
>     between what a client does in the absence of an SCT vs. what
>     WG has not addressed.  David took a position on this in his
>     browser spec, but that's just an
>     initial proposal that needs to be reviewed and discussed by the
>     WG. However, at least the issue is
>>     Other client behaviour, such as following the protocol, is _not_
>>     out of scope for 6962-bis. Indeed, it seems counter-productive to
>>     remove it, since that's the document implementers have to
>>     actually read in order to implement CT. It makes no sense to
>>     define one side of a protocol in one document and the other in
>>     another.
>
If 6962-bis were a complete spec for CT, then I would agree that it 
should specify all
protocol aspects of behavior for clients, CAs, Web Servers, Monitors, 
and Auditors. But, the
architecture document and the companion requirement specs for the 
CA/Subject, Monitor/Auditor
and Browser/vendor illustrate that 6962-bis is far from a comprehensive 
requirements spec.
>
>     ...
>
>
> Well, the reason this whole conversation started is because I don't 
> believe the IETF is in a position to say what clients should do, which 
> is why the language above is not normative (and appears in the 
> introduction, so it seems pretty obvious to me it is explanatory in 
> nature), and why I have very little interest in a client spec that 
> says more than how to process CT information and what it means - which 
> should be specified in 6962-bis.
I have a problem deciding what is in and out of scope when you use 
phrases like "what clients should do."
I believe an well-written spec for CT should make clear exactly what is 
mandated and what is a local
policy decision for a TLS client (as well as for other CT system 
elements). I find the text in 6962-bis
to be inadequate in this regard. If you read 
draft-dseomn-trans-browsers-00.txt you'd see what I view
as an appropriate level of specification for an IETF standard. The 
example I cited about differences
in how a browser should react to a missing SCT vs. an invalid SCT is a 
good example of what I view
as within scope when specifying a protocol. Note that I have not said 
anything about the ability
of a browser to discriminate against a cert with no accompanying SCT in 
terms of the UI. The browser
spec I mentioned specifically says that is a local matter.
> How could that be less vague? That is the reality of the situation...
This is a good example of where we seem to disagree about what 
constitutes appropriate language for a standards track RFC. I have long 
argued that it is unacceptable for browsers to reject a cert because
it is not accompanied by an SCT, until there is a backwards compatible 
transition mechanism codified
in an RFC. Your stance appears to be that what a browser does in this 
regard (which I consider a
basic protocol issue that should be in scope) is not subject to IETF 
standardization, and hence it's
OK to use deliberately vague phrases. We have a fundamental disagreement 
here.
>
>
>     ...
>
>
> Whether you need an STH depends on what you are trying to do. TLS 
> clients may or may not need STHs, depending whether they care about 
> verifying proofs... the I-D does explain when STHs are needed...
I still view the text as needlessly ambiguous. Again, please look at the 
requirements specs we posted
in late December as examples of how to be clear in this regard.
>
>     Since the next sentence refers to "marking clients" a reader may
>     infer that TLS clients
> A reader would be wrong to infer that, the point is that STHs could be 
> used to mark individual clients, TLS or otherwise. Which is what the 
> text says.
The text also strikes me as needlessly vague.

I have authored about 25 RFCs, 18 of which are standards track, and 3 or 
4 of which are BCPs.
I think my experience in this regard makes  me a good judge of what 
constitutes a well-written,
standards track security area RFC. I'm sorry to say that 6962-bis (v-11) 
is not.

Steve

---

From: Melinda Shore <[email-masked]>
Date: Fri, 29 Jan 2016 13:04:53 -0900

On 1/29/16 12:57 PM, Stephen Kent wrote:
> I have authored about 25 RFCs, 18 of which are standards track, and 3
> or 4 of which are BCPs. I think my experience in this regard makes
> me a good judge of what constitutes a well-written, standards track
> security area RFC. I'm sorry to say that 6962-bis (v-11) is not.

Please stick to technical discussion.  Thanks.

Melinda