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
