date:20160922

RE: Incidents involving the CA WoSign

2016-09-22 Thread Richard Wang

Hi Gerv,

This is the final statement about the incident: 
https://www.wosign.com/report/WoSign_final_statement_09232016.pdf (in English)

https://www.wosign.com/report/WoSign_final_statement_CN_09232016.pdf  (中文版) (In 
Chinese, this is easy for Chinese users.)

I think this is the supplement of the two released reports. 

Please let me if you have any questions about this statement, thanks.

Best Regards,

Richard Wang
CEO
WoSign CA Limited

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Richard Wang
Sent: Friday, September 16, 2016 6:05 PM
To: Gervase Markham 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Incidents involving the CA WoSign

Hi Gerv,

This is the final report: 
https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf 

Please let me if you have any questions about the report, thanks.

Best Regards,

Richard Wang
CEO
WoSign CA Limited

-Original Message-
From: Gervase Markham
Sent: Wednesday, September 7, 2016 7:00 PM
To: Richard Wang; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Hi Richard,

On 07/09/16 11:06, Richard Wang wrote:
> This discuss has been lasting two weeks, I think it is time to end it, 
> it doesn’t worth to waste everybody’s precious time.

Unfortunately, I think we may be only beginning.

I have prepared a list of the issues we are tracking with WoSign's certificate 
issuance process and business:

https://wiki.mozilla.org/CA:WoSign_Issues 

Please can you provide a response to issues F, P, S and T at your earliest 
convenience?

In addition, if you have further things to say about issues D, H, J, L, N or V 
we would be happy to hear them.

Thank you for your suggestions, but once Mozilla has a full understanding of 
what has gone on we will be in a better position to decide what next actions 
are appropriate.

With best wishes,

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

2016-09-22 Thread Richard Wang

Thanks for your hard work. I wish you can finish check for all other CA's 
report ASAP.

For WoSign, the report covered all 4 roots, not 3 roots.

For StartCom, Eddy can say something about it, StartCom is 1000% independent 
for everything at 2015.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Peter Bowen
Sent: Friday, September 23, 2016 10:54 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: WoSign and StartCom audit reports

As hinted at in my earlier email about what is expected in audit reports, I've 
been looking at WebTrust audit reports from many CAs in the Mozilla program and 
those applying to be in the program.

Since there has been lots of discussion about WoSign and Startcom recently, I 
took a look at their latest reports.  I thought others might be interested in 
the result.

Thanks,
Peter

Review of WoSign audit reports
for the period 1 January 2015 to 31 December 2015

Good:
- Uses AICPA standards
- Uses current criteria versions

Bad:
- Only covers three roots, not subordinate CAs (true for all three
reports: CA, BR, and EV)
- Does not provide assurance that subordinate CA certificate requests are 
accurate, authenticated, and approved

Really Bad:
- Includes 'emphasis of matters' which show failures of controls but still 
claims to be an unqualified opinion
- The EV opinion does not note that some of the EV certificates using a SHA-1 
hash in the signature have expiration dates after 2016-12-31


Review of StartCom audit reports
for the period 1 January 2015 to 31 December 2015

Good:
- Uses AICPA standards
- Uses current criteria versions

Bad:
- Only covers two roots, not subordinate CAs (true for all three
reports: CA, BR, and EV)
- Does not provide assurance that subordinate CA certificate requests are 
accurate, authenticated, and approved
- Does not provide assurance that it meets the Network and Certificate System 
Security Requirements as set forth by the CA/Browser Forum 
___
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

WoSign and StartCom audit reports

2016-09-22 Thread Peter Bowen

As hinted at in my earlier email about what is expected in audit
reports, I've been looking at WebTrust audit reports from many CAs in
the Mozilla program and those applying to be in the program.

Since there has been lots of discussion about WoSign and Startcom
recently, I took a look at their latest reports.  I thought others
might be interested in the result.

Thanks,
Peter

Review of WoSign audit reports
for the period 1 January 2015 to 31 December 2015

Good:
- Uses AICPA standards
- Uses current criteria versions

Bad:
- Only covers three roots, not subordinate CAs (true for all three
reports: CA, BR, and EV)
- Does not provide assurance that subordinate CA certificate requests
are accurate, authenticated, and approved

Really Bad:
- Includes 'emphasis of matters' which show failures of controls but
still claims to be an unqualified opinion
- The EV opinion does not note that some of the EV certificates using
a SHA-1 hash in the signature have expiration dates after 2016-12-31


