Opened 6 years ago

Closed 6 years ago

#142 closed defect (fixed)

Specify what TLS clients should send in the extension_data of the transparency_info TLS extension

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


RFC6962 requires TLS clients to send 'empty "extension_data"' for the "signed_certificate_timestamp" TLS extension.

In 6962-bis we have an opportunity to rethink this, because we're replacing the "signed_certificate_timestamp" TLS extension with a new "transparency_info" TLS extension.

I think it could make sense for TLS clients to signal various things in the "extension_data" of the "transparency_info" TLS extension. For example:

  • Which version(s) of CT does the TLS client support?
  • Which "TransType?"s can the TLS client handle?
  • Does the TLS client want to participate in gossip?

Change History (5)

comment:1 Changed 6 years ago by eranm@…

  • Owner changed from draft-ietf-trans-rfc6962-bis@… to eranm@…

Other things the client can send:

  • List of Log IDs.

comment:2 Changed 6 years ago by eranm@…

Advice obtained from exchange with Adam Langley:

  • The server doesn't have much control over which logs it has SCTs from so it may not be entirely useful to specify them.
  • Because we aren't certain what we'll need we'll just be building an extension-within-extension mechanism, might as well use the existing TLS extensions mechanism.
  • Specifying that the client sends nothing but the server does not reject non-empty extension_data, but, because we won't be using it initially, "it might get bug-rusted before you can use it".

So the conclusion is we leave the extension data empty, which simplifies the protocol but does not prevent us from sending additional data in the future using a different TLS extension.

comment:5 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.