Re: Second Discussion of CFCA Root Inclusion Request

[Kathleen Wilson]

Thanks to all of you who reviewed and commented on this request from 
CFCA to include the “CFCA EV ROOT” root certificate, turn on the 
websites trust bit, and enable EV treatment.


I am closing this discussion, and I will recommend approval in the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=926029

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen

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

Re: Second Discussion of CFCA Root Inclusion Request

[Kathleen Wilson]

On 1/20/15 12:25 PM, Kathleen Wilson wrote:

On 1/7/15 1:23 PM, Kathleen Wilson wrote:

China Financial Certification Authority (CFCA) has applied to include
the “CFCA EV ROOT” root certificate, turn on the websites trust bit, and
enable EV treatment.

The first discussion resulted in CA action items, which have been
completed.
https://groups.google.com/d/msg/mozilla.dev.security.policy/2G6KuAT9Ekk/GyakphSLS5EJ


https://bugzilla.mozilla.org/show_bug.cgi?id=926029#c26

For your convenience, and because the request has been changed to be
just for the EV root, I will re-summarize the request below.

CFCA is a national authority of security authentication approved by the
People’s Bank of China and state information security administration.
CFCA is a critical national infrastructure of financial information
security and one of the first certification service suppliers granted a
certification service license after the release of the Electronic
Signature Law of the People’s Republic of China. There are more than 200
Chinese banks that are using CFCA’s certificates to ensure the security
of online banking trade.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=926029

And in the pending certificates list:
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/pending/



Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8545426

Noteworthy points:

* The primary documents are the CPS and CP, which are provided in
Chinese, and the CPS has been translated into English.

Document repository: http://www.cfca.com.cn/us/us-12.htm
CPS (Chinese) http://www.cfca.com.cn/file/qqfwq-cps.zip
CP (Chinese): http://www.cfca.com.cn/file/qqfwq-cp.zip

CPS (English): http://www.cfca.com.cn/file/CFCA-1403-CPS-en.rar

* CA Hierarchy: The “CFCA EV ROOT” root has one internally-operated
subordinate CA, “CFCA EV OCA”, which issues EV SSL certificates.

* This request is to turn on the websites trust bit for the “CFCA EV
ROOT” root certificate, and enable EV treatment.



All,

Does anyone have questions or comments about CFCA's request for root
inclusion and EV treatment?

Thanks,
Kathleen





Thanks, Erwann, for reviewing and commenting on this request again.

I believe that all of the questions and concerns that were raised during 
the first discussion and this discussion have been resolved.


If there are no further questions or comments about CFCA's root 
inclusion request, then I will close this discussion and recommend 
approval in the bug.


Thanks,
Kathleen


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

Re: Second Discussion of CFCA Root Inclusion Request

[cfcazhaogaixia]

在 2015年1月23日星期五 UTC+8上午12:20:38，Erwann Abalea写道：
> Le mercredi 7 janvier 2015 22:25:00 UTC+1, Kathleen Wilson a écrit :
> > China Financial Certification Authority (CFCA) has applied to include 
> > the "CFCA EV ROOT" root certificate, turn on the websites trust bit, and 
> > enable EV treatment.
> [...]
> > * Root Cert: https://bugzilla.mozilla.org/attachment.cgi?id=8356494
> > 
> > * Test Website: https://pub.cebnet.com.cn
> > 
> > * OCSP
> > http://ocsp.cfca.com.cn/ocsp/
> > CPS 4.8.9: The maximum validity period for OCSP response does not exceed 
> > 7 days.
> 
> Sorry for the delay.
> 
> Getting the CRL issued by "CFCA EV ROOT" shows 2 revoked certificates (serial 
> numbers 0x844543D3B8 and 0xE6A7F45CF7).
> When requesting the OCSP for the status of these serial numbers, the OCSP 
> responder replies with an "unknown" status.

Erwann, Thanks for your review.

We checked the issue you mentioned, it appears that the 2 certificate with SN 
0x844543D3B8 and 0xE6A7F45CF7 are OCSP signing certificates we replaced in 2014 
in order to conform Baseline Requirement.

The problem is resolved by now, OCSP responses for 0x844543D3B8 and 
0xE6A7F45CF7 are revoked instead of unknown.

Ocsp signing certificates's revoke status in OCSP system use to be offline for 
EV OCA level.
These certificates can't issue any certificates or be used as website 
certificates.

Now we updated the model, once there is any changes take place in EV OCA level, 
including issuance of new (EV OCA level)certificates and certificates 
revoke/replace(in EV OCA level) , the database of OCSP service for EV OCA level 
will update.

So this problem won't happen again.
In addition, this problem do not affect our current subscriber/user.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Second Discussion of CFCA Root Inclusion Request

[Erwann Abalea]

Le mercredi 7 janvier 2015 22:25:00 UTC+1, Kathleen Wilson a écrit :
> China Financial Certification Authority (CFCA) has applied to include 
> the "CFCA EV ROOT" root certificate, turn on the websites trust bit, and 
> enable EV treatment.
[...]
> * Root Cert: https://bugzilla.mozilla.org/attachment.cgi?id=8356494
> 
> * Test Website: https://pub.cebnet.com.cn
> 
> * OCSP
> http://ocsp.cfca.com.cn/ocsp/
> CPS 4.8.9: The maximum validity period for OCSP response does not exceed 
> 7 days.

Sorry for the delay.

Getting the CRL issued by "CFCA EV ROOT" shows 2 revoked certificates (serial 
numbers 0x844543D3B8 and 0xE6A7F45CF7).
When requesting the OCSP for the status of these serial numbers, the OCSP 
responder replies with an "unknown" status.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Second Discussion of CFCA Root Inclusion Request

[Kathleen Wilson]

On 1/7/15 1:23 PM, Kathleen Wilson wrote:

China Financial Certification Authority (CFCA) has applied to include
the “CFCA EV ROOT” root certificate, turn on the websites trust bit, and
enable EV treatment.

The first discussion resulted in CA action items, which have been
completed.
https://groups.google.com/d/msg/mozilla.dev.security.policy/2G6KuAT9Ekk/GyakphSLS5EJ

https://bugzilla.mozilla.org/show_bug.cgi?id=926029#c26

For your convenience, and because the request has been changed to be
just for the EV root, I will re-summarize the request below.

CFCA is a national authority of security authentication approved by the
People’s Bank of China and state information security administration.
CFCA is a critical national infrastructure of financial information
security and one of the first certification service suppliers granted a
certification service license after the release of the Electronic
Signature Law of the People’s Republic of China. There are more than 200
Chinese banks that are using CFCA’s certificates to ensure the security
of online banking trade.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=926029

And in the pending certificates list:
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/pending/


Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8545426

Noteworthy points:

* The primary documents are the CPS and CP, which are provided in
Chinese, and the CPS has been translated into English.