Review of StartCom audit reports
for the period 1 January 2015 to 31 December 2015

Good:
- Uses AICPA standards
- Uses current criteria versions

Bad:
- Only covers two roots, not subordinate CAs (true for all three
reports: CA, BR, and EV)
- Does not provide assurance that subordinate CA certificate requests
are accurate, authenticated, and approved
- Does not provide assurance that it meets the Network and Certificate
System Security Requirements as set forth by the CA/Browser Forum
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Audit requirements

2016-09-22 Thread Peter Bowen

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 CAs need to ensure that all
components of the criteria are included in their report and ensure
that all unconstrained subordinates are identified as being covered by
the reports?

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

Re: Sanctions short of distrust

2016-09-22 Thread Percy

Ha. I was the OP of that email. Richard's reply was " From the screenshot, we 
know why Percy hate WoSign so deeply, we know he represent which CA, everything 
is clear now. "

On Thursday, September 22, 2016 at 11:55:43 AM UTC-7, Eric Mill wrote:
> On Wed, Sep 21, 2016 at 6:18 PM, Richard Wang  wrote:
> 
> >
> > > Do we trust that WoSign will not collect information on hits to any OCSP
> > responders they have set up and share that info with...whomever?
> >
> > Yes, any CA can do this if need. But you can use OCSP Stapling in your web
> > server.
> > We don’t worry about most China online banking system and many ecommerce
> > website using the foreign CA certificate, what do you worry about? As I
> > said, we used Akamai CDN service that all hits will go to Akamai Edge
> > servers first.
> >
> 
> In an earlier thread, someone posted a screenshot of what appeared to be a
> marketing email sent to Let's Encrypt customers, warning them about foreign
> CAs.
> 
> The screenshot image was: https://pbs.twimg.com/media/CrXf7w3W8AA2zd7.jpg:
> large
> 
> And the text as translated by the person who posted the screenshot (which I
> haven't personally verified) was:
> 
> The risks associated with foreign CA:
> 1. Cert revocation
> If foreign CA is influenced by politics and revoke certs for important
> Chinese organizations, the entire system will be paralyzed.
> 
> 2. Information security risks
> If the website uses foreign certs, users need to send information to
> foreign servers in every visit. Time of the visit, the location of the
> visit, IP addresses, and the browser, frequency of the visits are all
> collected by foreign CA. This will leak commercial secrets and sensitive
> data, and is a very risky!
> 
> 
> Here, you're saying you don't consider it to be a threat, and that you
> don't worry if most Chinese online banking and ecommerce websites use a
> foreign CA. Was the screenshot of WoSign's marketing email accurate? And if
> so, what is WoSign committing to doing w/r/t OCSP metadata that it doesn't
> trust foreign CAs to do?
> 
> -- Eric
> 
> 
> >
> >
> > Best Regards,
> >
> > Richard Wang
> > CEO
> > WoSign CA limited
> >
> >
> > From: dev-security-policy [mailto:dev-security-policy-bounces+richard=
> > wosign@lists.mozilla.org] On Behalf Of Peter Kurrasch
> > Sent: Thursday, September 22, 2016 3:06 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Time to distrust (was: Sanctions short of distrust)
> >
> > Do we trust that WoSign will honor requsts for certs to be revoked? Do we
> > trust that revocation will take place in a timely matter? Do we trust that
> > WoSign will not collect information on hits to any OCSP responders they
> > have set up and share that info with...whomever?
> >
> > ___
> > 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: Sanctions short of distrust

2016-09-22 Thread Eric Mill

On Wed, Sep 21, 2016 at 6:18 PM, Richard Wang  wrote:

>
> > Do we trust that WoSign will not collect information on hits to any OCSP
> responders they have set up and share that info with...whomever?
>
> Yes, any CA can do this if need. But you can use OCSP Stapling in your web
> server.
> We don’t worry about most China online banking system and many ecommerce
> website using the foreign CA certificate, what do you worry about? As I
> said, we used Akamai CDN service that all hits will go to Akamai Edge
> servers first.
>

In an earlier thread, someone posted a screenshot of what appeared to be a
marketing email sent to Let's Encrypt customers, warning them about foreign
CAs.

The screenshot image was: https://pbs.twimg.com/media/CrXf7w3W8AA2zd7.jpg:
large

And the text as translated by the person who posted the screenshot (which I
haven't personally verified) was:

The risks associated with foreign CA:
1. Cert revocation
If foreign CA is influenced by politics and revoke certs for important
Chinese organizations, the entire system will be paralyzed.

2. Information security risks
If the website uses foreign certs, users need to send information to
foreign servers in every visit. Time of the visit, the location of the
visit, IP addresses, and the browser, frequency of the visits are all
collected by foreign CA. This will leak commercial secrets and sensitive
data, and is a very risky!

Here, you're saying you don't consider it to be a threat, and that you
don't worry if most Chinese online banking and ecommerce websites use a
foreign CA. Was the screenshot of WoSign's marketing email accurate? And if
so, what is WoSign committing to doing w/r/t OCSP metadata that it doesn't
trust foreign CAs to do?

-- Eric

>
>
> Best Regards,
>
> Richard Wang
> CEO
> WoSign CA limited
>
>
> From: dev-security-policy [mailto:dev-security-policy-bounces+richard=
> wosign@lists.mozilla.org] On Behalf Of Peter Kurrasch
> Sent: Thursday, September 22, 2016 3:06 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Time to distrust (was: Sanctions short of distrust)
>
> Do we trust that WoSign will honor requsts for certs to be revoked? Do we
> trust that revocation will take place in a timely matter? Do we trust that
> WoSign will not collect information on hits to any OCSP responders they
> have set up and share that info with...whomever?
>
> ___
> 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

Removing Government of France root certificate -- issuance of SHA-1 certs detected

2016-09-22 Thread Kathleen Wilson

All,

In https://bugzilla.mozilla.org/show_bug.cgi?id=1301731 it was reported that 
SHA-1 SSL certs have recently been issued in the IGC/A CA Hierarchy that is 
owned by Government of France (ANSSI,DCSSI).

This root cert was already name constrained via 
https://bugzilla.mozilla.org/show_bug.cgi?id=952572

And was already slated for removal after this year via 
https://bugzilla.mozilla.org/show_bug.cgi?id=1272156

Since recently issued SHA-1 SSL certs have been detected, we are going to speed 
up the removal of this root cert. The CA has been cooperative, and they are 
working with their customer to remove these SHA-1 certificates. The CA has 
requested that their root cert be removed, in order to avoid this type of 
situation in the future.

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

Re: OpenSSL OCSP serious vulnerability

2016-09-22 Thread Jakob Bohm


On 22/09/2016 14:16, Richard Wang wrote:

OpenSSL OCSP Status Request extension unbounded memory growth (CVE-2016-6304)

http://security.360.cn/cve/CVE-2016-6304/index.html?from=timeline&isappinstalled=0


Best Regards,

Richard



Let me take this opportunity to thank your parent company Qihoo 360 for
reporting this bug to the OpenSSL team, thus helping to protect us all.

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: Sanctions short of distrust

2016-09-22 Thread Jakob Bohm


On 21/09/2016 21:40, Rob Stradling wrote:

On 21/09/16 15:06, Rob Stradling wrote:


I ran some queries earlier today on the crt.sh DB, to find all CNs,
dNSNames and iPAddresses in all unexpired certs whose issuer names
include either "WoSign" or "StartCom".  Then I cross-referenced that
with the latest PSL data to discover the unique base domains:


Someone contacted me off-list (thanks!) to point out that my lists were
incomplete.  I'd missed a load of base domains delegated below the new
gTLDs.  (I hadn't spotted that my local copy of
https://data.iana.org/TLD/tlds-alpha-by-domain.txt was rather out of date).

Updated count and gists...

WoSign:
  Unique Base Domains: 127,355

StartCom:
  Unique Base Domains: 259,712

https://gist.githubusercontent.com/robstradling/813138699b8527c1af58b4aa784c2d8f/raw/11fc8efbb0e594a12b3c5e2e76d9a9e474e24ea9/wosign_base_domains.txt

https://gist.githubusercontent.com/robstradling/813138699b8527c1af58b4aa784c2d8f/raw/11fc8efbb0e594a12b3c5e2e76d9a9e474e24ea9/startcom_base_domains.txt


WoSign:
  Unique CNs/dNSNames: 395,222
  Unique Base Domains: 118,785
  Unique IP Addresses: 154

StartCom:
  Unique CNs/dNSNames: 706,020
  Unique Base Domains: 249,841
  Unique IP Addresses: 0





While you are at it:

1. How many WoSign/StartCom certificates did you find with domains not
  on that IANA list?

2. How many WoSign/StartCom certificates did you find for other uses
  than https://www.example.tld:

2.1 Certificates for "odd" subdomains such as "extranet.example.com"

2.2 Certificates for e-mail

2.3 Code signing certificates

2.4 Others?



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

OpenSSL OCSP serious vulnerability

2016-09-22 Thread Richard Wang

OpenSSL OCSP Status Request extension unbounded memory growth (CVE-2016-6304)

http://security.360.cn/cve/CVE-2016-6304/index.html?from=timeline&isappinstalled=0


Best Regards,

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

Re: Time to distrust

2016-09-22 Thread Gervase Markham

On 22/09/16 03:00, Peter Kurrasch wrote:
> Well, well. Here we are again, Ryan, with you launching into a bullying,
> personal attack on me instead of seeking to understand where I'm coming
> from and why I say the things I say.

Er, no. I am entirely comfortable with saying that if you found Ryan's
message to be a bullying, personal attack then your skin is too thin.
(Which would surprise me, given what I know of you.)

Ryan's message, while possibly carrying a slightly exasperated tone, was
a reasonable exposition of the trade-offs inherent in various options
for dis-trusting a CA, trade-offs which you seem unwilling to recognise.
I'm sad that you don't see this as a set of trade-offs, but perhaps
there's little I or Ryan can do about it.

> ‎If Kathleen or Gerv or Richard decide that I'm
> disruptive and not providing any value to the wider population, I'll
> happily withdraw from this forum. 

I am not requesting that you withdraw, although you should know that the
level of account taken of what you say is approximately proportional to
the level of understanding that you show of the perspectives of all
parties involved - including those currently using WoSign certificates
for their sites.

Gerv

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

Re: Taiwan GRCA Root Renewal Request

2016-09-22 Thread horn917

Peter Bowen於 2016年9月20日星期二 UTC+8下午11時53分29秒寫道：
> On Fri, Sep 16, 2016 at 2:00 PM, Kathleen Wilson  wrote:
> >
> > * CA Hierarchy: Diagram of CA Hierarchy: http://grca.nat.gov.tw/
> > All subordinate CAs are operated by Taiwan Government organizations.
> > GCA is responsible for signing certificates for government agencies. This 
> > is the only intermediate cert that can issue SSL certs.
> > XCA is responsible for signing certificates for organizations;
> > MOICA is responsible for signing certificates for citizens;
> > MOEACA is responsible for signing certificates for corporations; and
> > HCA is responsible for signing certificates for health agencies.
> >
> > * Audit: Annual audits are performed by KPMG according to the WebTrust 
> > criteria.
> > WebTrust CA: https://cert.webtrust.org/SealFile?seal=2050&file=pdf
> > WebTrust BR: https://cert.webtrust.org/SealFile?seal=2051&file=pdf
> 
> I'm having trouble matching up the audits with the subordinate CAs.
> There are two different CAs with the same Distinguished Name but
> different SubjectPublicKeyInfo and KeyIDs (https://crt.sh/?caid=186
> and https://crt.sh/?caid=1330) which makes it trickier than normal,
> but either way I'm not seeing all of these subordinates covered in the
> audit reports.  Can someone please provide a link to each audit report
> for each subordinate?
> 
> Thanks,
> Peter

GRCA WebTrust CA 
(http://grca.nat.gov.tw/download/Audit/GRCA_Audit_Report_2016.pdf)

GCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/GCA_WTCA_Report_2016.pdf)
GCA BR (http://grca.nat.gov.tw/download/Audit/GCA_BR_Audit_Report_2015.pdf)

XCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/XCA_Report_2016.pdf)

HCA WebTrust CA 
(http://grca.nat.gov.tw/download/Audit/HCA_WTCA_Audit_Report_2015.pdf)

MOEACA WebTrust CA 
(http://grca.nat.gov.tw/download/Audit/MOEACA_Audit_Report_2015.pdf)

MOICA WebTrust CA 
(http://grca.nat.gov.tw/download/Audit/MOICA_Audit_Report_2015.pdf)


National Development Council (TW)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

RE: WoSign and StartCom audit reports

WoSign and StartCom audit reports

Audit requirements

Re: Sanctions short of distrust

Re: Sanctions short of distrust

Removing Government of France root certificate -- issuance of SHA-1 certs detected

Re: OpenSSL OCSP serious vulnerability

Re: Sanctions short of distrust

OpenSSL OCSP serious vulnerability

Re: Time to distrust

Re: Taiwan GRCA Root Renewal Request

12 matches

Site Navigation

Mail list logo

Footer information