Re: Unknown Intermediates

2017-06-16 Thread Andrew Ayer via dev-security-policy 
On Fri, 16 Jun 2017 10:29:45 -0700
Tavis Ormandy via dev-security-policy
 wrote:

> On Fri, Jun 16, 2017 at 2:00 AM, Rob Stradling
>  wrote:
> 
> > On 16/06/17 06:05, Tavis Ormandy via dev-security-policy wrote:
> >
> >> Hello, I was crawling the pkcs7 blobs in public pdf files and
> >> found some intermediate certificates that don't appear in crt.sh.
> >>
> >> I forwarded them to Rob, I don't know if this is useful to anyone
> >> else, but
> >> they're available here.
> >>
> >> https://lock.cmpxchg8b.com/intermediates.zip
> >>
> >> Tavis.
> >>
> >
> > Thanks Tavis.  I've just submitted all of these intermediates to
> > some CT logs.
> >
> > This list just grew considerably...
> > https://crt.sh/mozilla-disclosures#undisclosed
> >
> > (I have a larger collection if anyone wants them, but many have
> > unknown
> >> critical extensions, or are name or usage constrained, etc)
> >>
> >
> > Yes please.  :-)
> >
> >
> Is there an easy way to check which certificates from my set you're
> missing? (I'm not a PKI guy, I was collecting unusual extension OIDs
> for fuzzing).
> 
> I collected these from public sources, so can just give you my whole
> set if you already have tools for importing them and don't mind
> processing them, I have around ~8M (mostly leaf) certificates, the
> set with isCa will be much smaller.

Please do post the whole set.  I suspect there are several people on
this list (including myself and Rob) who have the tools and experience
to process large sets of certificates and post them to public
Certificate Transparency logs (whence they will be fed into crt.sh).

It would be useful to include the leaf certificates as well, to catch
CAs which are engaging in bad practices such as signing non-SSL certs
with SHA-1 under an intermediate that is capable of issuing SSL
certificates.

Thanks a bunch for this!

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

Re: Unknown Intermediates

2017-06-16 Thread Tavis Ormandy via dev-security-policy 
On Fri, Jun 16, 2017 at 2:00 AM, Rob Stradling 
wrote:

> On 16/06/17 06:05, Tavis Ormandy via dev-security-policy wrote:
>
>> Hello, I was crawling the pkcs7 blobs in public pdf files and found some
>> intermediate certificates that don't appear in crt.sh.
>>
>> I forwarded them to Rob, I don't know if this is useful to anyone else,
>> but
>> they're available here.
>>
>> https://lock.cmpxchg8b.com/intermediates.zip
>>
>> Tavis.
>>
>
> Thanks Tavis.  I've just submitted all of these intermediates to some CT
> logs.
>
> This list just grew considerably...
> https://crt.sh/mozilla-disclosures#undisclosed
>
> (I have a larger collection if anyone wants them, but many have unknown
>> critical extensions, or are name or usage constrained, etc)
>>
>
> Yes please.  :-)
>
>
Is there an easy way to check which certificates from my set you're
missing? (I'm not a PKI guy, I was collecting unusual extension OIDs for
fuzzing).

I collected these from public sources, so can just give you my whole set if
you already have tools for importing them and don't mind processing them, I
have around ~8M (mostly leaf) certificates, the set with isCa will be much
smaller.

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

Re: Unknown Intermediates

2017-06-16 Thread Jonathan Rudenberg via dev-security-policy 

> On Jun 16, 2017, at 05:00, Rob Stradling via dev-security-policy 
>  wrote:
> 
> On 16/06/17 06:05, Tavis Ormandy via dev-security-policy wrote:
>> Hello, I was crawling the pkcs7 blobs in public pdf files and found some
>> intermediate certificates that don't appear in crt.sh.
>> I forwarded them to Rob, I don't know if this is useful to anyone else, but
>> they're available here.
>> https://lock.cmpxchg8b.com/intermediates.zip
>> Tavis.
> 
> Thanks Tavis.  I've just submitted all of these intermediates to some CT logs.
> 
> This list just grew considerably...
> https://crt.sh/mozilla-disclosures#undisclosed

For posterity, here are the new ones (from June 14 to present, there are seven 
others predating this batch that are still on the list):

- 
https://crt.sh/?sha256=a6ca043d5c838dd10e935acdd1079c9686b6511faf4c80c4dcfc9c54394ded5e
- 
https://crt.sh/?sha256=6365b25e9299b5f382eb0066850629088ebcd9bcb398f28622107603c3c1c27e
- 
https://crt.sh/?sha256=d57b9872b1eef8e8032ab2e8cb0e63b685d1655c51c454f23f9975dfa2ad7e0a
- 
https://crt.sh/?sha256=077b75f6b7fa71be4f8121e1ec52faebca0d0aed2dc01711a0f6dcdc38e7bf38
- 
https://crt.sh/?sha256=7fa8450051bac3efd7ea4dbbd070075d7e7b7d27f3f119e6fa1f7103b8a89f24
- 
https://crt.sh/?sha256=3b84290532c84b7026e06a427b689c69fe24154bdecb43fedbe29bf955ca6513
- 
https://crt.sh/?sha256=5d1f493bb09823decc8a6e35a23d04c83778d854a43b34686a363d6f4bb287c2

I think it would be useful to see incident reports from each of the CAs so that 
we can understand how these trusted intermediate certificates, all issued 
several years ago, were missed.

Jonathan


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

Re: Symantec response to Google proposal

2017-06-16 Thread Peter Kurrasch via dev-security-policy 
  My thoughts:2) Timeline.I agree with Symantec that Google's original deadlines are far too aggressive, for 2 reasons. First, I do not think Symantec can move quickly without causing further damage. Second, I do not think Symantec's customers can move quickly at all ‎given that a majority of them are large corporations that have to coordinate budgets, staff, outsourcing firms, and so forth. These customers also need time to familiarize themselves with the new rules and identify a course of action that makes sense for their business environments and their user base. Even though I understand the desire to move quickly, in this situation it seems imprudent to do so.Many will find this next bit unacceptable, but in the interest of providing an alternative, let me suggest a timeline of 6 different dates over the next 2 years (in case it really does take that long): the 21st day of February, May, and August of 2018 & 2019. Each of these dates represent a different milestone for changes in policy enforcement, certificate validation, software and systems, and whatever is identified as a deliverable in these ongoing discussions. The dates here are chosen specifically to acknowledge that many businesses operate on a quarterly system while avoiding complications that inevitably take place at the end of a quarter and the end of the year. And, yes, that would imply no action taken before Feb of next year.1) Scope of DistrustFirst a question: is removing the EV entitlements from the Symantec roots something that is still on the table for Mozilla products or has that been dismissed for some reason? I ask because it hardly ‎seems appropriate that a CA under sanction be entitled to all the benefits that are extended to CA's which are not under sanction. Doing so also inflicts some pain on Symantec (without breaking the global economy) until such time as they've resolved their issues to Mozilla's satisfaction.Regarding the expiration of certificates, I do not agree that CT logging engenders trust so I disagree with Symantec on that. Frankly I don't entirely agree with Google on the phased dis-trust and CT logging items. Those seem to increase complexity in the PKI ecosystem ‎(which carries its own risk) without necessarily improving the ecosystem, but it's very likely I've missed some important details.As to scope itself, my understanding is that Mozilla will eventually remove trust from all current Symantec roots (the "ubiquitous roots") and in its place use a set of "new roots", some of which will be under the purview of Symantec competitors. These new roots will be cross-signed to those ubiquitous roots so that new certs that chain up to these new roots will still validate properly on products that have not or cannot be updated to use the new roots.‎ (If my understanding is incorrect, I hope someone will correct me.)To put it another way, all existing certs that chain up to ‎the ubiquitous roots will eventually stop working--many before their date of normal expiration. As such, there needs to be a ramp up of new cert issuing capacity while at the same time a phasing out of the existing certs. Combining that with the above "alt-timeline" would look something like the following. The exact makeup of the root bundles and CA groups are TBD.Milestone 1 (Feb 21, 2018) - EV entitlement removed from the ubiquitous roots, new root cert bundle A ‎is ready to go, and CA group 1 is approved to begin issuing against the roots in bundle A. No new end entity certs have been issued yet.Milestone 2 (May 21, 2018) - New root bundle B is ready to go and CA group 2 is approved to begin issuing against bundle B, but has not yet done so.Milestone 3 (Aug 21, 2018) - New root bundle C is ready to go and CA group 3 is approved to begin issuing against bundle C, but has not yet done so.Milestone 4 (Feb 21, 2019) - New root bundle D is ready to go and CA group 4 is approved to begin issuing against bundle D, but has not yet done so. In addition, some analysis should be performed to evaluate the ‎overall health of the new root solution (for example, how many total certs have been issued, any reports of major disruptions to end users, etc.).Milestone 5 (May ‎21, 2019) - The fifth, and final, bundle E of new roots is ready to go and CA group 5 is approved to begin issuing against them but has not yet done so. This would also represent the earliest date that Symantec is allowed to be included in any of the CA groups.Milestone 6 (Aug 21, 2019) - Final removal of trust for the original Symantec roots.I know that some of this represents a significant departure from what Google and Symantec have previously discussed but I thought there might be some utility in having an alternate framework from which to draw. 

Re: Unknown Intermediates

2017-06-16 Thread Rob Stradling via dev-security-policy 

On 16/06/17 06:05, Tavis Ormandy via dev-security-policy wrote:

Hello, I was crawling the pkcs7 blobs in public pdf files and found some
intermediate certificates that don't appear in crt.sh.

I forwarded them to Rob, I don't know if this is useful to anyone else, but
they're available here.

https://lock.cmpxchg8b.com/intermediates.zip

Tavis.


Thanks Tavis.  I've just submitted all of these intermediates to some CT 
logs.


This list just grew considerably...
https://crt.sh/mozilla-disclosures#undisclosed


(I have a larger collection if anyone wants them, but many have unknown
critical extensions, or are name or usage constrained, etc)


Yes please.  :-)

--
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