On 02/05/17 16:11, Alex Gaynor via dev-security-policy wrote:
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.
Simple project idea (perhaps for https://github.com/cabforum):
A CSV file that contains 2 items per line:
1. An optional comma-separated list of Subject attribute shortnames.
2. A string that a CA should probably not encode as a complete Subject
attribute.
e.g.,
"OU,ST,L","N/A"
,"."
"O","Internet Widgits Pty Ltd"
Anyone (CA representatives, industry researchers, etc, etc) would be
able to submit PRs, CAs would be invited to consult this list when
evaluating certificate requests, and certlint would be able to report on
"violations".
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.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
