New Roots? (was: WoSign and StartCom)

[Peter Kurrasch]

I think we're well past the point where a "do-over" can be considered a 
reasonable remedy. The problem is not simply one in which certs were issued 
improperly nor is it simply one in which ‎there were mistakes in the CA 
infrastructure. Such problems, I think, could fall under a category where 
starting over with new roots, new audits, etc. would seem acceptable. 

Rather, what we have here is basically a rogue operator that has threatened the 
trust and integrity of the global PKI system. Their conduct‎ has undermined 
efforts to establish and maintain security on the Internet (e.g. backdating 
SHA-1 certs). Their conduct has flaunted rules and regulations for reasons that 
are still to this day not fully understood (e.g. ownership and problems with 
the auditng). Their conduct has caused undue consternation to web site owners 
(e.g. github) due to cert mis-issuance. Their conduct has put their own 
customers in a difficult position as they must now consider obtaining new certs 
for their websites.

Starting over with new roots won't remedy these problems.

  Original Message  
From: Stephen Schrauger
Sent: Tuesday, September 27, 2016 7:32 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: WoSign and StartCom

> > Should StartCom/WoSign be permitted to re-apply using the same roots,
> > or would they need new roots?
> 
> New roots. Considering the extent to which StartCom/WoSign have
> mismanaged things, there could be further misissued certificates
> chaining to their roots that we don't know about. The only way to
> protect the ecosystem from such certificates is to require new roots -
> roots that have only ever operated under the new audits that will be
> required by Mozilla.
> 
> Regards,
> Andrew

I agree that they should need new roots. But on top of the points Andrew makes, 
it would also require StartCom and WoSign to get cross-signed if they wish to 
continue supporting older devices that lack their new roots. 

They would have to regain the trust of another root CA who would be willing to 
cross-sign their new roots. Or else StartCom and WoSign would have to accept 
that new certificates created under their new root may not work on older 
devices, since older computers and embedded devices aren't always able to 
update their root stores.

Assuming they want new certificates to work on older devices, I imagine the 
need to be cross-signed would create another point of trust, since another CA 
willing to cross-sign would do their own audit and have added requirements.
___
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: WoSign and StartCom: next steps

[谭晓生]

So far 360 is just an investor of Wosign, but we think we need to do something 
because of what happened.
I’d like to have suggestions from Gev to see if Richard Wang to join the 
meeting is a better proposal.

Thanks，
Xiaosheng Tan


在 16/9/30 上午10:03，“dev-security-policy 代表 Peter 
Kurrasch” 写入:

So if WoSign will not be present to discuss possible sanctions against 
WoSign, what are we to infer from that? Is Qihoo 360 acting in a capacity that 
is more than just an investor in WoSign? 

I'm trying not to get too far ahead of things, but this seems to be a very 
curious turn of events.


  Original Message  
From: Gervase Markham
Sent: Thursday, September 29, 2016 10:41 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: WoSign and StartCom: next steps

Hi everyone,

Following the publication of the recent investigative report,
representatives of Qihoo 360 and StartCom have requested a face-to-face
meeting with Mozilla. We have accepted, and that meeting will take place
next Tuesday in London.

After that, we expect to see a public response and proposal for
remediation from them, which will be discussed here before Mozilla makes
a final decision on the action we will take.

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


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

Re: WoSign and StartCom: next steps

[Vincent Lynch]

Hi Peter,

If you look in the original thread on M.S.D.P you will see that Qihoo made
a statement that they owned a majority share in WoSign. Im sure that
Mozilla has ensured Qihoo has the proper authority and permission to speak
on behalf of WoSign.

-Vincent

On Thu, Sep 29, 2016 at 10:03 PM, Peter Kurrasch  wrote:

> So if WoSign will not be present to discuss possible sanctions against
> WoSign, what are we to infer from that? Is Qihoo 360 acting in a capacity
> that is more than just an investor in WoSign?
>
> I'm trying not to get too far ahead of things, but this seems to be a very
> curious turn of events.
>
>
>   Original Message
> From: Gervase Markham
> Sent: Thursday, September 29, 2016 10:41 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: WoSign and StartCom: next steps
>
> Hi everyone,
>
> Following the publication of the recent investigative report,
> representatives of Qihoo 360 and StartCom have requested a face-to-face
> meeting with Mozilla. We have accepted, and that meeting will take place
> next Tuesday in London.
>
> After that, we expect to see a public response and proposal for
> remediation from them, which will be discussed here before Mozilla makes
> a final decision on the action we will take.
>
> Gerv
> ___
> 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
>



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

