RFC6962-bis: Discuss whether or not Submitters should verify SCTs

[GoogleCodeExporter]

RFC6962 Section 5.1 (Submitters) doesn't mention verification at all, and 
Section 4.1 says:
  "log clients who request an SCT for inclusion in TLS handshakes are
   not required to verify it"

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. 

I think RFC6962-bis should say "Submitters SHOULD verify SCTs" and briefly 
describe why it's a good idea to do so.

I don't think this needs to be a "MUST" requirement.  It's a 
you-might-shoot-yourself-in-the-foot-if-you-don't recommendation, rather than 
something that is security critical (because TLS clients will reject invalid 
SCTs anyway).

Original issue reported on code.google.com by robst...@gmail.com on 11 Dec 2013 at 1:20

[GoogleCodeExporter]

Sounds like a reasonable suggestion - as mentioned somewhere else, the Java 
client already does that.

Ben, if you're OK with this change, I'll send the reformatted text for review.

Original comment by er...@google.com on 17 Dec 2013 at 12:25

[GoogleCodeExporter]

The reason we said "not required to verify" is so we could make changes to SCTs 
and only have to change TLS clients and logs, not log clients.

Log clients that are prepared to fail if the SCT spec is changed MAY check the 
SCTs, might be the way to express this.

Original comment by benl@google.com on 10 Jan 2014 at 5:03

[GoogleCodeExporter]

IIUC, a log client that verifies RFC6962-compliant SCTs would only fail if it 
encounters a (not currently defined) v2-or-later SCT.  A v1 SCT, even one with 
1 or more not-currently-defined extensions, shouldn't cause the log client's 
SCT verification to fail, should it?

So, how about saying something like "Submitters MAY verify SCTs, and SHOULD 
verify v1 SCTs" plus some discussion of what might go wrong if you do verify 
and what might go wrong if you don't?

Original comment by robst...@gmail.com on 13 Jan 2014 at 12:17

[GoogleCodeExporter]

> The reason we said "not required to verify" is so we could make changes to 
SCTs and
> only have to change TLS clients and logs, not log clients.

RFC6962 says:
   (Note:
   Log clients don't need to be able to verify this structure; only TLS
   clients do.  If we were to serve the structure as a binary blob, then
   we could completely change it without requiring an upgrade to v1
   clients.)

But /ct/v1/add-chain and /ct/v1/add-pre-chain _don't_ "serve the structure as a 
binary blob".

Therefore, certain log clients (i.e. Submitters that want to use the SCTs they 
receive back from logs) _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.

Original comment by robst...@gmail.com on 15 Jan 2014 at 10:30

[GoogleCodeExporter]

We think we should change:

"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"

Also, the language about v1 clients not caring about verification errors should 
go.

Original comment by benl@google.com on 28 Jan 2014 at 1:44

[GoogleCodeExporter]

Great.  Thanks Ben.

Original comment by robst...@gmail.com on 28 Jan 2014 at 3:38

[GoogleCodeExporter]

Migrated to http://trac.tools.ietf.org/wg/trans/trac/ticket/2

Original comment by er...@google.com on 3 Mar 2014 at 8:16

• Changed state: Done