On Wed, August 6, 2014 11:48 am, Kathleen Wilson wrote: > 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
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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