Re: WoSign and StartCom: next steps

[Peter Kurrasch]

So if WoSign will not be present to discuss possible sanctions against WoSign, 
what are we to infer from that? Is Qihoo 360 acting in a capacity that is more 
than just an investor in WoSign? 

I'm trying not to get too far ahead of things, but this seems to be a very 
curious turn of events.


  Original Message  
From: Gervase Markham
Sent: Thursday, September 29, 2016 10:41 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: WoSign and StartCom: next steps

Hi everyone,

Following the publication of the recent investigative report,
representatives of Qihoo 360 and StartCom have requested a face-to-face
meeting with Mozilla. We have accepted, and that meeting will take place
next Tuesday in London.

After that, we expect to see a public response and proposal for
remediation from them, which will be discussed here before Mozilla makes
a final decision on the action we will take.

Gerv
___
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: WoSign and StartCom: next steps

[Percy]

On Thursday, September 29, 2016 at 10:12:37 AM UTC-7, Han Yuwei wrote:
> 在 2016年9月29日星期四 UTC+8下午11:41:12，Gervase Markham写道：
> > Hi everyone,
> > 
> > Following the publication of the recent investigative report,
> > representatives of Qihoo 360 and StartCom have requested a face-to-face
> > meeting with Mozilla. We have accepted, and that meeting will take place
> > next Tuesday in London.
> > 
> > After that, we expect to see a public response and proposal for
> > remediation from them, which will be discussed here before Mozilla makes
> > a final decision on the action we will take.
> > 
> > Gerv
> 
> Could you disclosure what would you talk about or would be determined on the 
> meeting? And would there be a video or transcript about your meeting?

In the original document,  Mozilla stated that it "is committed to a fair, 
transparent and thorough investigation of the facts of each case." So I think 
at least a summary of the meeting is warranted, if the meeting results in any 
change of Mozilla's previous proposal against WoSign/StartCom.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign and StartCom: next steps

[Han Yuwei]

在 2016年9月29日星期四 UTC+8下午11:41:12，Gervase Markham写道：
> Hi everyone,
> 
> Following the publication of the recent investigative report,
> representatives of Qihoo 360 and StartCom have requested a face-to-face
> meeting with Mozilla. We have accepted, and that meeting will take place
> next Tuesday in London.
> 
> After that, we expect to see a public response and proposal for
> remediation from them, which will be discussed here before Mozilla makes
> a final decision on the action we will take.
> 
> Gerv

Could you disclosure what would you talk about or would be determined on the 
meeting? And would there be a video or transcript about your meeting?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

WoSign and StartCom: next steps

[Gervase Markham]

Hi everyone,

Following the publication of the recent investigative report,
representatives of Qihoo 360 and StartCom have requested a face-to-face
meeting with Mozilla. We have accepted, and that meeting will take place
next Tuesday in London.

After that, we expect to see a public response and proposal for
remediation from them, which will be discussed here before Mozilla makes
a final decision on the action we will take.

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

Re: Audit requirements

[Erwann Abalea]

Bonjour,

Le jeudi 29 septembre 2016 11:45:39 UTC+2, Varga Viktor a écrit :
> Dear Peter,
> 
> I am deeply in ETSI process, so I can give info some info:
> 
> Formerly the ETSIs are based on
> 
> *102042 for CAs
> *101456 for CAs issuing qualified certificates (refernces frequently 
> the 102042)
> 
> o   BRG and EV is referenced from them for SSL and EV SSL certificate 
> issuance.
> 
> The new version of these : (2016-02) (these are based on the 910/2014/EC 
> regulation, which makes a common EU market.)
> 
> *319411-1 for CAs
> *319412-2 for CAs issuing qualified certificates (refernces 
> frequently the 319411-1)

You meant 319411-2 here. (319412-* are certificate profiles).

> o   319401 is referenced from them for technical requirements (technical 
> requirements from 102042 and 101456 were ripped of into this documents)
> 
> o   319412-1 ,-2, -3, -4, -5 referenced from them for certificate profiles
> o   BRG and EV is referenced from them for SSL and EV SSL certificate 
> issuance.

319412-2 and 319412-3 are not used for TLS server certificates, 319412-1 is 
general and introduces some semantic identifiers that could be used in TLS 
server certs, 319412-4 is dedicated to TLS server certificates but is mostly an 
empty shell relying on EVG and BR, 319412-5 adds the QCStatements extension 
(MUST be present for Qualified certs, MAY be present for non Qualified certs).

> For EU CAs the Microsoft forces to move to ETSI audit instead Webtrust.

No.

> The ETSI audit checks:
> 
> *that the certificate issuance systems and environment are compliant 
> with the technical or requirements. (against 319401)
> *that the certificate profiles meet the requirements (against 319412s)
> *the CP/CPS and the practice of issuance compliant with the 319411-1 
> (and for qualified certificates with 319411-2)
> 
> o   the 319411-1 and 319411-2 defines various Certification policies, and 
> rules for them.
> 
> LCP, NCP, NCP+, DVCP, IVCP, OVCP, EVCP, and also the new qualified ones 
> (qcp-n, qpc-l, qcp-n-qscd, qcp-l-qscd, qcp-w)
> 
> For DVCP, OVCP, IVCP, OVCP they references BRG and EVGL (and also for qcp-w, 
> which looks like a chimera for me :) )
> 
> At the end of audit each issuing subcas are checked against the compliance 
> with issuing policies, profiles, and technical requirements.
> 
> Of-course the ETSI report, or its Annex also includes the whole list of the 
> subordinates too.
> 
> Also the Microsoft doesn't accepts audit report without the subordinate list, 
> so its mandatory nowadays.
> 
> I think what is important to add the 319411-1 and -2 to the actual acceptable 
> audit requirements, because the MS ask for this, and it older version (119411 
> included in the 2.3 proposal)

My view is that 319411-2 may be an acceptable audit requirements, but since 
QCP-w certificates (the chimera) are not easily compared to EV certificates 
(because the "Qualified" attribute is granted by a supervisory body to a TSP 
established on its territory only), it's useless to add 319411-2 as acceptable 
(a CA will necessarily be 319411-1).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Audit requirements

[Varga Viktor]

Dear Peter,



I am deeply in ETSI process, so I can give info some info:



Formerly the ETSIs are based on

*102042 for CAs

*101456 for CAs issuing qualified certificates (refernces frequently 
the 102042)

o   BRG and EV is referenced from them for SSL and EV SSL certificate issuance.



The new version of these : (2016-02) (these are based on the 910/2014/EC 
regulation, which makes a common EU market.)

*319411-1 for CAs

*319412-2 for CAs issuing qualified certificates (refernces frequently 
the 319411-1)

o   319401 is referenced from them for technical requirements (technical 
requirements from 102042 and 101456 were ripped of into this documents)

o   319412-1 ,-2, -3, -4, -5 referenced from them for certificate profiles

o   BRG and EV is referenced from them for SSL and EV SSL certificate issuance.



For EU CAs the Microsoft forces to move to ETSI audit instead Webtrust.



The ETSI audit checks:

*that the certificate issuance systems and environment are compliant 
with the technical or requirements. (against 319401)

*that the certificate profiles meet the requirements (against 319412s)

*the CP/CPS and the practice of issuance compliant with the 319411-1 
(and for qualified certificates with 319411-2)

o   the 319411-1 and 319411-2 defines various Certification policies, and rules 
for them.

LCP, NCP, NCP+, DVCP, IVCP, OVCP, EVCP, and also the new qualified ones (qcp-n, 
qpc-l, qcp-n-qscd, qcp-l-qscd, qcp-w)

For DVCP, OVCP, IVCP, OVCP they references BRG and EVGL (and also for qcp-w, 
which looks like a chimera for me :) )



At the end of audit each issuing subcas are checked against the compliance with 
issuing policies, profiles, and technical requirements.

Of-course the ETSI report, or its Annex also includes the whole list of the 
subordinates too.

Also the Microsoft doesn't accepts audit report without the subordinate list, 
so its mandatory nowadays.



I think what is important to add the 319411-1 and -2 to the actual acceptable 
audit requirements, because the MS ask for this, and it older version (119411 
included in the 2.3 proposal)



At october I would like to upload our new audit reports to Salesforce, which 
are made aganst the 319411-s.

üdvözlettel //sincerelly yours,
Viktor Varga
Netlock
chief architect











-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+varga.viktor=netlock...@lists.mozilla.org] 
On Behalf Of Peter Bowen
Sent: Friday, September 23, 2016 12:57 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: Audit requirements



Kathleen, Gerv, Richard and m.d.s.p,



In reviewing the WebTrust audit documentation submitted by various CA program 
members and organizations wishing to be members, it seems there is possibly 
some confusion on what is required by Mozilla.  I suspect this might also span 
to ETSI audit documentation, but I don't know the ETSI process as well, so will 
leave it to some else to determine if there is confusion there.



The first part of the confusion comes from the scope of the audit.

When engaging an auditor to provide attestion services, it is up to the 
organization to define the scope of the audit.  For audits utilizing the 
WebTrust criteria, the scope could be all parts of the criteria.  According to 
auditors I have spoken with, the report will indicate which portions of the 
criteria were in scope for the audit by including a statement of items in scope 
on the management assertion.

If the assertion does not include an item, or the auditor does not express an 
opinion about the item, then it should be assumed to be out of scope.



I have seen a number of reports that do not include all of the criteria be in 
scope.  Specifically, many reports do not provide an opinion on criteria 7 
("Subordinate CA Certificate Life Cycle

Management") of the Trust Services and Principles and Criteria for 
Certification Authorities.  Given the emphasis on subordinate CAs in the 
Mozilla policy, it would seem that this should be required for any CA which 
does not the zero path length constraint.  The current inclusion policy item 11 
presumably includes this already, but does not specifically state that all 
parts of the listed criteria must be included.



The second item of confusion seems to be which CA certificate subjects must be 
audited.  A number of CAs only include the subjects of CA certificates directly 
included in the Mozilla products and do not include the subjects of subordinate 
CA certificates.  My impression is that there should be a report clearly 
covering each of subject of a unconstrained CA certificate in the heirarchy, as 
described in item 8 of the inclusion policy.  This includes a Baseline 
Requirements report for any unconstrained CA, even if the CA is not intended to 
be used for server authentication ("SSL") certificates.



What is Mozilla's expectation?  Do 

Re: Cerificate Concern about Cloudflare's DNS

[Florian Weimer]

* Patrick Figel:

> On 17/09/16 16:38, Florian Weimer wrote:
>> * Peter Bowen:
>> 
>>> On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei 
>>> wrote:
 So when I delegated the DNS service to Cloudflare, Cloudflare 
 have the privilege to issue the certificate by default? Can I 
 understand like that?
>>> 
>>> I would guess that they have a clause in their terms of service or 
>>> customer agreement that says they can update records in the DNS 
>>> zone and/or calls out that the subscriber consents to them getting
>>> a certificate for any domain name hosted on CloudFlare DNS.
>> 
>> I find it difficult to believe that the policies permit Cloudflare's 
>> behavior, but are expected to prevent the issue of interception 
>> certificates.  Aren't they rather similar, structurally?
>
> I don't see how they're similar. Interception certificates are issued
> without the knowledge and permission of the domain owner. Someone
> signing up for CloudFlare willingly chooses to trust a CDN provider with
> all their web traffic and DNS (in order to enable CloudFlare for a
> domain, the NS record for that domain needs to point to CloudFlare.)
>
> I could understand this argument if they'd somehow pretend to be a
> DNS-only provider and then abuse that to issue certificates. However,
> nothing about their site (or their marketing approach in general) gives
> me that impression - it's made quite clear that they're primarily a CDN
> with SSL support.

Well, there is .

My concern goes like this: If I move my infrastructure to Cloudflare,
I give them implied permission, based on their terms of service, to
obtain a X.509 certificate for my domain names hosted there, so that
they can intercept traffic.

On the other hand, if I move my infrastructure to Germany, I give the
German authorities implied permission, based on applicable German law,
to ask my service provide to obtain an X.509 certificate for my domain
names hosted there, so that they can intercept traffic in the clear
(in accordance with German law).

In both cases, we have implied consent, but the alleged certificate
subscriber never has control over the private key, and how it is used.
I don't think neither setup is intended to exist per the Mozilla CA
guidelines.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy