Certainly happy to share more info. The search was for all EV and OV certs. Of 
the 4000 certificates detected, 101 certificates are EV. Of these EV 
certificates, 17 would be included in the proposed revocation. The rest have 
the “N/A” issue. This is just the locality/state/zip. The jurisdiction of 
incorporation processes separately and doesn’t have the same auto-populate tool.


More info:

78 certs had non-US states populated with US states (thanks to the 

791 entities are affected by the entire range of certificates

257 entities are affected if we revoke the 1033 certs

82 entities are affected if we revoke just the 150 certs


What else would you like to know?




From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Monday, May 1, 2017 5:01 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: Gervase Markham <g...@mozilla.org>; 
Subject: Re: CA Validation quality is failing




On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

There isn't anything in our CPS directly. However, we state that we follow the 
baseline requirements in the CPS. The baseline requirements give a profile for 
the state field. We weren't sure this was strictly followed.

We finished our validation review over the weekend.   There are about 3000 
older certs with information indicating a field was not applicable (such as a 
"-", "N/A", etc). On top of this, we issued about 1000 certificates with 
mismatched validation information. The mismatched information can be divided 
into about 850 certificates with numbers in the state field. These numbers 
indicate a location code that was provided by the auto-populator.  The 
remaining 150 are certificates with "Select", a state, or a postal code 
improperly included in the certificate.  The root issue was a combination of 
the auto-populator inserting incorrect data into the cert request and our 
validation staff not properly updating the certificate information after 
completing the validation process.

Based on these results, we propose the following remediation plan:
1. We already removed the auto-populator from our CSR and certificate order 
2. We already blocked this information on the CA side from included in signed 
SSL/TLS objects.
3. We will revoke the 150 certificates with mismatched information.
4. We plan to let the remaining 3850 expire normally but will correct the 
certificate for all future orders (including rekeys).

Is this an acceptable plan? We are proposing not revoking the 3850 certificates 
because the information isn't misleading, the information is accurate, and 
there isn't a risk posed to Mozilla's users by inclusion of the numeric 
location code or not applicable indicator. Any thoughts?


(With a Google hat on)




I think with the information you've shared so far, that sounds like a 
reasonable plan from Google's perspective for the 3000 certificates. I think 
there's at least a little concern about the EV nature for the 850 side, but 
just trying to understand more here what the implications would be. Is this 
exclusively the state, or does it also extend to the jurisdiction* fields? Or 
is this only for EV?


Would you be able to share a spreadsheet or details for those, in the spirit of 
transparency? I think if you can share those details, it's reasonable to avoid 
revoking, and anything specific that might represent a security/compat risk to 
an Application Software Supplier (i.e. ), we can look into 


Thank you for

1) Disclosing the details to a sufficient level of detail immediately

2) Providing regular updates and continued investigation

3) Confirming the acceptability of the plan before implementing it, and with 
sufficient detail to understand the implications


These are several of the factors we weighed when considering the 
implications/risk of not revoking.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

dev-security-policy mailing list

Reply via email to