Opened 6 years ago

Last modified 6 years ago

#152 new defect

Architecture document: CT-aware TLS clients may require SCTs for all certs

Reported by: eranm@… Owned by: draft-ietf-trans-rfc6962-bis@…
Priority: major Milestone:
Component: client-behavior Version:
Severity: - Keywords:
Cc:

Description

(Towards the end of Page 14) Concludes that because real-time inclusion proof requests are infeasible, TLS clients are not expected to reject a certificate that has no associated SCTs.
I find that conclusion surprising.
I would expect the conclusion to be that TLS clients are not expected to fetch an inclusion proof in real-time during SSL connection establishment. As I understand it, it is CT's end-goal that at least some TLS clients would require presence of SCTs for all certificates.

Change History (2)

comment:1 Changed 6 years ago by kent@…

The architecture document is not written in the future optimistic tense ;-). While I agree that there is a goal for every server cert to be accompanied by (or to contain) an SCT, it seems inappropriate fort this document to state that browsers are expected to reject any cert that fails this criteria.

I plan to revise the text as follows:

Thus CT-aware TLS clients are not expected to fetch an inclusion proof in realtime, e.g., during TLS connection establishment. Such clients also are not expected to reject a certificate that has no associated SCT, because there is no plan for incremental deployment of CT that accommodates such rejection in a backwards compatible fashion.

comment:2 Changed 6 years ago by eranm@…

Sounds good to me.

Note: See TracTickets for help on using tickets.