Opened 6 years ago

Closed 5 years ago

#164 closed defect (fixed)

Incorporate new protocol mechanisms into TLS Client section

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

Description

Section 8.2 "TLS Client" is currently written as if SCT validation were the only
thing clients would get from servers and validate, even though one of the major
improvements to the protocol in this document is that it allows the server to
also send inclusion proofs and STHs!

This section needs to be generalized to cover what the client does when it
receives inclusion proofs and STHs from the server as well. I think that will
ultimately entail describing the range of "proactive" vs. "reactive" validation
that we have discussed on list.

The parts about validating SCTs should probably be deleted in favor of better
description of validation in the section that defines SCTs.

Change History (4)

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

  • Component changed from client-behavior to to-be-decided

comment:2 Changed 5 years ago by eranm@…

  • Component changed from to-be-decided to rfc6962-bis
  • Owner changed from draft-ietf-trans-rfc6962-bis@… to eranm@…
  • Status changed from new to assigned

Re-reading the "TLS Clients" section (now 8.1) It seems to me this is covered pretty well.
There's some repetition there, which I've fixed in this PR:

https://github.com/google/certificate-transparency-rfcs/pull/258

comment:4 Changed 5 years ago by melinda.shore@…

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