> On Jul 5, 2017, at 4:23 AM, Gervase Markham via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > On 03/07/17 17:44, Peter Bowen wrote: >> We still need to get the policy changed, even with the ballot. As >> written right now, all name constrained certificates are no longer >> considered constrained. > > I'm not sure what you mean... What's the issue you are raising here?
Right now (Policy v2.5) says: Intermediate certificates which have at least one valid, unrevoked chain up to such a CA certificate and which are not technically constrained to prevent issuance of working server or email certificates. Such technical constraints could consist of either: an Extended Key Usage (EKU) extension which does not contain any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection; or: name constraints which do not allow Subject Alternative Names (SANs) of any of the following types: dNSName, iPAddress, SRVName, rfc822Name The second bullet says “any”. As the rule for name constraints is that if they are not present for a type, then any name is allowed, you have to include name constraints for all four types. The issue comes down to the definition of “working server” certificates. Mozilla does not use either rfc822names or SRVName for name validation for server authentication, but you could have a valid server certificate that has only these names. Is NSS/Firefox code considered a “technical constraint”? If not, then all technically constrained CA certificates need to have constraints on SRVName and rfc822Name type General Names in addition to what they have now. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
