Opened 8 years ago

Closed 7 years ago

#48 closed defect (fixed)

Enforce the rules for Name-constrained Intermediates

Reported by: rob.stradling@… Owned by: draft-ietf-trans-rfc6962-bis@…
Priority: major Milestone:
Component: rfc6962-bis Version:
Severity: - Keywords:
Cc:

Description

Section 3.2.3 (Using a Name-Constrained Intermediate CA) specifies some conditions for Name-constrained Intermediate CA {certificates, Precertificates} that are logged in place of end-entity certificates.

Fabrice Gautier noticed that the current draft doesn't say anything about which, if any, log clients should verify that these conditions have been met.

Unless ticket #42 kills the name redaction mechanism and the possibility of SCTs existing for non-end-entity certificates, I suggest we add text to say...

  • When a TLS Client validates an SCT for an Intermediate CA certificate or Intermediate CA Precertificate, it MUST check that the conditions in section 3.2.3 have been met.

Monitors don't see SCTs, but they do "watch for certificates of interest". Let's discuss whether or not Monitors should care about section 3.2.3 over at Ticket #39.

Auditors check that the log is behaving correctly. I think the current text in section 3.2.3 implies that it would be incorrect behaviour to accept an Intermediate that doesn't meet the conditions. If this is what we want, then I think we should state it explicitly and consider requiring Auditors to verify compliance.
(Alternatively, is there any reason why we can't allow logs to accept any and all Intermediates? SCTs for Intermediates that don't meet the conditions in section 3.2.3 might not be of any practical use, but perhaps there might be some value in having dedicated log entries for all known Intermediates).

Change History (1)

comment:1 Changed 7 years ago by benl@…

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