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
<dev-security-policy@lists.mozilla.org> 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: mozilla-dev-security-pol...@lists.mozilla.org
> 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
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to