Opened 8 years ago

Closed 6 years ago

#23 closed defect (fixed)

How can TLS clients match an SCT to a certificate?

Reported by: eranm@… Owned by: rob.stradling@…
Priority: major Milestone: review
Component: rfc6962-bis Version:
Severity: - Keywords:
Cc:

Description

(Relevant to SCTs from stapled OCSP response and TLS handshake)
Currently the SCTs served by a web server do not have to be for the end-entity certificate - they could be for a name-constrained intermediate.

The RFC should describe how a TLS client should go about matching the SCTs to the certificates in the certificate chain.
A naive approach would be to start from the EE certificate, see if the signature verifies over it. If not, continue up the chain until either the SCT's signature verifies or it reaches a too-broad certificate (e.g. the root CA cert).

Change History (12)

comment:1 follow-up: Changed 8 years ago by rob.stradling@…

I think ticket #10 should address this.

We agreed (in ticket #10 comment 6) to define a new data structure to contain "an arbitrary number of {type, list} pairs, where |list| is a list of items all of the same type, identified |type|. So far, those might be SCTs, STHs, SCT inclusion proofs or STH consistency proofs."
We also agreed (in ticket #10 comments 6 and 8) to use this new data structure in a new TLS extension and also in a new X.509 Extension for Certificates and OCSP Responses.

This new data structure could also include optional metadata for each |item| in each |list|. e.g. for SCTs (and for SCT inclusions proofs!), this metadata would somehow indicate which Certificate the SCT (or SCT inclusion proof) is for. The method for "somehow indicate" would differ depending on where the new data structure is used:

  • Certificate Extension: Each SCT (or SCT inclusion proof) is, implicitly, for this Certificate, so no additional "Which Certificate is this for?" metadata is needed.
  • TLS Extension: For each SCT (or SCT inclusion proof) |item|, the metadata could be an integer (0..N) that indicates the relevant certificate in the certificate_list (in the "Server Certificate" message). i.e. 0 = the end-entity cert ... N = the last cert in the certificate_list. Also, see footnote (*).
  • OCSP Response Extension: For each SCT (or SCT inclusion proof) |item|, the metadata could be a boolean value (TRUE = the end-entity cert; FALSE = a Name-constrained intermediate cert); if FALSE, then the metadata could also include a (partial?) hash of the Name-constrained intermediate cert. (Since there may exist multiple chains of different lengths between the end-entity cert and the Name-constrained intermediate cert, it wouldn't be possible to use an integer to indicate the position of the Name-constrained intermediate cert in the chain).

(*) I'm hoping that the new data structure in ticket #10 will also be useful for gossip. So in addition to values of (0..N), we could have a special integer value that means "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."

comment:2 in reply to: ↑ 1 Changed 8 years ago by rob.stradling@…

Replying to rob.stradling@…:
<snip>

The method for "somehow indicate" would differ depending on where the new data structure is used:

  • Certificate Extension: Each SCT (or SCT inclusion proof) is, implicitly, for this Certificate, so no additional "Which Certificate is this for?" metadata is needed.

Actually, it would be useful if SCTs / SCT inclusion proofs for a Name-constrained Intermediate could optionally be embedded in certs further down the chain (particularly end-entity certs) instead of (or as well as) embedded in the Name-constrained Intermediate. This would avoid the need to reissue Name-constrained Intermediates that don't contain a sufficient number of SCTs from logs that are currently widely accepted by TLS clients.

This could be done by using essentially the same metadata that I suggested for "OCSP Response Extension". i.e.

  • Certificate Extension: For each SCT (or SCT inclusion proof) |item|, the metadata could be a boolean value (TRUE = this cert; FALSE = a Name-constrained intermediate cert further up the chain); if FALSE, then the metadata could also include a (partial?) hash of the Name-constrained intermediate cert.

comment:3 Changed 7 years ago by eranm@…

  • Resolution set to duplicate
  • Status changed from new to closed

Marking as duplicate of ticket 10, as the suggested data structure in ticket 10 should apply to this problem as well (with the addition of metadata as suggested by Rob).

comment:4 Changed 6 years ago by rob.stradling@…

  • Resolution duplicate deleted
  • Status changed from closed to reopened

Ticket #10 laid the groundwork for this ticket, but it left the implementation of "somehow indicate" as a TODO. Since that's what this ticket was/is about, I'm reopening it.

comment:5 Changed 6 years ago by rob.stradling@…

  • Owner changed from draft-ietf-trans-rfc6962-bis@… to rob.stradling@…
  • Status changed from reopened to new

comment:6 Changed 6 years ago by eranm@…

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.

comment:7 Changed 6 years ago by rob.stradling@…

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.

comment:8 Changed 6 years ago by rob.stradling@…

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.

comment:9 Changed 6 years ago by rob.stradling@…

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.

comment:10 Changed 6 years ago by eranm@…

Strongly support removing the ItemExtension? field.

comment:11 Changed 6 years ago by rob.stradling@…

  • Milestone set to review

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.

comment:12 Changed 6 years ago by melinda.shore@…

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.