Subject: Re: [Trans] [trans] #99 (rfc6962-bis): Clearer definition of when a certificate is CT-compliant needed

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

#99: Clearer definition of when a certificate is CT-compliant needed

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => needs-review

Comment:

 Propose this ticket be closed (Fixed) as the term 'compliant' is now used
 consistently throughout the text to mean 'compliant with the RFC'.
 For example, see https://tools.ietf.org/html/draft-ietf-trans-
 rfc6962-bis-10#section-9.2:
 "By validating SCTs, TLS clients can thus determine whether
    certificates are compliant.  A certificate not accompanied by a valid
    SCT MUST NOT be considered compliant by TLS clients.".

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

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

---

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

* status:  closed => reopened
 * resolution:  needs-review =>

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

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

---

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

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

-- 
------------------------------+--------------------------------------
 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/99#comment:3>
trans <http://tools.ietf.org/trans/>

---

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

Changes (by [email-masked]):

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

 Severity:  -                 |  Resolution:  fixed

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

---

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

> Changes ([email-masked]):
>
>   * status:  new => closed
>   For example, seehttps://tools.ietf.org/html/draft-ietf-trans-
I find the term "complaint" to not be helpful. As I noted in my reply to
Melinda re issue #79, the use of this term in the description
of some aspects of client behavior seems ambiguous. Adding
this new term does not clarify client behavior options. What is needed
is a statement about what a client is required to do, e.g., when a
TLS server provides an SCT, but the SCT is invalid (e.g., sig fails
or a timestamp in the future). Also, if there are multiple SCTs, there
needs to be a statement about whether a client SHOULD require all to be 
valid
(presumably not a good idea), or if a client is expected to accept the
cert if any SCT can be validated, or what. This may be beyond the scope of
issue 99, but it illustrates the gaps that need to be addressed if we are
to avoid ambiguity in the specs. I suggest this is best handled by moving
the description of client requirements to a separate doc, so that this doc
can focus on the log and avoid problems of the sort noted here.