Opened 7 years ago

Closed 7 years ago

#76 closed defect (fixed)

Normative client behavior specified in Section 3.4

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

Description

Section 3.4 does a much better job of explaining why there are 3 options for transmitting the SCT. However, the description of the certificate extension says that a certificate is more likely to be refused if any of the SCTs are now “invalid.” This statement cites specific TLS client behavior, which is out of scope.

Change History (8)

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

  • Component changed from client-behavior to rfc6962-bis

comment:2 Changed 7 years ago by benl@…

  • Milestone set to review

I cannot find the referenced text, so I assume this is already fixed.

comment:3 Changed 7 years ago by melinda.shore@…

  • Resolution set to fixed
  • Status changed from new to closed

comment:4 Changed 7 years ago by dkg@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

Steve Kent says:

no. it is not fixed. See my message citing specific instances of
normative client behavior in 3 and 3.4

comment:5 Changed 7 years ago by benl@…

I cannot act on this feedback - there are numerous messages from Steve Kent referring to normative client behaviour, none that I've reviewed have outstanding actions that I can find.

The actual text referred to needs to be quoted in this ticket.

comment:6 Changed 7 years ago by eranm@…

  • Owner changed from draft-ietf-trans-rfc6962-bis@… to melinda.shore@…
  • Status changed from reopened to new

Propose this ticket be closed (fixed) as we've added the following text (section 9.2):
"However, specifying the TLS clients' behavior once compliance or non-compliance has been determined (for example, whether a certificate should be rejected due to the lack of valid SCTs) is outside the scope of this document."

I also think that the text on SCT validity is quite clear:
"TLS clients SHOULD validate each SCT by computing the signature input from the SCT data as well as the certificate and verifying the signature, using the corresponding log's public key."

So not sure what can be added, unless Steve Kent points to the problematic wording in draft 10.

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

+1. Citing specific text would be infinitely more helpful than referring to old "messages" (links?) that refer to old section numbers!

comment:8 Changed 7 years ago by melinda.shore@…

  • Resolution set to fixed
  • Status changed from new to closed

This seems quite clear - I'm closing it as fixed.

Note: See TracTickets for help on using tickets.