Document repository: http://www.cfca.com.cn/us/us-12.htm
CPS (Chinese) http://www.cfca.com.cn/file/qqfwq-cps.zip
CP (Chinese): http://www.cfca.com.cn/file/qqfwq-cp.zip

CPS (English): http://www.cfca.com.cn/file/CFCA-1403-CPS-en.rar

* CA Hierarchy: The “CFCA EV ROOT” root has one internally-operated
subordinate CA, “CFCA EV OCA”, which issues EV SSL certificates.

* This request is to turn on the websites trust bit for the “CFCA EV
ROOT” root certificate, and enable EV treatment.



All,

Does anyone have questions or comments about CFCA's request for root 
inclusion and EV treatment?


Thanks,
Kathleen


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

Re: Second Discussion of CFCA Root Inclusion Request

[cfcazhaogaixia]

I'm CFCA's representative Zhao GaiXia and this is the officially respond 
account(using google groups). 

Thanks for your reply!

CFCA do not have limits relate to TLDs in SSL certificates, as is listed above
http://www.cfca.com.cn/file/CFCA-1403-CPS-en.rar 
"
** CPS section 3.2.2.4: Applications for EV SSL Certificates can only be 
submitted to CFCA. The subject must be the domain name of the web 
server, not the IP address. The domain name must not contain wildcards. 
The applicants can only be private organizations, business entities, 
government entities and non-commercial entities and should meet the 
following requirements: ... 
"

The survey from the University of Michigan may reflect the status of customers 
of CFCA for a period, but it's not a specification or a statement such as CPS.

for example the EV certificate in the test website https://pub.cebnet.com.cn is 
an EV certificate with TLD "cn"

and as listed above, if an organization wants an EV certificate with TLD "org", 
and conform all specifications and standards including CPS 3.2.2.4, there is no 
reason to reject.

CFCA do not have plans to be name constrained for EV/GT system now.


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

Re: Second Discussion of CFCA Root Inclusion Request

[Richard Barnes]

This question is somewhat unrelated to the inclusion of CFCA in the root
program, but I'm interested to know the answer:

Based on some survey data I've gotten from the University of Michigan, it
appears that the CFCA root(s) have been used only within a limited scope
(TLDs in issued EE certificates):

CFCA OCA2: cn, com, net
CFCA EV OCA: com

Does CFCA agree with this assessment, or are there certificates that were
missed by the UMich survey?

Would CFCA be willing to be name constrained by relying party software to
names ending in .cn, .com, or .net?  (Thus, relying parties would reject
certificates for names under other TLDs that chain to CFCA.)  This
constraint would help bound the risk posed by errors or compromises at CFCA
or any subordinates.

--Richard



On Wed, Jan 7, 2015 at 9:23 PM, Kathleen Wilson  wrote:

> China Financial Certification Authority (CFCA) has applied to include the
> “CFCA EV ROOT” root certificate, turn on the websites trust bit, and enable
> EV treatment.
>
> The first discussion resulted in CA action items, which have been
> completed.
> https://groups.google.com/d/msg/mozilla.dev.security.policy/2G6KuAT9Ekk/
> GyakphSLS5EJ
> https://bugzilla.mozilla.org/show_bug.cgi?id=926029#c26
>
> For your convenience, and because the request has been changed to be just
> for the EV root, I will re-summarize the request below.
>
> CFCA is a national authority of security authentication approved by the
> People’s Bank of China and state information security administration. CFCA
> is a critical national infrastructure of financial information security and
> one of the first certification service suppliers granted a certification
> service license after the release of the Electronic Signature Law of the
> People’s Republic of China. There are more than 200 Chinese banks that are
> using CFCA’s certificates to ensure the security of online banking trade.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=926029
>
> And in the pending certificates list:
> http://www.mozilla.org/en-US/about/governance/policies/
> security-group/certs/pending/
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=8545426
>
> Noteworthy points:
>
> * The primary documents are the CPS and CP, which are provided in Chinese,
> and the CPS has been translated into English.
>
> Document repository: http://www.cfca.com.cn/us/us-12.htm
> CPS (Chinese) http://www.cfca.com.cn/file/qqfwq-cps.zip
> CP (Chinese): http://www.cfca.com.cn/file/qqfwq-cp.zip
>
> CPS (English): http://www.cfca.com.cn/file/CFCA-1403-CPS-en.rar
>
> * CA Hierarchy: The “CFCA EV ROOT” root has one internally-operated
> subordinate CA, “CFCA EV OCA”, which issues EV SSL certificates.
>
> * This request is to turn on the websites trust bit for the “CFCA EV ROOT”
> root certificate, and enable EV treatment.
>
> ** CPS section 3.2.2.3: Applications for SSL Certificates can only be
> submitted to CFCA, who accepts applications from both organizations and
> individuals.
>
> ** CPS section 3.2.2.3: CFCA verifies not only the ID, address, and
> country of the applicant, but also the IP and the compliance of CSR. The
> procedures are as follows:
> CFCA performs a WHOIS inquiry on the internet for the domain name supplied
> by the applicant, to verify that the applicant is the entity to whom the
> domain name is registered. Where the WHOIS record indicates otherwise, CFCA
> will ask for a letter of authorization, or email to the register to inquiry
> whether the applicant has been authorized to use the domain name.
> To verify the public IP, the subscriber can supply a sealed paper document
> or email from the ISP showing the IP is allocated by the ISP to the
> applicant.
>
> ** CPS section 3.2.2.4: Applications for EV SSL Certificates can only be
> submitted to CFCA. The subject must be the domain name of the web server,
> not the IP address. The domain name must not contain wildcards. The
> applicants can only be private organizations, business entities, government
> entities and non-commercial entities and should meet the following
> requirements: … [verification of identity, organization, and authority of
> the certificate subscriber]
>
> ** CPS section 3.2.2.4 part 6, Domain Name of the Applicant:
> (1) The Applicant is the registered holder of the domain name or has been
> granted the exclusive right to use the domain name by the registered holder
> of the domain name
> (2) Domain registration information in the WHOIS database SHOULD be public
> and SHOULD show the name, physical address, and administrative contact
> information for the organization.
> (3) The Applicant is aware of its registration or exclusive control of the
> domain name.
>
> * EV Policy OID: 2.16.156.112554.3
>
> * Root Cert: https://bugzilla.mozilla.org/attachment.cgi?id=8356494
>
> * Test Website: https://pub.cebnet.com.cn
>
> * OCSP
> http://ocsp.cfca.com.cn/ocsp/
> CPS 4.8.9: The maximum v

Second Discussion of CFCA Root Inclusion Request

[Kathleen Wilson]

China Financial Certification Authority (CFCA) has applied to include 
the “CFCA EV ROOT” root certificate, turn on the websites trust bit, and 
enable EV treatment.


The first discussion resulted in CA action items, which have been completed.
https://groups.google.com/d/msg/mozilla.dev.security.policy/2G6KuAT9Ekk/GyakphSLS5EJ
https://bugzilla.mozilla.org/show_bug.cgi?id=926029#c26

