I know several CAs are using certlint (https://github.com/awslabs/certlint) as a pre-issuance check that the cert they're about to issue doesn't have any programmatically detectable deficiencies; if it doesn't already cover some of these cases, it'd be great to add them as a technical means for ensuring that this doesn't regress -- things like N/A should be an easy enough check to add I'd think.
Cheers, Alex On Tue, May 2, 2017 at 11:07 AM, Ryan Sleevi via dev-security-policy < [email protected]> wrote: > (Still wearing Google Hat in this context) > > I think sharing a list (in CT) of the certs is good and can help verify the > assertions made here :) > > But overall, I think this sounds right and the risk is minimal to our > users, so not revoking still sounds good :) > > On Mon, May 1, 2017 at 11:53 PM, Jeremy Rowley <[email protected] > > > wrote: > > > 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:[email protected]] > > *Sent:* Monday, May 1, 2017 5:01 PM > > *To:* Jeremy Rowley <[email protected]> > > *Cc:* Gervase Markham <[email protected]>; mozilla-dev-security-policy@ > > 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 < > > [email protected]> 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. > > > > > > > _______________________________________________ > 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
