Subject: Re: [Trans] [trans] #111 (to-be-decided): Consider using the cached-info TLS extension

From: "trans issue tracker" <[email-masked]>
Date: Tue, 19 Jul 2016 15:27:43 -0000

#111: Consider using the cached-info TLS extension

Comment (by [email-masked]):

 cached-info is now an RFC...

 https://www.rfc-editor.org/info/rfc7924

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  [email-masked]           |  [email-masked]
     Type:  enhancement              |      Status:  new
 Priority:  minor                    |   Milestone:
Component:  to-be-decided            |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

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

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 27 Jul 2016 14:36:41 -0000

I'd like to tackle this in 6962-bis.

 The original idea in this ticket (i.e. a TLS client sends hashes of SCTs
 that it has previously seen and cached) seems sub-optimal, in terms of
 bytes on the wire.

 So here's what I think is a better approach:
 When a TLS client uses the cached-info extension to inform a TLS server of
 1 or more certs it has cached, the TLS client may also indicate (via a
 boolean flag) whether or not it has already verified that each cert is "CT
 compliant" (according to the TLS client's own policies).

 One approach would be to have a list of boolean flags that corresponds to
 the list of 1 or more "cert" cached-info records.

 A simpler approach (which I think would be sufficient) would be to have a
 single boolean flag that is only set to "true" if all of the (1 or more)
 cached certs is already deemed by the TLS client to be "CT compliant".

 This boolean flag could be passed in the transparency_info extension, but
 I'm not sure it'd be wise to create that sort of interdependency between
 transparency_info and cached_info.  So I suggest that we define a new
 CachedInformationType so that TLS clients can send this boolean flag via
 cached_info.

 Any comments on this proposal?

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

---

From: "trans issue tracker" <[email-masked]>
Date: Fri, 29 Jul 2016 12:03:40 -0000

Proposed text out for review:
 https://github.com/google/certificate-transparency-rfcs/pull/186/files

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