For your convenience, and because the request has been changed to be 
just for the EV root, I will re-summarize the request below.


CFCA is a national authority of security authentication approved by the 
People’s Bank of China and state information security administration. 
CFCA is a critical national infrastructure of financial information 
security and one of the first certification service suppliers granted a 
certification service license after the release of the Electronic 
Signature Law of the People’s Republic of China. There are more than 200 
Chinese banks that are using CFCA’s certificates to ensure the security 
of online banking trade.


The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=926029

And in the pending certificates list:
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/pending/

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8545426

Noteworthy points:

* The primary documents are the CPS and CP, which are provided in 
Chinese, and the CPS has been translated into English.


Document repository: http://www.cfca.com.cn/us/us-12.htm
CPS (Chinese) http://www.cfca.com.cn/file/qqfwq-cps.zip
CP (Chinese): http://www.cfca.com.cn/file/qqfwq-cp.zip

CPS (English): http://www.cfca.com.cn/file/CFCA-1403-CPS-en.rar

* CA Hierarchy: The “CFCA EV ROOT” root has one internally-operated 
subordinate CA, “CFCA EV OCA”, which issues EV SSL certificates.


* This request is to turn on the websites trust bit for the “CFCA EV 
ROOT” root certificate, and enable EV treatment.


** CPS section 3.2.2.3: Applications for SSL Certificates can only be 
submitted to CFCA, who accepts applications from both organizations and 
individuals.


** CPS section 3.2.2.3: CFCA verifies not only the ID, address, and 
country of the applicant, but also the IP and the compliance of CSR. The 
procedures are as follows:
CFCA performs a WHOIS inquiry on the internet for the domain name 
supplied by the applicant, to verify that the applicant is the entity to 
whom the domain name is registered. Where the WHOIS record indicates 
otherwise, CFCA will ask for a letter of authorization, or email to the 
register to inquiry whether the applicant has been authorized to use the 
domain name.
To verify the public IP, the subscriber can supply a sealed paper 
document or email from the ISP showing the IP is allocated by the ISP to 
the applicant.


** CPS section 3.2.2.4: Applications for EV SSL Certificates can only be 
submitted to CFCA. The subject must be the domain name of the web 
server, not the IP address. The domain name must not contain wildcards. 
The applicants can only be private organizations, business entities, 
government entities and non-commercial entities and should meet the 
following requirements: … [verification of identity, organization, and 
authority of the certificate subscriber]


** CPS section 3.2.2.4 part 6, Domain Name of the Applicant:
(1) The Applicant is the registered holder of the domain name or has 
been granted the exclusive right to use the domain name by the 
registered holder of the domain name
(2) Domain registration information in the WHOIS database SHOULD be 
public and SHOULD show the name, physical address, and administrative 
contact information for the organization.
(3) The Applicant is aware of its registration or exclusive control of 
the domain name.


* EV Policy OID: 2.16.156.112554.3

* Root Cert: https://bugzilla.mozilla.org/attachment.cgi?id=8356494

* Test Website: https://pub.cebnet.com.cn

* OCSP
http://ocsp.cfca.com.cn/ocsp/
CPS 4.8.9: The maximum validity period for OCSP response does not exceed 
7 days.


* Audit: Annual audits are performed by PricewaterhouseCoopers according 
to the WebTrust criteria.

WebTrust CA: https://cert.webtrust.org/SealFile?seal=1788&file=pdf
WebTrust EV: https://cert.webtrust.org/SealFile?seal=1786&file=pdf
WebTrust BR: https://cert.webtrust.org/SealFile?seal=1787&file=pdf

* Potentially Problematic Practices – None noted for this EV root and 
hierarchy.

