Dear Peter,
I am deeply in ETSI process, so I can give info some info: Formerly the ETSIs are based on * 102042 for CAs * 101456 for CAs issuing qualified certificates (refernces frequently the 102042) o BRG and EV is referenced from them for SSL and EV SSL certificate issuance. The new version of these : (2016-02) (these are based on the 910/2014/EC regulation, which makes a common EU market.) * 319411-1 for CAs * 319412-2 for CAs issuing qualified certificates (refernces frequently the 319411-1) o 319401 is referenced from them for technical requirements (technical requirements from 102042 and 101456 were ripped of into this documents) o 319412-1 ,-2, -3, -4, -5 referenced from them for certificate profiles o BRG and EV is referenced from them for SSL and EV SSL certificate issuance. For EU CAs the Microsoft forces to move to ETSI audit instead Webtrust. The ETSI audit checks: * that the certificate issuance systems and environment are compliant with the technical or requirements. (against 319401) * that the certificate profiles meet the requirements (against 319412s) * the CP/CPS and the practice of issuance compliant with the 319411-1 (and for qualified certificates with 319411-2) o the 319411-1 and 319411-2 defines various Certification policies, and rules for them. LCP, NCP, NCP+, DVCP, IVCP, OVCP, EVCP, and also the new qualified ones (qcp-n, qpc-l, qcp-n-qscd, qcp-l-qscd, qcp-w) For DVCP, OVCP, IVCP, OVCP they references BRG and EVGL (and also for qcp-w, which looks like a chimera for me :) ) At the end of audit each issuing subcas are checked against the compliance with issuing policies, profiles, and technical requirements. Of-course the ETSI report, or its Annex also includes the whole list of the subordinates too. Also the Microsoft doesn't accepts audit report without the subordinate list, so its mandatory nowadays. I think what is important to add the 319411-1 and -2 to the actual acceptable audit requirements, because the MS ask for this, and it older version (119411 included in the 2.3 proposal) At october I would like to upload our new audit reports to Salesforce, which are made aganst the 319411-s. üdvözlettel //sincerelly yours, Viktor Varga Netlock chief architect -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+varga.viktor=netlock...@lists.mozilla.org] On Behalf Of Peter Bowen Sent: Friday, September 23, 2016 12:57 AM To: [email protected] <[email protected]> Subject: Audit requirements Kathleen, Gerv, Richard and m.d.s.p, In reviewing the WebTrust audit documentation submitted by various CA program members and organizations wishing to be members, it seems there is possibly some confusion on what is required by Mozilla. I suspect this might also span to ETSI audit documentation, but I don't know the ETSI process as well, so will leave it to some else to determine if there is confusion there. The first part of the confusion comes from the scope of the audit. When engaging an auditor to provide attestion services, it is up to the organization to define the scope of the audit. For audits utilizing the WebTrust criteria, the scope could be all parts of the criteria. According to auditors I have spoken with, the report will indicate which portions of the criteria were in scope for the audit by including a statement of items in scope on the management assertion. If the assertion does not include an item, or the auditor does not express an opinion about the item, then it should be assumed to be out of scope. I have seen a number of reports that do not include all of the criteria be in scope. Specifically, many reports do not provide an opinion on criteria 7 ("Subordinate CA Certificate Life Cycle Management") of the Trust Services and Principles and Criteria for Certification Authorities. Given the emphasis on subordinate CAs in the Mozilla policy, it would seem that this should be required for any CA which does not the zero path length constraint. The current inclusion policy item 11 presumably includes this already, but does not specifically state that all parts of the listed criteria must be included. The second item of confusion seems to be which CA certificate subjects must be audited. A number of CAs only include the subjects of CA certificates directly included in the Mozilla products and do not include the subjects of subordinate CA certificates. My impression is that there should be a report clearly covering each of subject of a unconstrained CA certificate in the heirarchy, as described in item 8 of the inclusion policy. This includes a Baseline Requirements report for any unconstrained CA, even if the CA is not intended to be used for server authentication ("SSL") certificates. What is Mozilla's expectation? Do CAs need to ensure that all components of the criteria are included in their report and ensure that all unconstrained subordinates are identified as being covered by the reports? Thanks, Peter _______________________________________________ dev-security-policy mailing list [email protected]<mailto:[email protected]> https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
