On Sunday, October 23, 2016, Peter Bowen <[email protected]> wrote: > On Sun, Oct 23, 2016 at 2:41 PM, Ryan Sleevi <[email protected] > <javascript:;>> 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.
It is precisely these sections that I have heard disagreeing interpretations, precisely because it implies dictating policy about what a client accepts. As a counter-interpretation, what about clients that impose policy on the SCTs delivered - such as Chrome does. Either we accept CT compliance is locally defined - which suggests optionality - or it's an unnessecary constraint on policy inconsistent with existing 6962 implementations. > 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. While this is true, as you know, this is not the only objective of CT from existing implementations. For example, it prevents detection of misissuance as defined by the CA/Browser Forum's Baseline Requirements, as name constrained sub-CAs still have obligations of issuance practice imposed on them. Your interpretation suggests the only value of CT is for specific domain holders, but I don't believe that's a correct or shared interpretation.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