(http://wiki.mozilla.org/CA:Problematic_Practices)

This begins the second discussion of the request from CFCA to include 
the “CFCA EV ROOT” root certificate, turn on the websites trust bit, and 
enable EV treatment. At the conclusion of this discussion I will provide 
a summary of issues noted and action items. If there are outstanding 
issues, then an additional discussion may be needed as follow-up. If 
there are no outstanding issues, then I will recommend approval of this 
request in the bug.

Re: CFCA Root Inclusion Request

[Kathleen Wilson]

On 9/2/14, 4:29 PM, Kathleen Wilson wrote:

I propose to close this discussion with the following action items:



I will take the lack of response to mean that everyone is OK with this 
proposal.
However, as mentioned in a different discussion thread, the wiki page 
has been updated. So I will update the PwC action item to remove the "if".

https://wiki.mozilla.org/CA:BaselineRequirements#Audit_Mistakes
==
When egregious mistakes were overlooked by the auditor, or there are a 
significant number of oversights, or the auditor did not notice BR 
compliance problems with the root or intermediate certificates, then the 
CA must resolve the issues and be re-audited. For the re-audit the CA 
can either get re-audited by a different auditor, or have the current 
auditor provide an immediate plan for correction and compliance, and 
then present a mid-term partial audit following that plan. In either 
case, the auditor must provide documentation about steps they are taking 
to avoid making the same mistakes in future audits. If the auditor fails 
to assure Mozilla that they have corrected the deficiencies in their 
auditing process, then their standing as a trusted auditor for the 
Mozilla root program may be jeopardized.

==


I am now closing this discussion regarding CFCA's root inclusion request.

The following action items will be tracked in the bug.

ACTION CFCA: State (in the bug) CFCA's plan for remediation of all of 
the issues noted in this discussion.


ACTION CFCA: Decide if CFCA will be re-audited by the same auditor, or 
by a different auditor. And get re-audited.


ACTION PwC: Provide a plan to improve PwC audits so that the oversights 
that were found during this discussion will not be missed in future PwC 
audits.


ACTION Kathleen: After the new audit statement has been received, start 
a second round of discussion for CFCA's root inclusion request.


Any further follow-up on this request should be added directly to the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=926029

Thanks,
Kathleen

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

Re: CFCA Root Inclusion Request

[Kathleen Wilson]

On 6/19/14, 4:20 PM, Kathleen Wilson wrote:

This begins the discussion of the request from CFCA to include the “CFCA
GT CA” and “CFCA EV ROOT” root certificates, turn on all three trust
bits for the “CFCA GT CA” root certificate, turn on the websites trust
bit for the “CFCA EV ROOT” root certificate, and enable EV treatment for
the ““CFCA EV ROOT” certificate. At the conclusion of this discussion I
will provide a summary of issues noted and action items. If there are
outstanding issues, then an additional discussion may be needed as
follow-up.



During the course of this discussion, this request was changed to only 
be for inclusion of the "CFCA EV Root" certificate, turn on all three 
trust bits, and enable EV for that root certificate.


In this timeframe we also created and discussed a new wiki page:
https://wiki.mozilla.org/CA:BaselineRequirements

Currently
https://wiki.mozilla.org/CA:BaselineRequirements#Audit_Mistakes
says: "When egregious mistakes were overlooked by the auditor or there 
are a significant number of oversights, then the CA must resolve the 
issues and be re-audited. For the re-audit the CA can either get 
re-audited by a different auditor, or have the current auditor provide 
an immediate plan for correction and compliance, and then present a 
mid-term partial audit following that plan. ..."



I propose to close this discussion with the following action items:

ACTION CFCA: state (in the bug) their plan for remediation of all of the 
issues noted in this discussion.


ACTION CFCA: Decide if they will be re-audited by the same auditor, or 
by a different auditor.


ACTION PwC: If CFCA's decision is to use the same auditor, then provide 
a plan to improve audits so that the oversights that were found during 
this discussion will not be missed in future audits.


ACTION Kathleen: After new audit statement has been received, start a 
second round of discussion for CFCA's root inclusion request.



Does that sound reasonable?

Kathleen








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

Re: CFCA Root Inclusion Request

[fhw843]

I agree with Ryan: new audit by new auditor. Since PWC did a mediocre job last 
time why would we expect a different result this time?

  Original Message  
From: Ryan Sleevi
Sent: Tuesday, August 5, 2014 5:41 PM
To: Kathleen Wilson
Reply To: ryan-mozdevsecpol...@sleevi.com
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CFCA Root Inclusion Request

On Tue, August 5, 2014 10:26 am, Kathleen Wilson wrote:
> On 7/29/14, 2:00 PM, Kathleen Wilson wrote:
> > All,
> >
> > Thank you to those of you who have reviewed and commented on this
> > inclusion request from CFCA. I will appreciate your opinions in response
> > to my questions below regarding how to move forward with this request.
> >
> > Note that the “CFCA GT CA” root was included in Microsoft’s program in
> > December 2012, and the “CFCA EV ROOT” root was included in Microsoft’s
> > program in May 2013.
> >
> >
> >>
> >> On a matter of process/procedure,
>
>
> So, shall we proceed with approval/inclusion of the "CFCA EV ROOT" cert
> after verifying that CFCA has addressed the issues noted in this
> discussion?
>
> Or, shall we require another audit before we proceed with
> approval/inclusion of the "CFCA EV ROOT" cert?
>
> Kathleen

Kathleen,

Given the compliance issues that were identified, and the number of them,
it's difficult to believe the auditor matches the criteria of "competent
party", pursuant to sections 12 - 16 of the Mozilla Inclusion Policy.

Per Section 16, it seems the burden is on the CA to establish the
competence of the third party.

This is somewhat distressing, since the auditor was
PricewaterhouseCoopers, whose only other WebTrust audits (per
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/included/
) is for the SECOM Roots. It's worth noting that the suitability of this
auditor has been discussed in the past (
https://groups.google.com/d/msg/mozilla.dev.security.policy/riLXu3ZJNso/HPOvC_5c0sUJ
), and that PricewaterhouseCoopers was also responsible for the Diginotar
Audit.

While it is ultimately the decision of Mozilla, per the inclusion policy,
as to whether the auditor meets criteria, the evidence and experience
gathered so far I believe casts a serious shadow.

Respectfully, and individually, I think the issues here are egregious
enough, and in sufficient number, to request a new audit by a new auditor,
pursuant with Mozilla's policies of requiring the CA to establish the
competence of the auditor.

___
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: CFCA Root Inclusion Request

[Ryan Sleevi]

On Tue, August 5, 2014 10:26 am, Kathleen Wilson wrote:
>  On 7/29/14, 2:00 PM, Kathleen Wilson wrote:
> > All,
> >
> > Thank you to those of you who have reviewed and commented on this
> > inclusion request from CFCA. I will appreciate your opinions in response
> > to my questions below regarding how to move forward with this request.
> >
> > Note that the “CFCA GT CA” root was included in Microsoft’s program in
> > December 2012, and the “CFCA EV ROOT” root was included in Microsoft’s
> > program in May 2013.
> >
> >
> >>
> >> On a matter of process/procedure,
>
>
>  So, shall we proceed with approval/inclusion of the "CFCA EV ROOT" cert
>  after verifying that CFCA has addressed the issues noted in this
>  discussion?
>
>  Or, shall we require another audit before we proceed with
>  approval/inclusion of the "CFCA EV ROOT" cert?
>
>  Kathleen

Kathleen,

Given the compliance issues that were identified, and the number of them,
it's difficult to believe the auditor matches the criteria of "competent
party", pursuant to sections 12 - 16 of the Mozilla Inclusion Policy.

Per Section 16, it seems the burden is on the CA to establish the
competence of the third party.

This is somewhat distressing, since the auditor was
PricewaterhouseCoopers, whose only other WebTrust audits (per
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/included/
) is for the SECOM Roots. It's worth noting that the suitability of this
auditor has been discussed in the past (
https://groups.google.com/d/msg/mozilla.dev.security.policy/riLXu3ZJNso/HPOvC_5c0sUJ
), and that PricewaterhouseCoopers was also responsible for the Diginotar
Audit.

While it is ultimately the decision of Mozilla, per the inclusion policy,
as to whether the auditor meets criteria, the evidence and experience
gathered so far I believe casts a serious shadow.

Respectfully, and individually, I think the issues here are egregious
enough, and in sufficient number, to request a new audit by a new auditor,
pursuant with Mozilla's policies of requiring the CA to establish the
competence of the auditor.

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

Re: CFCA Root Inclusion Request

[Kathleen Wilson]

On 7/29/14, 2:00 PM, Kathleen Wilson wrote:

All,

Thank you to those of you who have reviewed and commented on this
inclusion request from CFCA. I will appreciate your opinions in response
to my questions below regarding how to move forward with this request.

Note that the “CFCA GT CA” root was included in Microsoft’s program in
December 2012, and the “CFCA EV ROOT” root was included in Microsoft’s
program in May 2013.




On a matter of process/procedure,



So, shall we proceed with approval/inclusion of the "CFCA EV ROOT" cert 
after verifying that CFCA has addressed the issues noted in this discussion?


Or, shall we require another audit before we proceed with 
approval/inclusion of the "CFCA EV ROOT" cert?


Kathleen


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

Re: CFCA Root Inclusion Request

[Kathleen Wilson]

All,

Thank you to those of you who have reviewed and commented on this 
inclusion request from CFCA. I will appreciate your opinions in response 
to my questions below regarding how to move forward with this request.


Note that the “CFCA GT CA” root was included in Microsoft’s program in 
December 2012, and the “CFCA EV ROOT” root was included in Microsoft’s 
program in May 2013.





On a matter of process/procedure,

When these sorts of egregious failures are noted - failures to conform to
the required profiles or implement the specifications properly, what steps
are taken to ensure the program operates correctly going forward?


In the past it has depended on the number and seriousness of the 
problems that were found.


For a small number of not-too-serious problems we have checked that the 
CA corrected the problems, continued with inclusion, and then relied on 
the audit statements going forward.


For a large number of problems or serious problems, we have required the 
CA to fix the problems, get a new audit statement, and then go through a 
second public discussion phase, before continuing with inclusion.




For example, CFCA was audited by PricewaterhouseCoopers, on April 16,
2014, to WebTrust 1.1 (which is currently acceptable on
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
)

Certainly, this CA does not conform to Section 12 of the Inclusion Policy
(that is, it does not conform to BRs 1.1.5, which incorporates conformance
to RFC 3280/5280/X.509), so they should not be included.



Not to excuse these mistakes, but this CA isn't the only one having to 
update their systems to become compliant with the BRs.


See the dependency list in this bug regarding problems with BR-compliance:
https://bugzilla.mozilla.org/show_bug.cgi?id=1029147



It's clear
they're also in flagrant violation of Section 4, which specifically calls
out duplicate issuers/serials.



As we've seen in the past, this can lead to very serious problems.

CFCA's response to this is to withdraw their inclusion request for the 
“CFCA GT CA” cert, and only proceed with their inclusion request for the 
“CFCA EV ROOT” cert which did not have this problem.


According to CFCA their system does not allow this to happen anymore.



However, if they address the problems that Erwann has specifically
identified, does that reasonably give the community confidence that the
audit - which failed to identify these - is competent and qualified?

Is a
new audit required? If so, is the same auditor acceptable?



Given CFCA's response to the noted problems, do you think another audit 
is needed regarding the "CFCA EV ROOT" cert?


Do we need to have more discussion about this auditor, or does the 
information that was provided satisfy the concern?
Or, can we assume that this has been a good learning experience for both 
the CA and the auditor, and the CA can proceed with the same auditor?





Equally, as called out in the auditor's statement, no checks or procedures
were performed to determine the operating effectiveness of the controls,
for any period. Considering that a failure of controls led to TurkTrust
issuing improper certificates, and considering the findings found by
Erwann, it seems inappropriate to consider this CA for inclusion according
to Mozilla's policies (here, Section 17 of the Inclusion Policy)



There are 3 audit statements:
WebTrust CA: https://cert.webtrust.org/SealFile?seal=1606&file=pdf
WebTrust EV: https://cert.webtrust.org/SealFile?seal=1607&file=pdf
WebTrust BR-readiness: http://www.cfca.com.cn/file/PwC_CFCA(en).rar

I believe that this concern is regarding the BR-readiness audit.

https://wiki.mozilla.org/CA:CertificatePolicyV2.1
"Any Certificate Authority being considered for root inclusion after 
February 15, 2013 must comply with Version 2.1 or later of Mozilla's CA 
Certificate Policy. This includes having a Baseline Requirements audit 
performed if the websites trust bit is to be enabled. Note that the CA's 
first Baseline Requirements audit may be a Point in Time audit."


The reason we allow for the point-in-time audit is because CAs who are 
new to Mozilla's program may not have been aware of the BRs, so they may 
have been issuing certificates that were not fully compliant with the 
BRs. But the CA should resolve the non-compliances so that all 
certificate issuance going forward is in compliance with the BRs.


Given the issues that were identified and the CA's response to them, can 
we assume the issues have been resolved?
Or should we request another BR-audit, and require that the BR-audit 
cover a time period that will demonstrate the CA's compliance with the BRs?


Thanks,
Kathleen




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

Re: CFCA Root Inclusion Request

[cfcazhaogaixia]

This is our reply for GT system 

For GT: 

1, No SAN 
Status: 
No problem/Fixed
This problem is found and fixed in pre-audit stage, but the test certificate is 
an old one, now is been revoked.
As is mentioned in last reply, a Point in Time Pre-Issuance Readiness audit in 
this April. Since this is a point in time audit, the auditor only evaluated the 
design effectiveness. In the next audit, the operating effectiveness for a 
period will be evaluated. 

2, MIME type 
status： 
Fixed. 

3, OCSP signer certificate 
Status: 
Fixed. 
Using standards same as EV.

4, root key generation ceremony. 
Status: 
No problem. 
Same as EV.

5, CRL number field in crl downloaded from CRLDP 
Status: 
Fixed and updating

6, issue relate to oca2-SHA1 and oca2-SHA256 
Status: 
System down for update.

Leaders of CFCA take this matter very seriously and start an investigation:
1, Duplicate certificate is not allowed in CFCA's CA system, and the CA system 
running now cannot perform this operation.
2, It happened 2 years ago in a system update from SHA1 to SHA256.(SHA256 OCA2 
have only issued several test certificates, take down and upgrade this system 
will not affect end users)
3, After inner evaluation we decide to start a upgrade/rebuild for GT system, 
meanwhile revoke related certificates and stop issuing new certificates in GT 
system.
4, According to 3, GT system is not ready for this Inclusion request. I suggest 
that we process GT/EV system separately, and take GT system out of this wave of 
Inclusion request.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CFCA Root Inclusion Request

[cfcazhaogaixia]

Thank you all for your replies.

We tested and verified many problems mentioned by Erwann
In conclusion the problems mentioned by Erwann are:
1,No SAN in certificate
2,MIME type of AIA URI and CRLDP is test/plain
3,OCSP signer certificate's public key, valid period and extension.
4,root key generation ceremony.
5,Crl number field in crl downloaded from CRLDP
6,issue relate to oca2-SHA1 and oca2-SHA256 with same serial number.

Since we have two inclusion request (GT/EV), I'll explain separately.

For EV:

1, No SAN
Status:
No problem.
We checked our EV test website and other EV certificate (and the issuing 
model), EV subject certificate have SAN

2, MIME type
status：
Fixed.
The problem of MIME type is not within the CA issuing system (this means no 
problem with certificates' fields) but in the downloading server of AIA url and 
CRLDP.
This problem is fixed by now

3, OCSP signer certificate
Status:
Fixed.
The OCSP signing certificate issuing model is fixed by now, new ocsp signing 
certificate will have at least 2048 bits public key and valid period is set to 
1000 days(33month).
OCSP system for EV is updated and fixed by now.

4, root key generation ceremony.
Status:
No problem.
We discussed this issue with our auditor. Below is our reply:
Because our root was generated in August 2012 and we became aware of BRs in
2013 Dec, we did not require auditor to issue the audit report about root key 
generation.

Although the auditor did not issue an audit report about the root key 
generation, they actually observed the root key generation ceremony on site and 
performed all required audit procedures according to the Trust Service 
Principles and Criteria for CA v2.0 and WebTrust Audit Criteria and WebTrust EV 
Audit Criteria V1.4 which have same root key generation requirements with 
Webtrust BR Audit Criteria. No issue was identified. If the auditor cannot 
obtain reasonable assurance that all requirements are followed, it will not be 
possible to issue the unqualified WT opinions in 2012.

Following Mozilla's root certificate inclusion policy 
(https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy):

"Any Certificate Authority being considered for root inclusion after February 
15, 2013 must comply with Version 2.1 or later of Mozilla's CA Certificate 
Policy. This includes having a Baseline Requirements audit performed if the 
websites trust bit is to be enabled. Note that the CA's first Baseline 
Requirements audit may be a Point in Time audit. "

And it's our first BR audit, so the auditor performed a Point in Time 
Pre-Issuance Readiness audit in this April. Since this is a point in time 
audit, the auditor only evaluated the design effectiveness. In the next audit, 
the operating effectiveness for a period will be evaluated.

5, CRL number field in crl downloaded from CRLDP
Status:
Confirmed and fixing.
We discussed this issue with our auditor:

Our auditor performed the audit according to the Trust Service Principles and 
Criteria for CA v2.0 , SSL BR audit criteria V1.1 and WebTrust EV Audit 
Criteria V1.4. Except the SAN extension and root key generation requirements, 
other issues raised are not specified in these audit criteria, so they are not 
in the scope of audit. This is why the auditor did not find these issues.

Crl number field means "Section" in the old crl system of CFCA, for example the 
0~500 certificates have same crl number "1", which means they are in section 
one.
an update will take place soon in this system to ensure every detail comply to 
x509/RFC5280.

We will take measures to make sure similar problems won't happen again, and 
these features will not be missed in the future audit/report. We will provide 
details in next reply within this Public discussion.

6, issue relate to oca2-SHA1 and oca2-SHA256
Status:
No problem.
EV system has no problem relate to this issue.

For GT:
We are still investigating the issue relate to oca2-SHA1 and oca2-SHA256 with 
same serial number (How did it happen and what should we do).

We will include information relate to GT root in the next reply.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CFCA Root Inclusion Request

[Gervase Markham]

On 24/06/14 18:17, Ryan Sleevi wrote:
> On a matter of process/procedure,
> 
> When these sorts of egregious failures are noted - failures to conform to
> the required profiles or implement the specifications properly, what steps
> are taken to ensure the program operates correctly going forward?

This is an important question. Kathleen is not available for the next
few weeks, but let us make sure it does not fall off the radar by the
time she returns.

Gerv

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

Re: CFCA Root Inclusion Request

[cfcazhaogaixia]

I'm CFCA's representative Zhao GaiXia and this is the officially respond 
account(using google doc). 

Thanks for reviewing our request.

We will review and verify the points you mentioned and will reply soon.

Zhao Gaixia

Company Email:
gxz...@cfca.com.cn
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CFCA Root Inclusion Request

[Kurt Roeckx]

On Tue, Jun 24, 2014 at 10:55:14AM -0700, Ryan Sleevi wrote:
> On Tue, June 24, 2014 10:39 am, Kurt Roeckx wrote:
> >
> >  Should we mandate that the audit should also audit the procedures?
> >
> >  In my opinion the audit should:
> >  - Check that the CPS complies with all the requirements
> >  - Check that the CPS is being followed.
> 
> Well, "Check that the CPS is being followed" is a bit of a can of worms.
> 
> There's the sampling audit, that ensures, "historically", that the issued
> certificates have followed the CPS.
> 
> However, if an auditor does not also perform some observation that the CPS
> is being followed (e.g.: by having the CA demonstrate the various
> technical controls being followed), then a CA that has issued no
> certificates is, from an audit coverage perspective, indistinguishable
> from a CA with no technical controls.
> 
> So I think we need both - the sampling (historical) and some practical
> demonstration.

I was thinking about the practical demonstration, but I agree that
sampling of historical certificates is a useful thing to do.

I would also like that the audit report we get was more explicit
in what they did and possibly what problems they found.  I am
expecting that an audit finds problems.  I would find it unlikely
that a CA is perfect, and don't trust an audit that didn't find
any problems.


Kurt

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

RE: CFCA Root Inclusion Request

[Jeremy Rowley]

Right - under the BRs there is supposed to be a "Pre-Issuance Readiness
Audot" that confirms the CA's readiness to comply with the BRS.
Unfortunately, the pre-readiness audit is not well defined, but it should
include a practical demonstration that when issuance begins, the BRs will be
followed in all certs.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Ryan Sleevi
Sent: Tuesday, June 24, 2014 11:55 AM
To: Kurt Roeckx
Cc: Erwann Abalea; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CFCA Root Inclusion Request

On Tue, June 24, 2014 10:39 am, Kurt Roeckx wrote:
>
>  Should we mandate that the audit should also audit the procedures?
>
>  In my opinion the audit should:
>  - Check that the CPS complies with all the requirements
>  - Check that the CPS is being followed.

Well, "Check that the CPS is being followed" is a bit of a can of worms.

There's the sampling audit, that ensures, "historically", that the issued
certificates have followed the CPS.

However, if an auditor does not also perform some observation that the CPS
is being followed (e.g.: by having the CA demonstrate the various technical
controls being followed), then a CA that has issued no certificates is, from
an audit coverage perspective, indistinguishable from a CA with no technical
controls.

So I think we need both - the sampling (historical) and some practical
demonstration.

>
>  I would also like that the software they use should enforce as  much 
> as possible and not rely on humans to check things that can  be 
> automated.  That however does not mean it should only be  checked by 
> the software.
>
>  I would also like clear rules on what happens when we detect that  
> they do not follow the requirements.
>
>
>  Kurt
>

Agreed.

As it stands, I'm surprised that the controls in place that led to the
issues Erwann detected were sufficient to satisfy the requirements of
Sections 3.9 and 6.1 of the WebTrust "Principles and Criteria for
Certification Authorities 2.0", which is part of the basis of evaluating the
requirements of the "SSL Baseline Requirements Audit Criteria V1.1"

At a minimum, it seems like this CA should be moved to the back of the queue
for discussion, since it's clear that it's not yet in compliance with the
Mozilla 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: CFCA Root Inclusion Request

[Ryan Sleevi]

On Tue, June 24, 2014 10:39 am, Kurt Roeckx wrote:
>
>  Should we mandate that the audit should also audit the procedures?
>
>  In my opinion the audit should:
>  - Check that the CPS complies with all the requirements
>  - Check that the CPS is being followed.

Well, "Check that the CPS is being followed" is a bit of a can of worms.

There's the sampling audit, that ensures, "historically", that the issued
certificates have followed the CPS.

However, if an auditor does not also perform some observation that the CPS
is being followed (e.g.: by having the CA demonstrate the various
technical controls being followed), then a CA that has issued no
certificates is, from an audit coverage perspective, indistinguishable
from a CA with no technical controls.

So I think we need both - the sampling (historical) and some practical
demonstration.

>
>  I would also like that the software they use should enforce as
>  much as possible and not rely on humans to check things that can
>  be automated.  That however does not mean it should only be
>  checked by the software.
>
>  I would also like clear rules on what happens when we detect that
>  they do not follow the requirements.
>
>
>  Kurt
>

Agreed.

As it stands, I'm surprised that the controls in place that led to the
issues Erwann detected were sufficient to satisfy the requirements of
Sections 3.9 and 6.1 of the WebTrust "Principles and Criteria for
Certification Authorities 2.0", which is part of the basis of evaluating
the requirements of the "SSL Baseline Requirements Audit Criteria V1.1"

At a minimum, it seems like this CA should be moved to the back of the
queue for discussion, since it's clear that it's not yet in compliance
with the Mozilla policy.

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

Re: CFCA Root Inclusion Request

[Kurt Roeckx]

On Tue, Jun 24, 2014 at 10:17:17AM -0700, Ryan Sleevi wrote:
> 
> However, if they address the problems that Erwann has specifically
> identified, does that reasonably give the community confidence that the
> audit - which failed to identify these - is competent and qualified? Is a
> new audit required? If so, is the same auditor acceptable?
> 
> Equally, as called out in the auditor's statement, no checks or procedures
> were performed to determine the operating effectiveness of the controls,
> for any period. Considering that a failure of controls led to TurkTrust
> issuing improper certificates, and considering the findings found by
> Erwann, it seems inappropriate to consider this CA for inclusion according
> to Mozilla's policies (here, Section 17 of the Inclusion Policy)

Should we mandate that the audit should also audit the procedures?

In my opinion the audit should:
- Check that the CPS complies with all the requirements
- Check that the CPS is being followed.

I would also like that the software they use should enforce as
much as possible and not rely on humans to check things that can
be automated.  That however does not mean it should only be
checked by the software.

I would also like clear rules on what happens when we detect that
they do not follow the requirements.


Kurt

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

Re: CFCA Root Inclusion Request

[Ryan Sleevi]

On Tue, June 24, 2014 3:33 am, Erwann Abalea wrote:
>  Le vendredi 20 juin 2014 01:20:56 UTC+2, Kathleen Wilson a écrit :
> > China Financial Certification Authority (CFCA) has applied to include
> > the "CFCA GT CA" and "CFCA EV ROOT" root certificates, turn on all three
> > trust bits for the "CFCA GT CA" root certificate, turn on the websites
> > trust bit for the "CFCA EV ROOT" root certificate, and enable EV
> > treatment for the "CFCA EV ROOT" certificate.
>  [...]
>
>
>  Under "CFCA GT CA" root:
>
>  https://cs.cfca.com.cn/cgi-bin/
>  - subscriber certificate doesn't contain the mandatory SAN extension (CABF
>  BR section 9.2.1)
>  - MIME type of AIA:caIssuers URI is invalid ("text/plain")
>  - MIME type of CRLDP URI is invalid ("text/plain")
>  - CRL obtained by the CRLDP keeps the same CRLNumber value (1) while its
>  lastUpdate changes; this is forbidden by X.509/RFC5280
>
>  Duplicate issuer+serial number found for the issuing CA (CN=CFCA OCA2).
>  One certificate (sha256WithRSA-signed, expiration in 2032) is sent by the
>  test web server, the other (sha1WithRSA-signed, expiration in 2026) is
>  obtained by the AIA:caIssuer extension, both have the same information
>  including the serial number (0x29ad8db84e). This is forbidden by
>  X.509/RFC5280.
>  MIME type of CRLDP URI of this intermediate certificate is also invalid.
>
>  OCSP responder behind http://ocsp.cfca.com.cn/ocsp, when validating the
>  subscriber certificate, has a 1024 bits key and is valid for 5 years (and
>  a useless CRLDP extension).
>
>  OCSP responder behind http://ocsp.cfca.com.cn/ocsp, when validating the
>  intermediate certificate, has the same problems.
>
>  There's no trace of a report by a Qualified Auditor about the generation
>  of this root key (see CABF BR section 17.7), this is mandatory for keys
>  generated after 1 July 2012.
>
>
>  Under "CFCA EV ROOT" root:
>
>  https://pub.cebnet.com.cn
>  - subscriber certificate doesn't contain the mandatory SAN extension (CABF
>  BR section 9.2.1)
>  - MIME type of AIA:caIssuers URI is invalid ("text/plain")
>  - MIME type of CRLDP URI is invalid ("text/plain")
>  - CRL obtained by the CRLDP keeps the same CRLNumber value (1) while its
>  lastUpdate changes; this is forbidden by X.509/RFC5280
>
>  MIME type of CRLDP URI of the intermediate certificate is also invalid.
>
>  OCSP responder behind http://ocsp.cfca.com.cn/ocsp, when validating the
>  subscriber certificate, has a 1024 bits key for a 5 years validity (and a
>  useless CRLDP extension).
>
>  OCSP responder behind http://ocsp.cfca.com.cn/ocsp, when validating the
>  intermediate certificate, has the same problems.
>
>  There's no trace of a report by a Qualified Auditor about the generation
>  of this root key (see CABF BR section 17.7), this is mandatory for keys
>  generated after 1 July 2012.
>  ___
>  dev-security-policy mailing list
>  dev-security-policy@lists.mozilla.org
>  https://lists.mozilla.org/listinfo/dev-security-policy
>

