The point of certlint was to help identify issues. While I appreciate it getting broad usage, I don't think pushing for revocation of every certificate that trips any of the Error level checks is productive. This reminds of me of people trawling a database of known vulnerabilities then reporting them to the vendors and asking for a reward, which happens all too often in bug bounty programs.
I think it would be much more valuable to have a "score card" by CA Operator that shows absolute defects and defect rate. Thanks, Peter On Wed, Aug 9, 2017 at 2:21 PM, Jeremy Rowley via dev-security-policy <[email protected]> wrote: > And this is exactly why we need separate tiers of revocation. Here, there is > zero risk to the end user. I do think it should be fixed and remediated, but > revoking all these certs within 24 hours seems unnecessarily harsh. I think > there was a post about this a while ago, but I haven't been able to find it. > If someone remembers where it was, I'd appreciate it. > > -----Original Message----- > From: dev-security-policy > [mailto:dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org] > On Behalf Of Jonathan Rudenberg via dev-security-policy > Sent: Wednesday, August 9, 2017 10:08 AM > To: [email protected] > Subject: Certificates with metadata-only subject fields > > Baseline Requirements section 7.1.4.2.2(j) says: > >> All other optional attributes, when present within the subject field, MUST >> contain information that has been verified by the CA. Optional attributes >> MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘ (i.e. space) characters, >> and/or any other indication that the value is absent, incomplete, or not >> applicable. > > There are 522 unexpired unrevoked certificates known to CT issued after > 2015-11-01 that are trusted by NSS for server authentication and have at > least one subject field that only contains ASCII punctuation characters. > > The full list can be found here: https://misissued.com/batch/5/ > > Since there are so many, I have included a list of the CCADB owner, > intermediate commonName, and count of certificates for the 311 certificates > in this batch that were issued in the last 365 days so that the relevant CAs > can add the appropriate technical controls and policy to comply with this > requirement in the future. Please let me know if there is any additional > information that would be useful. > > Jonathan > > — > > DigiCert (131) > Cybertrust Japan Public CA G3 (64) > DigiCert SHA2 Extended Validation Server CA (36) > DigiCert SHA2 High Assurance Server CA (12) > TERENA SSL CA 3 (7) > DigiCert SHA2 Secure Server CA (6) > Cybertrust Japan EV CA G2 (6) > > GlobalSign (62) > GlobalSign Organization Validation CA - SHA256 - G2 (46) > GlobalSign Extended Validation CA - SHA256 - G2 (8) > GlobalSign Extended Validation CA - SHA256 - G3 (8) > > Symantec / VeriSign (35) > Symantec Class 3 Secure Server CA - G4 (32) > Symantec Class 3 EV SSL CA - G3 (2) > Wells Fargo Certificate Authority WS1 (1) > > Symantec / GeoTrust (34) > GeoTrust SSL CA - G3 (25) > GeoTrust SHA256 SSL CA (5) > RapidSSL SHA256 CA (2) > GeoTrust Extended Validation SHA256 SSL CA (2) > > Comodo (19) > COMODO RSA Organization Validation Secure Server CA (11) > COMODO RSA Extended Validation Secure Server CA (8) > > Symantec / Thawte (17) > thawte SSL CA - G2 (12) > thawte SHA256 SSL CA (3) > thawte EV SSL CA - G3 (2) > > T-Systems International GmbH (Deutsche Telekom) (6) > Zertifizierungsstelle FH Duesseldorf - G02 (3) > TeleSec ServerPass Class 2 CA (2) > Helmholtz-Zentrum fuer Infektionsforschung (1) > > QuoVadis (3) > QuoVadis EV SSL ICA G1 (2) > QuoVadis Global SSL ICA G2 (1) > > SECOM Trust Systems Co. Ltd. (2) > NII Open Domain CA - G4 (2) > > SwissSign AG (1) > SwissSign Server Gold CA 2014 - G22 (1) > > Entrust (1) > Entrust Certification Authority - L1K (1) > _______________________________________________ > dev-security-policy mailing list > [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 > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
