On Thu, May 5, 2016 at 2:57 AM, Rob Stradling <[email protected]> wrote: > RFC5280 says (emphasis mine)... > "4.2.1.10. Name Constraints > The name constraints extension, which MUST be used only in a CA > certificate, indicates a name space within which all subject names in > *subsequent certificates in a certification path* MUST be located." > > The Mozilla CA Policy says... > "For a certificate to be considered technically constrained, the > certificate MUST include an Extended Key Usage (EKU) extension > specifying all extended key usages that the subordinate CA is > authorized to issue certificates for... > If the certificate includes the id-kp-serverAuth extended key usage, > then the certificate MUST include the Name Constraints X.509v3 > extension with constraints on both dNSName and iPAddress." > (BRs Section 7.1.5 contains the same requirements) > > > Consider a certificate chain of this form: > Root > Intermediate 1 (contains Name Constraints / EKU) > Intermediate 2 (does not contain Name Constraints / EKU) > End-entity > > In fact, here's a real example: > Root: https://crt.sh/?id=1 > Intermediate 1: https://crt.sh/?id=1250505 > Intermediate 2: https://crt.sh/?id=1250506 > End-entity certs: https://crt.sh/?Identity=%25&iCAID=1188 > > > As per RFC5280, certificate path processing software imposes Intermediate > 1's name constraints upon Intermediate 2, because name constraints flow down > to "subsequent certificates in a certification path". > > Similarly, (IINM) NSS treats the EKU extension in an intermediate > certificate as a constraint on the permitted EKUs in "subsequent > certificates in a certification path". (This is arguably an abuse of > RFC5280, but let's not revisit that argument yet again). > > > Since Intermediate 2 is effectively technically constrained, you might > imagine that it should be exempt from the disclosure requirement. However, > the "certificate MUST include...extension" language in both the Mozilla CA > Policy and the BRs seems to clearly state that: > - Intermediate 1 need not be disclosed. > - Intermediate 2 MUST be disclosed. > > Anyone disagree with my interpretation?
I will disagree. I think the intent is to "prune" the tree once either a technical constraint is hit or when the set of allowed key purposes ceases to include serverAuth. I also think that path length constraints should be taken in to account. That being said, because multiple cross-certificates can exist with the same subject, it is possible that one path would be pruned but there is another path that is unconstrained, which would result in disclosure being required. Thanks, Peter _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
