On Mon, July 28, 2014 6:39 am, Wallas Smith wrote: > [Please note that it has been the second time that I am trying to send > this mail to the mozilla.dev.security.policy mailing list. I didn't > noticed it appearing in the mailing list the first time, I guess it > failed, I hope it will work this time. Thank you for your understanding.] >
Hi Wallas, I suspect you may have missed some basic research into this problem, based on the questions. I suspect that if you read https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/ , you will find many of your questions and the technical details about what is (and is not) required already answered. This is the sum of the set of requirements imposed, so if it's not there, it's not a requirement. > Hello, > > As explained in the checklist > > (https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices), > one of the 3 following audit is required when asking for CA inclusion : > > * ETSI TS 101 456 > * ETSI TS 102 042 > * WebTrust Principles and Criteria for Certification Authorities > > I therefore have some questions regarding these audits. > > 1) I would like to know the precise criteria that Mozilla took into > account when > initially choosing these 3 audits. How did Mozilla chose them, on which > points > did the auditors fit with Mozilla requirements ? Prior to the CA/Browser Forum's publication of the Baseline Requirements, ETSI TS 101 456 and WebTrust for CAs both effectively provide the same set of common audit criteria regarding best practices for CAs. After the publication, these Baseline Requirements (which Mozilla is a participant in developing, through its involvement in the CA/Browser Forum) have been rolled into ETSI TS 102 042 and WebTrust for CAs (v2.0). That is, the Baseline Requirements set forth the practices, but they are not audit criteria. These are then turned into an auditable set of controls by AICPA and ETSI, which result in the publication of the two audit criteria. > 2) Which auditors are allowed to deliver the audit for Mozilla (is there a > list) and how were they chosen ? See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ points 12 - 16 Note that it incorporates the Baseline Requirements Section 17.6 set of Auditor Requirements. There is not an explicit list. An auditor that meets this requirements is, according to Mozilla's policy, a reasonable auditor. You can see exactly who the auditors are for all of the included certs at https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/included/ > > 3) Is there a contract with the auditor(s) in case Mozilla criteria are > not respected ? What sanctions can be taken (did it happened before) ? > Who, by Mozilla side, check the auditors actions and sayings (in case > there is anyone, if it not just an assurance contract), and what is the > checking process if it is public ? If you read Mozilla's policy, you will see at no point does Mozilla impose a requirement that CAs are audited to *their* requirements. Without providing a set of audit criteria that an auditor can then apply, this is not something that auditors will engage in. Instead, Mozilla requires that the CA be audited according to one of the three audit frameworks, which derive their audit requirements from the Baseline Requirements (and for which both AICPA and ETSI have representatives within the CA/Browser Forum ensuring that the audit criteria are consistent with the Forum's publications). It is then incumbent upon the CA to ensure the fulfillment of additional requirements imposed by Mozilla. The way this generally takes place is that the CA is expected to note within the CP/CPS how they follow Mozilla's criteria, which is then expanded upon in the inclusion bug. The auditor measures compliance with the CP/CPS, where applicable. There is no contract with the auditors. There have been no sanctions towards auditors (to this date). The auditors are bound by professional code of conduct and various governmental regulations regarding the authenticity of their audit. If an auditor "cooks the books", as it were, it's the same as any other form of audit malfeasance. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
