On Wed, Nov 2, 2016 at 7:08 AM, Peter Bowen <[email protected]> wrote: > I realize that 6962bis has passed WGLC, so I know there is a high bar > for changes. However I think this might pass that bar. The highly > restrictive language that imposes minimum policy for logs prevents > interoperability with other IETF RFCs on the standards track very > hard. 6962bis appears to assume that DANE (RFCs 7671 and 6698) will > never be implemented and that concepts like RFC 6091 will never come > to fruition.
To further expand on Peter's question regarding Section 5.1, as presently specified, it shifts a significant burden to log clients submitted certificates that might otherwise be addressed by log flexibility. Consider a CA which it itself a trust anchor (root cert) and has a certificate cross-signed by another trust anchor (cross-sign). One log may directly support the root, another log may only support the CA issuing of the cross-sign. One interpretation of the text is that "using the chain of intermediate CA certificates provided by the submitter" means that only the first log can be used, and that the second log cannot perform any path building to determine that the cross-sign exists. As such, a client submitting certs must have full knowledge of the PKI graph, prior to submission, to determine which logs it can use, and logs are prevented from using their knowledge. Another interpretation is that the chain of intermediates is merely a 'hint', and may be discarded by the log when evaluating the path. This would at least resolve some of Peter's concerns, but not all. The core of this is the question regarding the MUST level requirement, and whether that language unduly restricts possible implementations in a way that may prevent standards adoption. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
