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

Reply via email to