RE: Certificates with less than 64 bits of entropy

[Stephen Davidson via dev-security-policy]

Ah, my apologies.

https://bugzilla.mozilla.org/attachment.cgi?id=8898848

Regards, Stephen



From: dev-security-policy 
[dev-security-policy-bounces+s.davidson=quovadisglobal@lists.mozilla.org] 
on behalf of Eric Mill via dev-security-policy 
[dev-security-policy@lists.mozilla.org]
Sent: Saturday, August 19, 2017 12:06 PM
To: Stephen Davidson
Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with less than 64 bits of entropy

On Fri, Aug 18, 2017 at 12:04 PM, Stephen Davidson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> 4)  The list of affected certificates is attached in spreadsheet
> form;  they will be uploaded to CT as well.  You will note that the number
> has declined – Siemens' previous report did not take into account that some
> of the certificates had already previously been revoked for other
> reasons.   The spreadsheet also includes certificates issued during the
> Digicert/Verizon root signing period.
>

Would you mind posting this to a public URL or to a Bugzilla bug? The list
doesn't transmit attachments.

-- Eric


>
> Regards, Stephen
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone 
___
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

Re: Certificates with less than 64 bits of entropy

[Eric Mill via dev-security-policy]

On Fri, Aug 18, 2017 at 12:04 PM, Stephen Davidson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> 4)  The list of affected certificates is attached in spreadsheet
> form;  they will be uploaded to CT as well.  You will note that the number
> has declined – Siemens' previous report did not take into account that some
> of the certificates had already previously been revoked for other
> reasons.   The spreadsheet also includes certificates issued during the
> Digicert/Verizon root signing period.
>

Would you mind posting this to a public URL or to a Bugzilla bug? The list
doesn't transmit attachments.

-- Eric


>
> Regards, Stephen
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Expired Certificates Listed by Certificate Manager

[userwithuid via dev-security-policy]

On Tuesday, August 15, 2017 at 12:32:01 PM UTC, Gervase Markham wrote:
> OneCRL does not obsolete certdata.txt-based distrust because not
> everyone checks OneCRL. While we can't add every cert in OneCRL to
> certdata.txt, we should add the big dis-trusts to it. Do you think
> there's anything missing?

I'm not following this CA stuff for that long, but one thing that comes to mind 
is the us gov pki. The symantec cross-sign has expired by now and the identrust 
one only has 5 months left, so going by current public info this will resolve 
itself soon. Still, for 2 years now a huge, intransparent, complex subtree is 
(probably) blocked for OneCRL clients, but trusted for non-OneCRL (+non-OCSP) 
users. Imho this is/was a little more high-profile than most other entries.

Another situation: Old Wosign/StartCom roots are slated to be removed from 
certdata soon afaik. Finally, end of that story, right? But old WoSign has a 
revoked cross-signed by Certum until 2020. So Firefox and OCSP clients will get 
the expected result: No more old WoSign. "Just certdata"-consumers will still 
have it trusted and hardly anybody will know that this is happening or how. 
Candidate for addition?

In general: When I read the messages on this list, I get the following 
impression:

1. GOOD: Revocation alone is "not really enough", mis-issuance is still bad and 
it reflects badly on a CA if there are too many issues or their handling is 
poor.
2. HOWEVER: In practice, once a cert is revoked and added to OneCRL, both the 
CA and Mozilla consider that particular issue resolved. A revoked cert or 
subtree is considered "not in scope" any more (and understandably so, there 
isn't much more that can be done on the technical level save removing the 
entire root for really bad cases).

So to me it kinda felt like non-OneCRL is not taken into account by Mozilla any 
more. But since you said certdata distrust might still be used, a suggestion:

The Mozilla workflow seems to be missing a step that checks whether a revoked 
subCA will 1. keep issuing certs (e.g. I just read up on the Disney CA that was 
revoked, then started issuing non-compliant certs) and 2. whether exisiting 
certs at the time of revocation had critical issues (e.g. failed validation). 
In both cases certdata addition should be at least considered. Otoh, additions 
stemming from e.g. the recent reports seem to be good candidates for 
OneCRL-only distrust. Same if a subCA just moved roots or stopped operating and 
that was the reason for revocation.

Basically: Figure out/inquire why the revocation happened and classify as high 
or low risk. Maybe Mozilla's policy could be adjusted to require CAs to provide 
such an explanation on revocation? I'm aware that there is a "revocation 
reason" in OCSP already, but that is insufficient (e.g. "cessation of 
operation" for identrust federal bridge cross...).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy