Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

2017-06-19 Thread Matthew Hardeman via dev-security-policy
On Monday, June 19, 2017 at 11:40:22 PM UTC-5, Tom Ritter wrote:
> So at what point does the CA become culpable to misissuance in a case
> like this? Is it okay that we let them turn a blind eye to issuing or
> reissuing certificates where they have a strong reason to believe the
> private key will be published in firmware?

Pretty much any DV validated certificate could be used the way Cisco's software 
used this one...  Unless we want to create new burdens for every DV validating 
CA out there, I don't think it's practical to pre-suppose that a similar 
certificate will get similar misuse.

The right balance is probably revoking when misuse is shown.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

2017-06-19 Thread Tom Ritter via dev-security-policy
On 19 June 2017 at 08:28, Samuel Pinder via dev-security-policy
 wrote:
> Therefore the newly re-issued
> certificate *will* end up with it's private key compromised *again*,
> no matter how well it may be obfuscated in the application, it is
> still against the very principle.

I'm pretty confused by this as well.

First off, while people have proposed multiple solutions to this
problem, they are not trivially implementable, nor are they
widespread. I think if you shook the tree with some automation, you'd
find on the order of 50 or more publicly trustable private keys
embedded in firmware pretty quickly.

So at what point does the CA become culpable to misissuance in a case
like this? Is it okay that we let them turn a blind eye to issuing or
reissuing certificates where they have a strong reason to believe the
private key will be published in firmware?

Clearly we wouldn't require them to vet every use of every certificate
they issue, but if they revoke a certificate for being used in this
fashion, it seems reasonable for them to ask the customer to at least
give them an explanation of how they've changed things such that a
newly issue certificate for the same domain will not be used in the
exact same way.

Is it reasonable for us to ask a CA to do this (that is, to ask their
customer)? Is it reasonable to require it?

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


Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

2017-06-19 Thread Matt Palmer via dev-security-policy
On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via 
dev-security-policy wrote:
> If you should find such an issue again in a Cisco owned domain, please
> report it to ps...@cisco.com and we will ensure that prompt and proper
> actions are taken.

I don't know, this way seems to have worked Just Fine.

- Matt

___
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-19 Thread Jakob Bohm via dev-security-policy

Notes on your below suggested timeline:

1. I see no reason to have that many new root bundles from Symantec.
  Ideally, there would be just two bundles: A transitional root bundle
  which signs the outsourced SubCAs only, and a final bundle intended
  to become the new long-term Symantec roots.  The transitional root
  bundle would be made in a subset of the current Symantec
  infrastructure, while the final bundle would be generated in the
  new higher security infrastructure isolated from any historic bugs
  in the old infrastructure.

2. For any certificate bundle that needs to be incorporated into the
  Mozilla root stores, a significant period (3 to 6 months at least)
  will be needed between acceptance by Mozilla and actual trust by
  Mozilla users.  This would involve time to complete the following:

2.1 Adding the new roots to the NSS store source code.

2.2 Actually incorporating that updated NSS store into release candidate
  builds of all Mozilla products.

2.3 Releasing those builds of Mozilla products to the general public

2.4a Waiting for the majority of users (especially those with telemetry
  and other phone-home behavior disabled) to install the updated Mozilla
  products.

2.4b Waiting for enterprise users to incorporate the updated Mozilla
  products into new system images and rolling out those system images.

2.4c Waiting for users to migrate beyond Firefox ESR 52 due to
  disrupting non-PKI changes (feature removals) made at that point.
   Similar for future feature-disrupting Mozilla product changes.

(Note this is not a complaint about the breaking changes beyond Fx ESR
52, just an observation that such actions by other Mozilla teams can
cause a significant delay in the deployment of NSS root store changes).



On 16/06/2017 14:43, Peter Kurrasch wrote:

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 Distrust

First 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 

Re: [EXT] Mozilla requirements of Symantec

2017-06-19 Thread Jakob Bohm via dev-security-policy

On 12/06/2017 22:12, Nick Lamb wrote:

On Monday, 12 June 2017 17:31:58 UTC+1, Steve Medin  wrote:

We think it is critically important to distinguish potential removal of support 
for current roots in Firefox versus across NSS. Limiting Firefox trust to a 
subset of roots while leaving NSS unchanged would avoid unintentionally 
damaging ecosystems that are not browser-based but rely on NSS-based roots such 
as code signing, closed ecosystems, libraries, etc.


Abusing NSS to support code signing or "closed ecosystems" would be an error 
regardless of what happens to Symantec, it makes no real sense for us to prioritize 
supporting such abuse. To the extent that m.d.s.policy represents consumers of NSS 
certdata other than Firefox, they've _already_ represented very strongly that what they 
want is for this data to follow Mozilla's trust decisions more closely not less.



I believe you are exaggerating in that assertion.

NSS until fairly recently was in fact used for code signing of Firefox
extensions using the public PKI (this is why there is a defunct code
signing trust bit in the NSS root store).

I also believe that the current checking of "AMO" signatures is still
done by NSS, but not using the public PKI.

This makes it completely reasonable for other users of the NSS libraries
to still use it for code signing, provided that the "code signing" trust
bits in the NSS root store are replaced with an independent list,
possibly based on the CCADB.

It also makes it likely that systems with long development / update
cycles have not yet deployed their own replacement for the code signing
trust bits in the NSS root store, even if they have a semi-automated
system importing changes to the NSS root store.  That would of cause be
a mistake on their part, but a very likely mistake.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Unknown Intermediates

2017-06-19 Thread Daniel Cater via dev-security-policy
On Monday, 19 June 2017 20:57:28 UTC+1, Tavis Ormandy  wrote:
> I noticed there's an apparently valid facebook.com certificate in there
> (61b1526f9d75775c3d533382f36527c9.pem). This is surprising to me, that
> seems like it would be in CT already - so maybe I don't know what I'm doing.
> 
> Let me know if I've misunderstood something.
> 
> Tavis.

Thanks for uploading these. I submitted that one in particular which can now be 
seen here: https://crt.sh/?id=157454198

This is the certificate for a precertificate which was already in the CT logs: 
https://crt.sh/?id=81124044 (crt.sh handily has links in both directions 
between both certificates now that it knows about both) and the issuance is 
therefore "known" already, but the final signed certificate was not seen by any 
logs. It is useful to have the final certificate now as well.

I haven't looked at any of the others, but I imagine this case only covers a 
small percentage of the total. When someone here with a more automated approach 
to submitting the certificates (along with their intermediates) analyses them I 
imagine we will see some interesting results.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: ETSI auditors still not performing full annual audits?

2017-06-19 Thread Kathleen Wilson via dev-security-policy
On Monday, June 19, 2017 at 12:21:46 PM UTC-7, Peter Bowen wrote:
> It seems there is some confusion. The document presented would appear
> to be a Verified Accountant Letter (as defined in the EV Guidelines)
> and can used as part of the process to validate a request for an EV
> certificate.  It is not an audit report and is not something normally
> submitted to browsers.

Yet, it is the document that was provided to root store operators as the annual 
audit statement. And there has been plenty of time in Bug #1142323 for that to 
have been rectified. 

As reference, here is the audit statement that was provided in 2016:
https://bug343756.bmoattachments.org/attachment.cgi?id=8781268
It says: "KPMG has executed a main certification audit in year 2013, and 
surveillance certification audits in 2014 and 2015..."
"We were engaged to conduct the annual examinations, with the objective of 
which would be the expression of an opinion on the application for Extended 
Validation (EV) Certificates. Accordingly we do express our positive opinion 
and provide you confirmation that the requirements were fulfilled during the 
annual certification audits... "


In the audit statement in question 
(https://bug1142323.bmoattachments.org/attachment.cgi?id=8853299) it says:
"KPMG has executed a main certification audit in year 2017..." So I took that 
to mean that this was intended to be their annual audit statement, and the 
format is very similar to the audit statement from the previous year. But as I 
read through it I noticed phrases like "point in time audit". And then it said:
"We were not engaged to and did not conduct an examination, the objective of 
which would be the expression of an opinion on the Application for Extended 
Validation (EV) Certificate. Accordingly, we do not express such an opinion. 
Had we performed additional procedures, other matters might have come to our 
attention that would have been reported to you." 
This is very different from the statement the previous year.

Thanks,
Kathleen

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


Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

2017-06-19 Thread Matthew Hardeman via dev-security-policy
I wonder if the device intercepts DNS queries within the LAN for that address 
and substitutes in the IP of the appliance instead of 127.0.0.1.  Is it often 
deployed as the customer premise NAT/router in addition to serving video 
purposes?

I'm thinking they probably wanted some other devices or browsers on the local 
LAN to access, via https, the appliance on the LAN.  And they wanted it to have 
a trusted cert for that purpose.  They just didn't want to have to deal with 
unique name and cert per device.

Which, as has been pointed out repeatedly is a violation of the CA <-> 
subscriber agreement, because the baselines require that the CA <-> subscriber 
agreement forbid this.

It looks to me like someone wanted to avoid the need to have a unique 
certificate issued for each device.

The easy way forward would be for them to create a new domain, run their own 
dynamic DNS service for each device on that domain (get said domain on the PSL) 
and develop software for it to fetch and update valid certificates for these 
IoT devices.  Presumably they could roll their own DNS infrastructure and even 
use something like Let's Encrypt, though I'm not certain whether Let's Encrypt 
is on the record as to what they'd think of such a use case.

In as far as Cisco has requested a new drmlocal.cisco.com certificate Why?  
They can't use it the new certificate in the same way again (or it would just 
get revoked again) and the real drmlocal.cisco.com record points to 127.0.0.1, 
so it's not like they have a real central drmlocal.cisco.com site that needs a 
certificate.  I think the "local" part of the name is probably most telling.  
They likely came up with that name because ciscodrm.local would have been 
impossible to get a valid cert for.


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


Principles and Goals

2017-06-19 Thread Gervase Markham via dev-security-policy
I think it might be useful to take a step back and remind ourselves of
Mozilla's mission, principles and goals with regard to resolving the
situation with Symantec. These will be useful as we flesh out the
details of the consensus proposal, particularly concerning dates.

First, a quick reminder on goals, anti-goals and non-goals.

Goal:  something you specifically want to achieve.
Anti-goal: something you specifically want to not achieve.
Non-goal:  something you are explicitly not trying to achieve.

Non-goals differ from anti-goals in that you will try hard not to
achieve an anti-goal, but you don't mind either way whether a non-goal
happens or not.

In deciding what is a goal, anti-goal or non-goal, we need to establish
our principles, which in this case I will define as higher-level things
we believe and are trying to achieve with our root program which are not
specific to this particular situation. Mozilla's principles relating to
this situation all flow from our overarching mission to do good to and
for the Web, and the manifesto principle that the security of web
citizens is essential. More specifically, I would characterise our
principles here as follows:

Root Program Principles
---

1) Maintain the public's trust in the WebPKI as a whole.

2) In any change, minimise disruption to websites and web end-users.

3) Make decisions for the benefit of Mozilla and its mission first.

4) Operate in a transparent, consultative and open way.


In this case, we are attempting to maintain trust in the WebPKI by
executing the sub-task of eliminating hierarchies, systems and/or
issuers who have lost trust. So our goals in this particular situation,
where we no longer have trust in Symantec's "old" (current) PKI, are
therefore:

Symantec Remediation Goals
--

A) Remove the roots relating to the old Symantec PKI from our root store
as quickly as possible.

B) Before we can do so, take interim steps to minimise risk by reducing
the scope of trust in their old PKI, such as:

* not trusting new Symantec-controlled issuance;
* not trusting certs without proof of publication; and/or
* not trusting certs issued before a certain date;

all as quickly as possible.

C) Make sure that those certificate users with a hard dependency on
Symantec's old PKI and also a requirement for public trust have, or
mostly have, sufficient transition time to eliminate that dependency.


Something which is a non-goal is that Symantec be able to continue
issuing all the same types of certs at the same volumes to all of their
customers without interruption. This will almost certainly be a goal for
Symantec, but it's not a goal for Mozilla. It must be pointed out that
it's not an anti-goal either - we are not _aiming_ to affect Symantec's
business. But we are not going to take decisions which treat maintaining
those capabilities unchanged as a goal.

This point will become important when Symantec publishes the results of
the process they are currently going through to find CAs to work with
them on taking over issuance from their old PKI. Their plans and the
dates associated with them will, no doubt, be predicated on that goal,
which is not our goal (but to repeat, is not an anti-goal), and will
need to be evaluated in that light. Symantec also need to be clear that
"we signed a contract to meet this goal" is not an argument which will
cause that goal to become Mozilla's goal.

Any set of dates we require which are not "as long as you need" will
inevitably have a level of arbitrariness about them. Why not a week
more? Why not a week less? I think it would be unhelpful, therefore, to
get into a date-based "negotiation". We need to make our best estimate
of how long it would take Symantec and their partners to put in place
systems which allow our goals to be met, and choose deadlines accordingly.

The only other thing which might modify our requirements is the fact
that this is a consensus proposal we are implementing. Consensus is a
good thing for the WebPKI and for Symantec, who I'm sure would not
welcome the prospect of implementing several different remediation plans
at the same time. Therefore, we should also take into account the
published principles and goals of other root store operators who are
part of the consensus, and how the proposal might need to be written to
also meet their goals.

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


Re: Unknown Intermediates

2017-06-19 Thread Tavis Ormandy via dev-security-policy
I noticed there's an apparently valid facebook.com certificate in there
(61b1526f9d75775c3d533382f36527c9.pem). This is surprising to me, that
seems like it would be in CT already - so maybe I don't know what I'm doing.

Let me know if I've misunderstood something.

Tavis.

On Mon, Jun 19, 2017 at 12:41 PM, Tavis Ormandy  wrote:

> Thanks Alex, I took a look, it looks like the check pings crt.sh - is
> doing that for a large number of certificates acceptable Rob?
>
> I made a smaller set, the certificates that have 'SSL server: Yes' or 'Any
> Purpose : Yes', there were only a few thousand that verified, so I just
> checked those and found 551 not in crt.sh.
>
> (The *vast* majority are code signing certificates, many are individual
> apple developer certificates)
>
> Is this useful? if not, what key usage is interesting?
>
> https://lock.cmpxchg8b.com/ServerOrAny.zip
>
> Tavis.
>
> On Mon, Jun 19, 2017 at 7:03 AM, Alex Gaynor  wrote:
>
>> If you're interested in playing around with submitting them yourself, or
>> checking if they're already submitted, I've got some random tools for
>> working with CT: https://github.com/alex/ct-tools
>>
>> Specifically ct-tools check  will get what you
>> want. It's all serial, so for 8M certs you probably want to Bring Your Own
>> Parallelism (I should fix this...)
>>
>> Alex
>>
>> On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote:
>>>
 On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote:

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

>>>
>>> +1
>>>
>>> Tavis, please do post the whole set.  And thanks!
>>>
>>> --
>>> 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
>>>
>>
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Unknown Intermediates

2017-06-19 Thread Tavis Ormandy via dev-security-policy
Thanks Alex, I took a look, it looks like the check pings crt.sh - is doing
that for a large number of certificates acceptable Rob?

I made a smaller set, the certificates that have 'SSL server: Yes' or 'Any
Purpose : Yes', there were only a few thousand that verified, so I just
checked those and found 551 not in crt.sh.

(The *vast* majority are code signing certificates, many are individual
apple developer certificates)

Is this useful? if not, what key usage is interesting?

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

Tavis.

On Mon, Jun 19, 2017 at 7:03 AM, Alex Gaynor  wrote:

> If you're interested in playing around with submitting them yourself, or
> checking if they're already submitted, I've got some random tools for
> working with CT: https://github.com/alex/ct-tools
>
> Specifically ct-tools check  will get what you
> want. It's all serial, so for 8M certs you probably want to Bring Your Own
> Parallelism (I should fix this...)
>
> Alex
>
> On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote:
>>
>>> On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote:
>>>
>> 
>>
>>> 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!
>>>
>>
>> +1
>>
>> Tavis, please do post the whole set.  And thanks!
>>
>> --
>> 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
>>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: ETSI auditors still not performing full annual audits?

