Hello,
Many thanks for the research - this CT analysis is both fascinating and useful. I'd like to address the following statement: "Noncompliance already visible from previously logged certificates. The HydrantID SSL ICA G2 CA is trusted by Mozilla (via QuoVadis) for TLS authentication, but issues certs intended for IPSEC and which lack serverAuth and clientAuth EKU values, which are not BR-compliant (7.1.2.3.f)." For the sake of reference, here's a link to one of the certificates referenced: https://crt.sh/?id=380352272&opt=zlint. Responding to the two points: 1. IPSEC EKU These certificates contain extKeyUsage values for IPSEC due to a customer requirement. This is allowed under the Baseline Requirements: "7.1.2.3.f. extKeyUsage (required) Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both values MUST be present. id-kp-emailProtection [RFC5280] MAY be present. Other values SHOULD NOT be present." RFC 2119 defines SHOULD NOT as: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. 2. serverAuth and clientAuth EKU These certificates are compliant with the BR and contain the required extKeyUsage values for both id-kp-serverAuth or id-kp-clientAuth. It appears that zLint "w_sub_cert_eku_extra_values" provides an incomplete message relating to the BR 7.1.2.3: ***************************************** * ZLint showing just w_sub_cert_eku_extra_values description ***************************************** $ zlint -list-lints-json | grep 'w_sub_cert_eku_extra_values' {"name":"w_sub_cert_eku_extra_values","description":"Subscriber Certificate: extKeyUsage either the value id-kp-serverAuth or id-kp-clientAuth or both values MUST be present.","citation":"BRs: 7.1.2.3"} This lint shows a warning due to the inclusion of additional extKeyUsage values. The zLint description ideally should include the "Other values SHOULD NOT be present" portion of the BR to reflect that the warning may be generated even though the cert is compliant with the BR. Regards, Stephen Davidson QuoVadis -----Original Message----- From: dev-security-policy <dev-security-policy-bounces+s.davidson=quovadisglobal....@lists.mozilla.org> On Behalf Of Tim Smith via dev-security-policy Sent: Saturday, March 31, 2018 7:15 PM To: Mozilla <[email protected]> Subject: Discovering unlogged certificates in internet-wide scans Hi MDSP, I went looking for corpuses of certificates that may not have been previously logged to CT and found some in the Rapid7 "More SSL" dataset, which captures certificates from their scans of non-HTTPS ports for TLS-speaking services. I wrote up some findings at http://blog.tim-smith.us/2018/03/moressl-spelunking/. A few highlights include: - of the ~10 million certificates in the corpus, about 20% had valid signatures and chained to roots included in the Mozilla trust store - about 50,000 of the 2 million trusted certificates had not previously been logged - about half of the novel certificates were unexpired There were interesting examples of unexpired, non-compliant, trusted certificates chaining to issuers including GoDaddy, NetLock, Logius, and Entrust. (I have not taken any action to inform issuers of these findings, other than this message and by publishing the certificates to CT logs.) I welcome any feedback or questions about the value of the approach and the findings. Thanks, Tim _______________________________________________ dev-security-policy mailing list [email protected]<mailto:[email protected]> https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
