Thanks, Nick, for the comment on the scope difference in the dnsName constraints vs. SAN wildcard. I hadn't contemplated that. As you note, the real risk isn't dissimilar. (I would presume that this is because a CA willing to issue a SAN dnsName of *.example.com would also presumably issue a SAN dnsName of *.research.example.com.)
Having given further consideration to potential exposures and risks of certificates issued downline of the name constrained intermediate, I did come up with one metric in which the risk profile _could_ be different versus a wildcard EE cert: the wildcard EE certs issued by a CA in the normal course of business must comply with the BRs pertaining to length of validity of validation information and maximum length of validity period of EE certificate life (and, of course, with the rest of the BRs). It's not clear that such a standard or requirement would presently apply to a name constrained technically constrained intermediate certificate. Perhaps it makes sense to only accord preferential treatment of name + eku constrained intermediates which are also constrained to limited period of validity. Perhaps that constraint should mirror or only slightly exceed the limits on EE certs. Out of curiosity, I checked crt.sh's CA certificates disclosure report to see if I could find an in-the-wild name constrained intermediate that I think largely reflects the overall attributes/constraints which might allow for preferential treatment, and found one for Southern Company (an energy & telecom company in the southeast USA). The intermediate certificate in question is at: https://crt.sh/?id=11501550 Southern Company seems to use this certificate to issue some of the EE certificates on some of their public facing websites. https://southernlinc.com features a leaf certificate issued from this technically constrained intermediate. Features, in particular, that I think may allow for preferential treatment of these intermediates, as demonstrated in the crt.sh linked intermediate above, include: 1. Pathlen constraint in this example was 0, but I would presume a pathlen 1 for policy CAs to allow for separate internal intermediates might be allowable too. Not sure if allowing that adds a further risk exposure or not? The effective eku applied to the EE certificate is the most restrictive eku of the certificates in the chain including the leaf certificate, right? (Thus, declaring the further intermediate to have lesser / different name constraints or extra eku permissions would not be effective, correct?) 2. The eku values here are constrained to TLS Server Auth, TLS Client Auth, Email Protection, and OCSP signing 3. As email protection eku is selected, at least one permitted rfc822 name constraint exists. Here, there are actually two: .sourthernco.com and southernco.com (presumably to allow issuance of email certs covering anything in the southernco.com namespace. 4. As TLS server auth eku is present, name constraint exclusions for the whole IPv4 and IPv6 IP space are present. Additionally, a number of permitted dnsName constraints are provided, listing out domains over which the validated organization has control. In contemplating the risk of such intermediates spefically to the Web PKI, the only risks that I can presently imagine to exceed that of wildcard EE certificates thus pertain to validity period. The example certificate I found has a 5 year validity period. It seems to me, however, that while I am aware that one could cause the constrained intermediate to sign a certificate which is NOT baseline requirements compliant, modern Web PKI software would not honor this. With the exception of that caveat, it would appear that proper name constraints, validity period, ekus, and path length constraints can combine to effectively force subordinate leaf certificates into alignment with the baseline requirements. Thus, it would seem that disclosure of certificates descending from such intermediates is likely unnecessary. As long as the validation and issuance of such constrained intermediates is watched by an externally audit-able mechanism like CT, I don't think these intermediates themselves would need specific disclosure in CCADB. Thanks, Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