On a matter of process/procedure,

When these sorts of egregious failures are noted - failures to conform to
the required profiles or implement the specifications properly, what steps
are taken to ensure the program operates correctly going forward?

For example, CFCA was audited by PricewaterhouseCoopers, on April 16,
2014, to WebTrust 1.1 (which is currently acceptable on
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
)

Certainly, this CA does not conform to Section 12 of the Inclusion Policy
(that is, it does not conform to BRs 1.1.5, which incorporates conformance
to RFC 3280/5280/X.509), so they should not be included. It's clear
they're also in flagrant violation of Section 4, which specifically calls
out duplicate issuers/serials.

However, if they address the problems that Erwann has specifically
identified, does that reasonably give the community confidence that the
audit - which failed to identify these - is competent and qualified? Is a
new audit required? If so, is the same auditor acceptable?

Equally, as called out in the auditor's statement, no checks or procedures
were performed to determine the operating effectiveness of the controls,
for any period. Considering that a failure of controls led to TurkTrust
issuing improper certificates, and considering the findings found by
Erwann, it seems inappropriate to consider this CA for inclusion according
to Mozilla's policies (here, Section 17 of the Inclusion Policy)

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

Re: CFCA Root Inclusion Request

[Erwann Abalea]

Le vendredi 20 juin 2014 01:20:56 UTC+2, Kathleen Wilson a écrit :
> China Financial Certification Authority (CFCA) has applied to include 
> the "CFCA GT CA" and "CFCA EV ROOT" root certificates, turn on all three 
> trust bits for the "CFCA GT CA" root certificate, turn on the websites 
> trust bit for the "CFCA EV ROOT" root certificate, and enable EV 
> treatment for the "CFCA EV ROOT" certificate.
[...]


