Opened 8 years ago

Closed 6 years ago

#10 closed defect (fixed)

Permit Precertificate SCTs to be delivered via OCSP Stapling and the TLS Extension

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

Description

RFC6962 only allows the OCSP Stapling and signed_certificate_timestamp TLS Extension mechanisms to deliver Certificates SCTs (LogEntryType?=x509_entry).

RFC6962-bis should allow these mechanisms to deliver both Certificates SCTs (LogEntryType?=x509_entry) and Precertificate SCTs (LogEntryType?=precert_entry), so that ticket #1 option 2 can be supported everywhere.

Since, in the RFC6962 SCT v1 format, entry_type is "implicit from the context in which the SCT is presented", we would need to either:

i) Define SCT v2, in which entry_type is expressed explicitly.

or

ii) Define a CtExtensions? extension to carry the entry_type explicitly in a v1 SCT.

or

iii) Expect TLS Clients to attempt to verify v1 SCTs sent via OCSP Stapling or the TLS Extension twice (first time, assume entry_type is "x509_entry"; if the SCT signature doesn't verify, try again, this time assuming entry_type is "precert_entry").

Change History (18)

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

Alternative idea for solving this problem with OCSP Stapling...

Per RFC6962, a Certificate can contain a List of Precertificate SCTs in an Extension with OID 1.3.6.1.4.1.11129.2.4.2, and an OCSP Response can contain a List of Certificate SCTs in an Extension with OID 1.3.6.1.4.1.11129.2.4.5.

We could allow the .2.4.2 Extension to also appear in OCSP Responses, as well as or instead of the .2.4.5 Extension. entry_type would be implied by the OID of the Extension in which the SCT is delivered.

This would avoid having to make any changes to the SCT v1 format.

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

Replying to rob.stradling@…:

Alternative idea for solving this problem with OCSP Stapling...

<snip>

This would avoid having to make any changes to the SCT v1 format.

To achieve the same thing for the TLS extension delivery method, I think we'd have to register another new TLS Extension.

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

Replying to rob.stradling@…:

To achieve the same thing for the TLS extension delivery method, I think we'd have to register another new TLS Extension.

Actually, I think there is a way to do this using just the existing TLS extension: insert a "dummy SCT" in the middle of the SCT List.
If an SCT List contains a "dummy SCT", then all the SCTs listed before the "dummy SCT" are presumed to be Precertificate SCTs, and all the SCTs listed after the "dummy SCT" are presumed to be Certificate SCTs.
If an SCT List does not contain a "dummy SCT", then (as per RFC6962) all of the SCTs in the list are Certificate SCTs.

A "dummy SCT" could be defined very simply as:

       struct {
           Version dummy_sct_version;
       } DummySignedCertificateTimestamp;

   "dummy_sct_version" is the version of the protocol to which the dummy SCT
   conforms.  This version is vdummy.

Also, the definition of Version would need to be updated:

       enum { v1(0), vdummy(255) }
         Version;

comment:4 follow-up: Changed 8 years ago by benl@…

I think if we're going to start adding extra stuff to the extension, rather than an ad hoc mechanism like this we should instead register a new extension with more structure.

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

Replying to benl@…:

I think if we're going to start adding extra stuff to the extension, rather than an ad hoc mechanism like this we should instead register a new extension with more structure.

I agree that this would be cleaner than the comment 3 hack, as long as we face no obstacles deploying another new TLS extension in the real world.

comment:6 Changed 8 years ago by benl@…

Decision: define a new extension that contains 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.

For OCSP, adopt comment 1: "We could allow the .2.4.2 Extension to also appear in OCSP Responses, as well as or instead of the .2.4.5 Extension. entry_type would be implied by the OID of the Extension in which the SCT is delivered."

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

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

comment:8 follow-up: Changed 8 years ago by benl@…

In fact, OCSP should use the same data structure, identified by a new OID, rather than having its own way to do it. Similarly, the new data structure should be embeddable in a certificate/precertificate using the same OID.

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

Replying to benl@…:

In fact, OCSP should use the same data structure, identified by a new OID, rather than having its own way to do it. Similarly, the new data structure should be embeddable in a certificate/precertificate using the same OID.

Once we've specified the new Certificate/OCSP Extension, it would be best to get the new OID assigned from the arc that Russ Housley manages.

http://datatracker.ietf.org/doc/draft-housley-pkix-oids/ "describes the object identifiers that were assigned in that arc, it returns control of that arc to IANA, and it establishes IANA allocation policies for any future assignments within that arc."

comment:10 Changed 7 years ago by eranm@…

Ticket 23 is a duplicate of this.
For future reference, ticket 23 contains Rob's suggestion of adding metadata.

comment:11 Changed 7 years ago by rick_andrews@…

I don't understand how this solution would work if the precertificate contains redacted names.

Would CAs still add to the final cert the extension that contains the array of the number of label redactions?

comment:12 follow-up: Changed 7 years ago by eranm@…

Rick, I believe the answer is yes - regardless of the SCT's origin, the TLS client knows it has to reconstruct the precertificate by redacting some of the labels based on information in the final certificate. The text on redacted names says:
"When a Precertificate contains one or more redacted labels, a non-

critical extension (OID 1.3.6.1.4.1.11129.2.4.6, whose extnValue
OCTET STRING contains an ASN.1 SEQUENCE OF INTEGERs) MUST be added to
the corresponding certificate:"

So this extension would be removed from the certificate when the client is re-constructing the precertificate, and the information in it would instruct the client to convert top.secret.example.com to (private).example.com (by indicating two levels should be redacted).

I believe this information is relevant regardless of the SCT origin - Rob, do you agree?

comment:13 in reply to: ↑ 12 Changed 7 years ago by rob.stradling@…

Replying to eranm@…:

I believe this information is relevant regardless of the SCT origin - Rob, do you agree?

Yes, I agree.

comment:14 follow-ups: Changed 7 years ago by rob.stradling@…

The mailing list (also, see ticket #42) is currently discussing the dangers of the name redaction mechanism. I think that discussion needs to reach a firm conclusion on whether name redaction should ever be allowed before we can continue progress on this ticket. (If name redaction is never allowed, then this ticket is pointless and should be marked WONTFIX).

comment:15 in reply to: ↑ 14 Changed 7 years ago by rob.stradling@…

Replying to rob.stradling@…:

...(If name redaction is never allowed, then this ticket is pointless and should be marked WONTFIX).

Having said that, the "new extension that contains an arbitrary number of {type, list} pairs, where |list| is a list of items all of the same type, identified |type|" envisaged by comment:6 could still be useful for gossip. Perhaps this should be the subject of a separate ticket? Incidentally, since this would be a new TLS extension, a new certificate extension and a new OCSP Response extension, I think ticket #34 needs to be resolved before we can start work on defining it.

comment:16 in reply to: ↑ 14 Changed 7 years ago by rob.stradling@…

Replying to rob.stradling@…:

(If name redaction is never allowed, then this ticket is pointless and should be marked WONTFIX).

There seems to be consensus that 6962-bis should specify a name redaction mechanism, so this ticket is not pointless. :-)

Ticket #34 is currently being discussed on the TRANS mailing list. Once that is resolved, we can make progress on this ticket.

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

  • Milestone set to review

Draft -11 added the new extension envisaged by comment:6, so I think this ticket should be closed now. I left 3 TODOs in the doc, but I will (re)open separate tickets to address these.

You can see the relevant changes using rfcdiff (although note that ticket #105 was also addressed in -11):
https://www.ietf.org/rfcdiff?url1=draft-ietf-trans-rfc6962-bis-10&url2=draft-ietf-trans-rfc6962-bis-11

Alternatively, here's the PR:
https://github.com/google/certificate-transparency-rfcs/pull/89

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

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