On Thursday, March 10, 2016 at 11:07:51 PM UTC-8, Jakob Bohm wrote: > - DNS name (for https?) in CN, but not repeated as a SAN (as per PKIX).
Not PKIX. It's the Baseline Requirements. > - SAN present but does not include the server name from the CN, this > might make some PKIX-based clients fail to match the name to the > certificate. Again, not a PKIX thing. You're thinking RFC 2818 (HTTPS) or RFC 6125. However, as detailed in both documents, it's not the presence of the sAN that makes the CN ignored, it's the presence of a SAN with the dNSName (or iPAddress, as appropriate) type. Which is to say, any conforming RFC 6125 or RFC 2818 client that recognizes the commonName field *should* still accept this as valid, as the certificate lacks a dNSName SAN that would cause only the SAN values to be used. > - SHA-1 certificate with apparently intended https usage issued after > 2016-01-01. Quite. This is a BR violation (not a PKIX violation) > - e-mailaddress in DN placed before CN (tradition is after, so the > matchable CN for older browsers is the first element of the DN). This is simply not true. You're conflating the presence of multiple commonNames with the general name type. The compatability issues do not arise with respect to where the commonName field appears within the Subject, only what happens when multiple commonName fields appear. And even then, there is no 'tradition' here - some clients respect the first appearance of the commonName, others the last, and yet others still all. It is at least to their credit that they ordered the SEQUENCE-SET-SEQUENCE tuples of AVAs such that there's only one SEQUENCE per SET; when multiple AVAs appear within a SET, there are further compatability issues (because all name types nested within the SET are considered equivalent) > - No EKU extension and no Netscape usage extension. >From a PKIX perspective, this is perfectly fine - the absence of the EKU means >this certificate is unrestricted from an RFC 5280 standpoint (although from a >modern client library behaviour, the restriction is the intersection of the >intermediate and root CAs' EKUs) >From a Baseline Requirements perspective, this is also a BR violation (item >7.1.2.3, item f) > Code signing for various Microsoft platforms is a key example of such a > situation. The Microsoft platforms that are still restricted to SHA-1 > signatures are also restricted to old CA lists, so setting up new roots > for supporting those is not viable, and not every CA has an old root > they can "throw away", like Symantec did with some of the branded roots > they had accumulated. And Comodo. And Entrust. And I think there were one or two more. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