Under "CFCA GT CA" root:

https://cs.cfca.com.cn/cgi-bin/ 
- subscriber certificate doesn't contain the mandatory SAN extension (CABF BR 
section 9.2.1)
- MIME type of AIA:caIssuers URI is invalid ("text/plain")
- MIME type of CRLDP URI is invalid ("text/plain")
- CRL obtained by the CRLDP keeps the same CRLNumber value (1) while its 
lastUpdate changes; this is forbidden by X.509/RFC5280

Duplicate issuer+serial number found for the issuing CA (CN=CFCA OCA2). One 
certificate (sha256WithRSA-signed, expiration in 2032) is sent by the test web 
server, the other (sha1WithRSA-signed, expiration in 2026) is obtained by the 
AIA:caIssuer extension, both have the same information including the serial 
number (0x29ad8db84e). This is forbidden by X.509/RFC5280.
MIME type of CRLDP URI of this intermediate certificate is also invalid.

OCSP responder behind http://ocsp.cfca.com.cn/ocsp, when validating the 
subscriber certificate, has a 1024 bits key and is valid for 5 years (and a 
useless CRLDP extension).

OCSP responder behind http://ocsp.cfca.com.cn/ocsp, when validating the 
intermediate certificate, has the same problems.

There's no trace of a report by a Qualified Auditor about the generation of 
this root key (see CABF BR section 17.7), this is mandatory for keys generated 
after 1 July 2012.


