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 auto-populator) 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? Jeremy 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>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CA Validation quality is failing On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <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 generators. 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) Jeremy, 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. 4.9.1.1(15) ), we can look into separately. 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
