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?
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
