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).
The investigators verify the completeness and authenticity of the
materials. Reliable data source would be used to validate the
applicant�s identity, address, country and etc.

*** CPS section 3.2.2.2, Authentication of Corporate (Organization)
Identity: First, CFCA designates a staff to receive the application
materials, and carry out initial examiniation of the completeness. This
is to ensure that the materials meet the demands for identity verification.
Second, CFCA designates an investigator to verify the application materials:
(1) Verify the organization identity, address, country and other
information through third party channels or the identity repository of
CFCA to ensure that the organization is an authentic existence.
(2) Verify the authorization through phone calls or official letters.


* EV Policy OID: 2.16.156.112554.3

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

* Test Websites:
https://cs.cfca.com.cn/cgi-bin/
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=1606&file=pdf
WebTrust EV: https://cert.webtrust.org/SealFile?seal=1607&file=pdf
WebTrust BR: http://www.cfca.com.cn/file/PwC_CFCA(en).rar

* Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices)

** Delegation of Domain / Email validation to third parties
CPS section 1.3.2: The RA function of the OCA2 and EV OCA system under
the CFCA Global Trust System is performed by CFCA internally. The RA
function of the OCA21 can be delegated to other organizations according
to relevant norms.
CPS section 1.4.1: The table shows that OCA21 cannot sign server (SSL)
or code-signing certs.

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. If there are no outstanding issues, then I will recommend
approval of this request in the bug.

Kathleen

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

[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

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@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)

[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

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

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

[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

[cfcazha...@gmail.com]

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

[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

[cfcazha...@gmail.com]

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.

[cfcazha...@gmail.com]

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.

[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

[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

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

[fhw...@gmail.com]

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-mozde...@sleevi.com
Cc: mozilla-dev-s...@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,
>
>

[Kathleen Wilson]

Let's please discuss the auditor questions a little more...

The auditor's statement (http://www.cfca.com.cn/file/PwC_CFCA(en).rar)
says that the auditor performed the procedures according to the
"WebTrust for Certification Authorities - SSL Baseline Requirements
Audit Criteria Version 1.1"
which is available here:
http://www.webtrust.org/homepage-documents/item72052.docx

If an auditor strictly performs the audit procedures required by
WebTrust SSL Baseline Requirements Audit Criteria v1.1 (link above),
would that auditor identify all of the issues raised by Erwann?

Thanks,
Kathleen

[Ryan Sleevi]

Principle 2, Item 2.1
"The CA maintains controls to provide reasonable assurance that
certificates issued meet the minimum requirements for Certificate Content
and profile as established in Section 9 of the Baseline Requirements"

The certificates identified by Erwann fail this test. They are
certificates that are key to the CA's infrastructure. These were and are
trivially identifiable, as Erwann showed.

The fact that such certificates were issued are proof that the controls
implemented do not provide said reasonable assurance.

Principle 2, Item 4.11
"The CA maintains controls to provide reasonable assurance that Root CA
Private Keys must not be used to sign Certificates except as permitted by
the Baseline Requirements."

The certificates signed violate this, ergo, the controls do not provide
reasonable assurance.

Principle 2, Item 6.2
"The CA maintains controls to provide reasonable assurance that:
the CA provides all personell performing information verification duties
with skills-training ...
the CA ... ensures that personel entrusted with Validation Specialist
duties maintain a skill level that enables them to perform such duties
satisfactorily
the CA requires all Validation Specialists to pass an examination provided
by the CA on the information verification requirements outlined in the
Baseline Requirements"

The response by the CA to Erwann's issues raises serious question about this.

I think the key tenet is whether or not the assertion, by
PricewaterhouseCoopers, that the CA "maintained effective controls to
provide reasonable assurance that the integrity of keys and certificates
it manages was established and protected throughout their life cycles" and
"CA systems development, maintenance and operations were properly
authorized and performed to maintain CA systems integrity", is
trustworthy.

The egregious evidence from Erwann, upon trivial inspection, seems to call
into question as to whether the assertion, by PricewaterhouseCoopers, as
to what constitutes "effective controls" and "reasonable assurance", is
trustworthy. Without this trust, the entire audit is invalidated.

Further, it calls into question as to whether PricewaterhouseCoopers
effectively "obtain(ed) an understanding of ABC Company's SSL certificate
life cycle management practices and procedures, including its relevant
controls over the issuance, renewal and revocation of SSL certificates".
(Appendix B, Example 1/3)

Note that Erwann identified issues were certificates or CRLs were issued
that failed, at a minimum, to conform to the policies set out in RFC 5280.

It is expected that a "competent party" (section 13, Mozilla Root
Inclusion policy" with "knowledge of CA-related technical issues such as
public key cryptography and related standards" would be capable of
determining that the controls implemented were ineffective/insufficient.

Given that Mozilla "reserves the right to designate your own
representative(s) to act as a competent independent party or parties
described above, should that prove to be necessary and appropriate"
(section 15, Mozilla Root Inclusion) and that Mozilla "reserve(s) the
right to not include a particular CA certificate in (our) software
products" for CA's that "issue certificates that have ... duplicate issuer
names and serial numbers" (Section 4, Mozilla Root Inclusion), it seems
appropriate and consistent action to either deny the inclusion request, or
to dictate an audit by an independent third-party.

The non-normative "how inclusion works" (
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion ) describes
issues identified as "things to update in the CP/CPS and possibly
operational practices" - except what we have is a violation of the CP/CPS
(and of the Mozilla requirements)

Thus, it does not seem appropriate to treat this as an "item to fix" to be
sent to Phase 2, but a reason to deny inclusion.

[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

[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