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. >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. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
