Steve, As I mentioned, I think log is a good place to ensure that hygiene of the path and not just the leaf certificate.
IMPLEMENTATION ISSUES I do not know if an Appendix would help log operators with some of the past erroneous implementations or interpretations of RFC 5280. I mention this if the log operators choose to use some of the existing platforms to implement path validation. Newer versions may or may not have fixed some of these issues such as: 1. Not enforcing name constraints on intermediate certificates in the path 2. Interpreting name constraints as the only name forms allowed and rejecting certificates with other name forms. For example, if the name constraints contain DN based names and SAN contain RFC 822 names, rejecting the certificates erroneously. 3. Misapplying name constraints on URI. This has caused real problems in circles I work in. Since not all URI schemes have authority component, the URI name constraint should not be applied to the ones that do not (e.g., even if URI name constraints are present, they do not apply to URN and certificates should not be rejected. EKU PROCESSING I went back to the CAB Forum document and it has no processing rules for EKU for the path. But, based on their desire to constrain the path how some of the more popular implementation has done it, the following logic seems to make sense. Assume n certificates in the certificate chain. Set the value of EKU for a certificate to Universal Set if the extension is absent or contains anyExtendedKeyUsage; otherwise set the value to the set of OIDs in the EKU extension. Now, take the intersection of all n sets. If the intersection is empty, the path validation fails. If the intersection in Universal set, the end certificate can be used for any purpose. Otherwise, the end certificate can be used for purpose(s) in the intersection. BTW, I am confused by what the CABF document says in Appendix B item: "Generally Extended Key Usage will only appear within end entity certificates (as highlighted in RFC 5280 (4.2.1.12)), however, Subordinate CAs MAY include the extension to further protect relying parties until the use of the extension is consistent between Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide" I only bring it up because 6962 seems to be using that as a baseline. -----Original Message----- From: Trans [mailto:[email protected]] On Behalf Of Stephen Kent Sent: Monday, September 29, 2014 10:42 AM To: [email protected] Subject: [Trans] path validation I realized, after I sent my reply, that Santosh's point wrt path validation is important. I believe Ben indicated that he did not envision logs performing all of the 5280 checks, just verifying the signatures in the path. So, I misspoke when I noted that 6962-bis already called for path checking; it calls for it, but only in a very superficial way. Thus we need to decide if we believe that a sig-only check on a path consistent with the CABF guidelines. I don't think it is. The Definitions section of the CABF guidelines includes the following entry: Valid Certificate: A Certificate that passes the validation procedure specified in RFC 5280. Steve _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