2017-06-19 Thread Peter Bowen via dev-security-policy
On Mon, Jun 19, 2017 at 12:14 PM, Kathleen Wilson via
dev-security-policy  wrote:
> I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=1374381 about an 
> audit statement that I received for SwissSign. I have copied the bug 
> description below, because I am concerned that there still may be ETSI 
> auditors (and CAs?) who do not understand the audit requirements, see below.
>
> ~~~
> SwissSign provided their annual audit statement:
> https://bug1142323.bmoattachments.org/attachment.cgi?id=8853299
>
> Problems noted in it:
> -- "Agreed-upon procedures engagement" - special words for audits - does not 
> necessarily encompass the full scope
> -- "surveillance certification audits" - does not necessarily mean a full 
> audit (which the BRs require annually)
> -- "point in time audit" -- this means that the auditor's evaluation only 
> covered that point in time (note a period in time)
> -- "only intended for the client" -- Doesn't meet Mozilla's requirement for 
> public-facing audit statement.
> -- "We were not engaged to and did not conduct an examination, the objective 
> of which would be the expression of an opinion on the Application for 
> Extended Validation (EV) Certificate. Accordingly, we do not express such an 
> opinion. Had we performed additional procedures, other matters might have 
> come to our attention that would have been reported to you." -- some of the 
> included root certs are enabled for EV treatment, so need an EV audit as well.
>
>
> According to section 8.1 of the CA/Browser Forum's Baseline Requirements:
> "Certificates that are capable of being used to issue new certificates MUST 
> ... be ... fully audited in line with all remaining requirements from this 
> section.
> ...
> The period during which the CA issues Certificates SHALL be divided into an 
> unbroken sequence of audit periods. An audit period MUST NOT exceed one year 
> in duration."
>
> So, a full period-in-time audit is required every year.
>
> After I voiced concern 
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1142323#c27) the CA provided an 
> updated audit statement to address the concerns I had raised in the bug:
> https://bugzilla.mozilla.org/attachment.cgi?id=8867948
> I do not understand how the audit statement can magically change from 
> point-in-time to a period-in-time.
> ~~~
>
> I will greatly appreciate thoughtful and constructive input into this 
> discussion about what to do about this SwissSign audit situation, and if this 
> is an indicator that ETSI auditors are still not performing full annual 
> audits that satisfy the CA/Browser Forum's Baseline Requirements.

Kathleen,

It seems there is some confusion. The document presented would appear
to be a Verified Accountant Letter (as defined in the EV Guidelines)
and can used as part of the process to validate a request for an EV
certificate.  It is not an audit report and is not something normally
submitted to browsers.

I suspect someone simply attached the wrong document to an email or
uploaded the wrong document.  This makes no sense to be part of an
audit report.

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


ETSI auditors still not performing full annual audits?

2017-06-19 Thread Kathleen Wilson via dev-security-policy
I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=1374381 about an 
audit statement that I received for SwissSign. I have copied the bug 
description below, because I am concerned that there still may be ETSI auditors 
(and CAs?) who do not understand the audit requirements, see below.

~~~
SwissSign provided their annual audit statement:
https://bug1142323.bmoattachments.org/attachment.cgi?id=8853299

Problems noted in it:
-- "Agreed-upon procedures engagement" - special words for audits - does not 
necessarily encompass the full scope
-- "surveillance certification audits" - does not necessarily mean a full audit 
(which the BRs require annually)
-- "point in time audit" -- this means that the auditor's evaluation only 
covered that point in time (note a period in time)
-- "only intended for the client" -- Doesn't meet Mozilla's requirement for 
public-facing audit statement.
-- "We were not engaged to and did not conduct an examination, the objective of 
which would be the expression of an opinion on the Application for Extended 
Validation (EV) Certificate. Accordingly, we do not express such an opinion. 
Had we performed additional procedures, other matters might have come to our 
attention that would have been reported to you." -- some of the included root 
certs are enabled for EV treatment, so need an EV audit as well.


According to section 8.1 of the CA/Browser Forum's Baseline Requirements: 
"Certificates that are capable of being used to issue new certificates MUST ... 
be ... fully audited in line with all remaining requirements from this section. 
...
The period during which the CA issues Certificates SHALL be divided into an 
unbroken sequence of audit periods. An audit period MUST NOT exceed one year in 
duration."

So, a full period-in-time audit is required every year.

After I voiced concern 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1142323#c27) the CA provided an 
updated audit statement to address the concerns I had raised in the bug:
https://bugzilla.mozilla.org/attachment.cgi?id=8867948
I do not understand how the audit statement can magically change from 
point-in-time to a period-in-time.
~~~

I will greatly appreciate thoughtful and constructive input into this 
discussion about what to do about this SwissSign audit situation, and if this 
is an indicator that ETSI auditors are still not performing full annual audits 
that satisfy the CA/Browser Forum's Baseline Requirements.

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


Re: Unknown Intermediates

