Opened 7 years ago

Closed 6 years ago

#94 closed defect (fixed)

Fetching of inclusion proofs: Why and when are clients expected to do this?

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

Description

The introduction implies that clients asynchronously check for inclusion proofs.

A rough suggestion by Steve Kent:
"If clients check for the presence of SCTs, this is a good start because gives them some confidence the certificate is logged if the log is behaving. They can gain additional confidence by demanding an inclusion proof. We recognise it puts additional burden on clients"

We should also point out that a client directly contacting the log to request an inclusion proof discloses private information to the log (the website the client has visited) and so other, indirect methods of contacting the log may be required.

Change History (9)

comment:1 Changed 7 years ago by benl@…

  • Component changed from client-behavior to rfc6962-bis

I note that this question is addressed in the gossip I-D, and perhaps is better left there?

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

I'd just like to note that ticket #10 aims to (re)introduce the option of passing inclusion proofs (embedded in certs, OCSP responses or a TLS extension) instead of SCTs.

This ticket's question is still relevant when SCTs are used, of course.

comment:3 Changed 6 years ago by eranm@…

Regarding the original question raised in this issue:
(1) When is defined pretty clearly in https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-11#section-9.2.
(2) Why is explained in the introduction, albeit briefly.

The distinction between a client having an SCT and a client having an inclusion proof that was clear in RFC6962 is now less sharp, as inclusion proofs can be directly provided to clients.

There's benefit in explaining the distinction between a client only having seen an SCT and a client having checked inclusion by verifying an inclusion proof; I welcome suggestions regarding the relevant section in the RFC this should be described.

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

I suggest the "TLS Client" section (currently numbered 9.2).

comment:5 Changed 6 years ago by eranm@…

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

comment:6 Changed 6 years ago by eranm@…

From the mailing list (Quoting Steve Kent):
"I think the text in draft-dseomn-trans-browsers-00.txt addresses the topic
of what a browser can/should do re SCTs more clearly that 6962-bis, although
the browser I-D not been updated to reflect the possibility of an inclusion
proof being sent as part of an SCT.

Also, the topic of when a server should send an inclusion proof, or when
a CA should embed a proof in an SCT in a cert, should be addressed in
I-Ds that thoroughly describe server and CA behaviors, e.g.,
draft-kseo-trans-ca-subject-00.txt."

comment:7 Changed 6 years ago by eranm@…

Out for review in https://github.com/google/certificate-transparency-rfcs/pull/106

The text is more terse than originally suggested, but should capture the original intent.

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