Under "CFCA EV ROOT" root:

https://pub.cebnet.com.cn
- subscriber certificate doesn't contain the mandatory SAN extension (CABF BR 
section 9.2.1)
- MIME type of AIA:caIssuers URI is invalid ("text/plain")
- MIME type of CRLDP URI is invalid ("text/plain")
- CRL obtained by the CRLDP keeps the same CRLNumber value (1) while its 
lastUpdate changes; this is forbidden by X.509/RFC5280

MIME type of CRLDP URI of the intermediate certificate is also invalid.

OCSP responder behind http://ocsp.cfca.com.cn/ocsp, when validating the 
subscriber certificate, has a 1024 bits key for a 5 years validity (and a 
useless CRLDP extension).

OCSP responder behind http://ocsp.cfca.com.cn/ocsp, when validating the 
intermediate certificate, has the same problems.

There's no trace of a report by a Qualified Auditor about the generation of 
this root key (see CABF BR section 17.7), this is mandatory for keys generated 
after 1 July 2012.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CFCA Root Inclusion Request

[Kathleen Wilson]

China Financial Certification Authority (CFCA) has applied to include 
the “CFCA GT CA” and “CFCA EV ROOT” root certificates, turn on all three 
trust bits for the “CFCA GT CA” root certificate, turn on the websites 
trust bit for the “CFCA EV ROOT” root certificate, and enable EV 
treatment for the ““CFCA EV ROOT” certificate.


