On 17/3/2019 1:54 π.μ., Matthew Hardeman via dev-security-policy wrote:
While sending a message that non-compliance could result in policy change is generally a bad idea, I did notice something about the profile of the non-compliant certificate which gave me pause: None of the example certificates which were provided include a SAN extension at all. Today, no valid certificates for the WebPKI lack a SAN extension. There should always been at least one SAN dnsName, SAN ipAddress, or in case of S/MIME certificates, a SAN rfc822 name. I know that Chrome has already fully deprecated non-SAN bearing certs. Have the other browsers? I'm wondering whether it's possible or reasonable for policy to update such that certificates that lack any SAN at all would be out of scope?
This is a very interesting proposal and would narrow the scope of the policy to exactly the certificate types used by Mozilla products. There might be some legacy implementations out there that still use the CN field to validate a FQDN, IP Address and emailAddress to validate an e-mail address. If there is a policy change to better specify the scope adding something more than the EKU, IMHO it should include these legacy cases too. I made an attempt to describe how that would look like in the policy but the language can definitely be improved. I used some of the existing language of section 1.1 of the current policy.
For an end-entity certificate Certificate to be in scope of the Mozilla Policy, it MUST have:
* either an Extended Key Usage (EKU) extension which contains one or more of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection; or * no EKU extension Additionally, the end-entity certificate MUST have: * a Subject Alternative Names extension of any of the following types: dNSName, iPAddress, SRVName, rfc822Name; or * a subjectDN that contains a commonName attribute (OID: 2.5.4.3) that point to a Domain Name or IP Address; or * a subjectDN that contains an emailAddress attribute (OID: 1.2.840.113549.1.9.1) that point to an Email Address. I hope this is useful. Dimitris. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
