Subject: Re: [Trans] [trans] #23 (rfc6962-bis): How can TLS clients match an SCT to a certificate?

From: "trans issue tracker" <[email-masked]>
Date: Mon, 01 Feb 2016 16:38:54 -0000

#23: How can TLS clients match an SCT to a certificate?

Comment (by [email-masked]):

 Capturing offline discussion with Rob:
 * The ItemExtension field may be redundant given new TransItems can be
 defined that refer to other TransItems to provide metadata.
 * Given that name-constrained intermediates that are logged instead of
 leaf certificates are easily identifiable by a non-critical extension,
 providing the metadata indicating which certificate the SCT refers to may
 be an overkill: A client can try to verify the SCT on the leaf
 certificate, if the signature does not validate it should traverse the
 cert chain until it finds such an intermediate, then validate the SCT over
 that intermediate.
 * An intermediate MAY be logged instead of the leaf, so to allow for the
 case where both the intermediate and leaf are logged, the client has to
 validate the SCT against the leaf first.

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

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

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 01 Feb 2016 17:19:51 -0000

Comment (by [email-masked]):

 Also discussed with Eran just now: In comment:1 I suggested that it might
 be useful to define an !ItemExtension for gossip (i.e. "This SCT (or SCT
 inclusion proof) isn't relevant to any of the certificates you're
 currently interested in, but nonetheless please keep a copy of it and send
 it to some other TLS servers you communicate with.")  However, we could
 define a different mechanism for signalling this: two ideas...
   - Define a new range of !TransType values that mirror the existing set.
 The log would produce SCTs, inclusion proofs, etc, using the existing set
 of !TransType values; the TLS server would modify the !TransType of an
 object it's gossiping; then the (gossip-supporting) TLS client would spot
 that this object is being gossiped, then restore the original !TransType
 if it wants to verify the !TransItem's signature.  (Clients that don't
 support gossip via this mechanism would simply ignore the !TransItem
 objects with !TransType values they don't recognize).
   - As per comment:6, an additional !TransItem could be added by the TLS
 server (using a not-yet-defined !TransType value) that contains additional
 metadata about other !TransItems in the list.  One drawback of this
 approach is that if the TLS client doesn't recognize this not-yet-defined
 !TransType value, it would try to verify the gossiped SCTs / inclusion
 proofs against the TLS server's certificate/chain.

 The second of these approaches would need to be documented in 6962-bis to
 ensure that the described drawback does not occur.
 The first of these approaches could be implemented entirely in the gossip
 draft.  6962-bis need not know anything about it.

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

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 01 Feb 2016 17:44:47 -0000

One further thing discussed with Eran just now: it could be useful to
 define an SCT extension to self-identify that SCT as belonging to a name-
 constrained intermediate certificate rather than an end-entity
 certificate.  Requiring this SCT extension to be present in such SCTs
 would reduce the amount of guesswork that clients need to do in order to
 determine which certificate the SCT belongs to.
 If we do this, we would need a corresponding extension for inclusion
 proofs, although there's currently no extensions field in
 InclusionProofDataV2.

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

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 01 Feb 2016 17:48:40 -0000

At the moment I am fairly inclined to get rid of the !ItemExtension field.
 It complicates things (especially for servers, since they would need to
 manipulate log-signed !TransItem objects in order to insert
 !ItemExtensions), and it seems (from the last few comments) that we can
 manage without it.

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

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 03 Feb 2016 16:14:35 -0000

Strongly support removing the ItemExtension field.

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

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 16 Feb 2016 14:03:14 -0000

Changes (by [email-masked]):

 * milestone:   => review

Comment:

 Fixed by https://github.com/google/certificate-transparency-
 rfcs/commit/d71d7707a3eeb5707cf5048c3849b068e477038c

 The !ItemExtension field is gone.  When there's a suitably name-
 constrained intermediate in the certificate chain, TLS clients may need to
 use trial and error to determine which of the certificates in the chain an
 SCT or inclusion proof corresponds to.

 Priority:  major             |   Milestone:  review

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

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 16 Feb 2016 17:36:18 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => 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: <https://trac.tools.ietf.org/wg/trans/trac/ticket/23#comment:12>
trans <https://tools.ietf.org/trans/>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 29 Feb 2016 14:30:17 -0500

Rob,

I'm not sure what your proposed resolution for this issue means.

Phases like "a suitably name-constrained intermediate cert" and
"clients may need to used trial and error" are not really appropriate
for a standard. I'll await publication  of the next rev of 6962-bis to
see if there is an algorithmic description of how the matching is to be
performed.

Steve