Opened 8 years ago

Closed 8 years ago

#2 closed defect (fixed)

Require log submitters to verify SCTs

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

Description

Migrated from https://code.google.com/p/certificate-transparency/issues/detail?id=24 :

robstrad suggests changing the language in section 5.1 (Submitters) to say:
"Submitters SHOULD verify SCTs" for the following reasons:

An invalid SCT is not useful:

  • If a CA includes an invalid Precertificate SCT in a Certificate, this could cause them and their customers pain/embarrassment/hassle.
  • If a server operator includes an invalid SCT in TLS handshakes, CT-aware TLS clients will object. More pain/embarrassment/hassle.
  • If anyone submits a Certificate to a log without verifying the SCT, they can't immediately be sure that that Certificate will actually appear in the log.

According to benl, this requirement was not stated "so we could make changes to SCTs and only have to change TLS clients and logs, not log clients.".

robstrad points out that log clients "... _do_ need to understand the internal structure of an RFC6962 SCT, because they need to put the pieces together to produce the SCT "binary blob". So if you were to "make changes to SCTs" then these log clients, which will include every CA that implements Precertificates, would need to be updated too." (and it is not a opaque binary blob to them).

benl then suggests changing"
"log clients who request an SCT for inclusion in TLS handshakes are

not required to verify it"

to

"log clients who request an SCT for inclusion in TLS handshakes SHOULD verify it"

And removing the language about v1 clients not caring about verification errors.

Change History (7)

comment:1 Changed 8 years ago by eranm@…

Shouldn't the SCT requested for inclusion be verified regardless of their intended use? i.e. it should not matter if the client is requesting the SCT for inclusion in the TLS handshake, embedding in a precertificate or stapled OCSP response.

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

  • Cc rob.stradling@… added

comment:3 Changed 8 years ago by eranm@…

I'll point out that if submitters are required to verify the received SCTs, then only log clients which do not use the returned SCTs can safely ignore SCTs with version > v1.

comment:4 Changed 8 years ago by eranm@…

comment:5 Changed 8 years ago by benl@…

This change does not actually address this issue!

comment:6 Changed 8 years ago by eranm@…

I've messed up the issue above by uploading an unrelated diff.

Please have another look here:
http://codereview.appspot.com/98100043
(this time changes directly relate to checking SCTs that are to be embedded or otherwise accompany certificates).

comment:7 Changed 8 years ago by eranm@…

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