2017-06-19 Thread Alex Gaynor via dev-security-policy
If you're interested in playing around with submitting them yourself, or
checking if they're already submitted, I've got some random tools for
working with CT: https://github.com/alex/ct-tools

Specifically ct-tools check  will get what you
want. It's all serial, so for 8M certs you probably want to Bring Your Own
Parallelism (I should fix this...)

Alex

On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote:
>
>> On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote:
>>
> 
>
>> 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!
>>
>
> +1
>
> Tavis, please do post the whole set.  And thanks!
>
> --
> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

2017-06-19 Thread Samuel Pinder via dev-security-policy
There's more than just a clue in the name drmlocal.cisco.com , if one
looks up this address in the DNS it returns the loopback IP 127.0.0.1
. http://dnstools.ws/tools/lookup.php?host=drmlocal.cisco.com=A
This can only mean that this address is fully intended to be referred
to only by one's own machine that the NowTV software is running on.
There's probably an architectural reason why a publicly trusted
certificate is used. But the way it's been implemented clearly does
mean that the private key ends up being shipped, which, even if it
didn't break the Baseline Requirements, it goes against the very
principle of PKI cryptography. Therefore the newly re-issued
certificate *will* end up with it's private key compromised *again*,
no matter how well it may be obfuscated in the application, it is
still against the very principle.
Is a publicly-trusted certificate even needed here? Another this could
have been done is what anti-virus programs often resort to doing:
installing a self-signed root into the OS (and other browser stores)
as part of the client installation process and generating certificates
on-the-fly directly off of it. But then that would mean that if anyone
compromised the key for that, it could potentially put many users whom
use NowTV at risk unless that self-signed root was constrained in some
way. *However* this would mean at least, it no longer breaks the
Baseline Requirements as it would no longer be within it's scope. I'm
no expert here at all, and I do dislike the idea of this kind of
behaviour completely (and I could be completely wrong about why
drmlocal.cisco.com is used). NowTV might want to consider their
options here, but shipping a private key and trusted certificate with
an application, really isn't the way. In summary: I believe a
compromise will happen again as it is clear drmlocal.cisco.com is
deliberately intended to refer to one's own machine.
Sam


On Mon, Jun 19, 2017 at 1:50 PM, Nick Lamb via dev-security-policy
 wrote:
> On Monday, 19 June 2017 09:32:20 UTC+1, troy.f...@cisco.com  wrote:
>>The compromised certificate for drmlocal.cisco.com serial number 
>> 6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 has been revoked.  A new certificate 
>> is being reissued to drmlocal.cisco.com and we will work with the developers 
>> of the YES video player to ensure that the issue does not happen again.
>
> Troy, the name makes me suspicious, what - other than this trick which isn't 
> a permissible use - was the drmlocal.cisco.com name ever for in the first 
> place? If it doesn't have any legitimate use, there was no purpose in seeking 
> a re-issue of the certificate.
>
> The right way to approach this problem will be to issue unique keys and 
> certificates to individual instances of the system, this both satisfies the 
> BRs and (which is why) achieves the actual security goal of partitioning each 
> customer so that they can't MitM each other.
>
> It is a little surprising to me that (at least so far as I know) no 
> manufacturer has an arrangement with a CA to issue them large volumes of 
> per-device certificates in this way. I expect that Comodo (to name one which 
> definitely has business issuing very large volumes) would be able to 
> accommodate a deal to issue say, a million certificates per year with an 
> agreed suffix (say, .nowtv.cisco.com) for a fixed fee. The first time it's 
> attempted there would be some engineering work to be done in production and 
> software for the system, but nothing truly novel and that work is re-usable 
> for future products.
> ___
> 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: Turktrust SubCA abuse and MITM'ing

2017-06-19 Thread davmaz58--- via dev-security-policy
I found two and they were both expired so I disable them and did some research 
which ended me in many sites and also here in this forum. If this happened so 
long ago and was caught why is it in my Galaxy Grand Prime that I bought 
brand-new less than two years ago.This is one- 
TURKTRUST_Certificate_Services_Provider_Root_2.  The thumprint is 
b4:35:d4:e1:11:9d:1c:66:90:a7:49:eb:b3:94:bd:63:7b:a7:82:b7. The other is 
similar but not exact. I disable them but they were there for two years. I 
updated if they're still there. Need advice?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy