Subject: Re: [Trans] [trans] #76 (rfc6962-bis): Normative client behavior specified in Section 3.4

From: "trans issue tracker" <[email-masked]>
Date: Tue, 03 Nov 2015 01:28:20 -0000

#76: Normative client behavior specified in Section 3.4

Changes (by [email-masked]):

 * owner:  [email-masked] =>
     [email-masked]
 * status:  reopened => new

Comment:

 Propose this ticket be closed (fixed) as we've added the following text
 (section 9.2):
 "However, specifying the TLS clients' behavior once compliance or non-
 compliance has been determined (for example, whether a certificate should
 be rejected due to the lack of valid SCTs) is outside the scope of this
 document."

 I also think that the text on SCT validity is quite clear:
 "TLS clients SHOULD validate each SCT by computing the signature input
 from the SCT data as well as the certificate and verifying the signature,
 using the corresponding log's public key."

 So not sure what can be added, unless Steve Kent points to the problematic
 wording in draft 10.

-- 
--------------------------+--------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect        |      Status:  new
 Priority:  major         |   Milestone:  review
Component:  rfc6962-bis   |     Version:
 Severity:  -             |  Resolution:
 Keywords:                |
--------------------------+--------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/76#comment:6>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 03 Nov 2015 12:21:33 -0000

Comment (by [email-masked]):

 +1.  Citing specific text would be infinitely more helpful than referring
 to old "messages" (links?) that refer to old section numbers!

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/76#comment:7>
trans <http://tools.ietf.org/trans/>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Nov 2015 10:56:12 -0500

Melinda,

> Changes ([email-masked]):
>
>   * owner:[email-masked]  =>
>       [email-masked]
I think the wording here is still imprecise. For example, the text in 9.2
says "TLS clientsMUST reject SCTs whose timestamp is in the future." But
this, combined with the text above, does not say that a TLS client SHOULD
treat a cert as invalid is it contains (or is associated with) an SCT that
is "rejected." Is this ambiguity intentional?  Also, the term 
"compliance" seems
needlessly vague here.

My colleagues plan to post a proposed client requirements spec (focusing on
browsers and browser vendors) later this week. It tries to be more explicit
about this and other client behaviors (required and optional).
>   So not sure what can be added, unless Steve Kent points to the problematic
The following problematic comments re client behavior (wrt SCTs) appear 
in -10

    The intent is that eventually clients would refuse to honor

certificates that do not appear in a log, effectively forcing CAs to

add all issued certificates to the logs.

    TLS clients can thus requirethat all

certificates they accept as valid are accompanied by signed

timestamps.

Sincecertificates may not be accepted by TLS clients unless logged ...

    In addition, if TLS clients will not accept unlogged certificates ...

    certificates that have not been publicly logged, and thus

do not have a valid SCT, are not considered compliant (so TLS clients

may decide, for example, to reject them).

------------------------------------------------------------------------

These statements do not literally mandate client behavior, but they

expressing intent which could easily be interpreted as client behavior
specs.

Steve

------------------------------------------------------------------------

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Nov 2015 11:01:41 -0500

see my response to Melinda's message on this topic.

> Comment ([email-masked]):
>

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 16 Nov 2015 04:49:45 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 This seems quite clear - I'm closing it as fixed.

-- 
--------------------------+--------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect        |      Status:  closed
 Priority:  major         |   Milestone:  review
Component:  rfc6962-bis   |     Version:
 Severity:  -             |  Resolution:  fixed
 Keywords:                |
--------------------------+--------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/76#comment:8>
trans <http://tools.ietf.org/trans/>