(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 <jeremy.row...@digicert.com>
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: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-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 <
> 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.
>
>
>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to