Subject: [Trans] [trans] #152 (client-behavior): Architecture document: CT-aware TLS clients may require SCTs for all certs

From: "trans issue tracker" <[email-masked]>
Date: Fri, 08 Jan 2016 17:11:15 -0000

#152: Architecture document: CT-aware TLS clients may require SCTs for all certs

 (Towards the end of Page 14) Concludes that because real-time inclusion
 proof requests are infeasible, TLS clients are not expected to reject a
 certificate that has no associated SCTs.
 I find that conclusion surprising.
 I would expect the conclusion to be that TLS clients are not expected to
 fetch an inclusion proof in real-time during SSL connection establishment.
 As I understand it, it is CT's end-goal that at least some TLS clients
 would require presence of SCTs for all certificates.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-
  [email-masked]       |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  client-      |    Version:
  behavior               |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/152>
trans <https://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 12 Jan 2016 19:27:51 -0000

Comment (by [email-masked]):

 The  architecture document is not written in the future optimistic tense
 ;-).  While I agree that there is a goal for every server cert to be
 accompanied by (or to contain) an SCT, it seems inappropriate fort this
 document to state that browsers are expected to reject any cert that fails
 this criteria.

 I plan to revise the text as follows:

 Thus CT-aware TLS clients are not expected to fetch an inclusion proof in
 realtime, e.g., during TLS connection establishment. Such clients also are
 not expected to reject a certificate that has no associated SCT, because
 there is no plan for incremental deployment of CT that accommodates such
 rejection in a backwards compatible fashion.

  behavior               |  Resolution:
 Keywords:               |

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