On Sun, Oct 23, 2016 at 2:41 PM, Ryan Sleevi <[email protected]> wrote: > I'm curious to understand the interpretation of Section 4.2, and it's > presumed implications for CT clients. > > At present, Section 4.2 ( > https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-19#section-4.2 > ) states: > > An intermediate CA certificate or intermediate CA precertificate that > contains the Name Constraints [RFC5280] extension MAY be logged in > place of end-entity certificates issued by that intermediate CA, as > long as all of the following conditions are met > > As I read this, this implies that this is not an obligation upon > clients to recognize this extension, or this approach to logging. That > is, a client (such as Google Chrome) may consider rejecting such > certificates as part of its Certificate Transparency policy. At > present, this is where the thinking of Chrome is, but if it's > perceived to obligate clients to recognize such events, then I'd like > to try to see how to tweak the text to make it clearer that this is > optional - for logs and for clients.
The draft clearly calls for TLS clients to accept this. See section 8: TLS servers MUST use at least one of the three mechanisms listed below to present one or more SCTs from one or more logs to each TLS client during full TLS handshakes, where each SCT corresponds to the server certificate or to a name-constrained intermediate the server certificate chains to. Section 10.2.6 makes it clear that section 8 defines compliance: If any certificate in a chain includes the transparency_info (Section 8.5) TLS extension identifier in the TLS Feature [RFC7633] certificate extension, then CT compliance (using any of the mechanisms from Section 8) is required. It appears that the methiod in 4.2 is explicitly called out in other sections and does not appear to be optional for clients. > >From discussing with some of the authors, and from those in the CA and > log operator space, it doesn't seem that there's a clear agreement > about the implication of the text, and whether or not it belongs in > https://datatracker.ietf.org/doc/draft-strad-trans-redaction/ (as a > technical means for redaction). However, if there's WG consensus that > it is merely descriptive about how such a mechanism would work (via > MAY), rather than prescriptive upon a client implementation, then > perhaps it's worth noting more explicitly as such, without > meaningfully altering the text that has passed WG consensus. I don't think it needs moving. The objective to allow named subjects of certificates to detect mis-issuance is met by using Name Constrained CAs. Just as a subject monitors for end-entity certificates she did not authorize, she should also monitor for subordinate CAs she did not authorize. The effect is the same -- ensuring that there is proper authorization for the issuance of certificates. The key difference between an unconstrained CA and name constrained CA is pre-notification of intent to issue. With an unconstrained CA, any name can show up at any time. However with a NC CA, there is clear notice of what names are to be issued. This is even better than a standard end-entity certificate checking, as the subject can preemptively take action rather than waiting for the first EE certificate to be issued. Thanks, Peter _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