CFCA is a national authority of security authentication approved by the 
People’s Bank of China and state information security administration. 
CFCA is a critical national infrastructure of financial information 
security and one of the first certification service suppliers granted a 
certification service license after the release of the Electronic 
Signature Law of the People’s Republic of China. There are more than 200 
Chinese banks that are using CFCA’s certificates to ensure the security 
of online banking trade.


The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=926029

And in the pending certificates list:
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/pending/

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8423345

Noteworthy points:

* The primary documents are the CPS and CP, which are provided in 
Chinese, and the CPS has been translated into English.


Document repository: http://www.cfca.com.cn/us/us-12.htm
CPS (Chinese) http://www.cfca.com.cn/file/qqfwq-cps.zip
CP (Chinese): http://www.cfca.com.cn/file/qqfwq-cp.zip

CPS (English): http://www.cfca.com.cn/file/CFCA-1403-CPS-en.rar

* CA Hierarchy: The “CFCA GT CA” root has two internally-operated 
subordinate CAs: The “CFCA OCA2” subCA issues SSL, Code Signing, Email, 
VPN, and Device certificates. The “CFCA GT OCA21” subCA issues 
pre-generated certificates, individual certificates, and organization 
certificates. The “CFCA EV ROOT” root has one internally-operated 
subordinate CA, “CFCA EV OCA”, which issues EV SSL certificates.


* This request is to turn on all three trust bits for the “CFCA GT CA” 
root certificate, turn on the websites trust bit for the “CFCA EV ROOT” 
root certificate, and enable EV treatment for the ““CFCA EV ROOT” 
certificate.


** CPS section 3.2.2.3: Applications for SSL Certificates can only be 
submitted to CFCA, who accepts applications from both organizations and 
individuals.


** CPS section 3.2.2.3: CFCA verifies not only the ID, address, and 
country of the applicant, but also the IP and the compliance of CSR. The 
procedures are as follows:
CFCA performs a WHOIS inquiry on the internet for the domain name 
supplied by the applicant, to verify that the applicant is the entity to 
whom the domain name is registered. Where the WHOIS record indicates 
otherwise, CFCA will ask for a letter of authorization, or email to the 
register to inquiry whether the applicant has been authorized to use the 
domain name.
To verify the public IP, the subscriber can supply a sealed paper 
document or email from the ISP showing the IP is allocated by the ISP to 
the applicant.


** CPS section 3.2.2.4: Applications for EV SSL Certificates can only be 
submitted to CFCA. The subject must be the domain name of the web 
server, not the IP address. The domain name must not contain wildcards. 
The applicants can only be private organizations, business entities, 
government entities and non-commercial entities and should meet the 
following requirements: … [verification of identity, organization, and 
authority of the certificate subscriber]


** CPS section 3.2.2.4 part 6, Domain Name of the Applicant:
(1) The Applicant is the registered holder of the domain name or has 
been granted the exclusive right to use the domain name by the 
registered holder of the domain name
(2) Domain registration information in the WHOIS database SHOULD be 
public and SHOULD show the name, physical address, and administrative 
contact information for the organization.
(3) The Applicant is aware of its registration or exclusive control of 
the domain name.


** CPS section 3.2.2.5: For Email Certificate, CFCA only issue 
certificates to domain name email that can be verified through WHOIS. 
CFCA verifies the validity of the email address and determines whether 
it’s legitimate through appropriate channels including but not limited 
to verification E-mails.


** CPS section 3.1.2: For Code-signing certificates, the DN must be the 
subscriber’s real name, and the CN can be the code name or name on the 
valid ID. CFCA would verify the ID provided.


** CPS section 3.2.2.5: For Code-signing certificates, CFCA would verify 
the code issuer’s identity, address, and country. … Standards of 
verification for identity are the same as listed in 3.2.2.1 and 3.2.2.2.


*** CPS section 3.2.2.1, Authentication of Individual Identity: The 
following materials should be submitted: 1. Certificate applicationForm; 
2. Copies of ID; 3. Authorization of the organization (applicable only 
to the individuals in organizations).
Th