Hi Ryan, hi all, three things to comment on that: 1. How is the EU ETSI audit scheme thought and what is it intended to provide to Mozilla and the CA/Browser ecosystem? The European scheme of technical standards for CA/TSP developed by ETSI was made and is constantly adopted to integrate CA/Browser requirements. The main standards I am referring to are: ETSI EN 319 401, EN 319 411-1 and EN 319 411-2. With regard to auditor guidance specifically for the CA/Browser ecosystem, ETSI even developed and maintains the TS 119 403-2 “Part 2: Additional requirements for Conformity Assessment Bodies auditing Trust Service Providers that issue Publicly-Trusted Certificates”. For auditors using such technical standards Europe has established a well thought through scheme based upon organizations (accredited audit bodies) which job it is – amongst others – to ensure auditors (the natural person) qualification, independence, etc. This scheme turned out to be of high trustworthiness, reliability, robustness, etc. And it works very well over here since years.
2. Transparency The transparency lies in the European scheme with independent skilled bodies auditing each other in order to ensure conformant implementation of technical standards as well as of operational requirements for audit bodies as well as for the single auditor (natural person). Not only the requirements for the qualification/independence/etc. of the auditor (natural person) are clearly defined within the ISO/ETSI but also the management requirements of the body in order to ensure that they are kept upright – btw. BSI C5 controls, section 4.4.9 is meant similar to that. Every accredited body is audited at least once a year by its NAB which checks conformant audit processing (e.g. according to ISO/IEC17065 in combination with ETSI EN 319 403). Now, requesting more of transparency with regard to auditor qualification for Mozilla insinuates this immediately translates into more confidence in the auditor. Please lets be careful here. If we like the community to follow that, shouldn’t be clearly stated: - which documents/evidences are expected from the auditor to be handed in to Mozilla, - what criteria (details need to be published) shall Mozilla use to check the documents/evidences against, - a statement of how Mozilla comes to the conclusion: auditor is acceptable / not acceptable, - how Mozilla shall organize themselves to perform this task (skilled staff members are required), - how that can get organized in a way that it is compatible to CA projects (see Tim Hollebeeks mail), and finally: what information is expected from Mozilla to be published for every single auditor (natural person) to show auditors qualification and make it transparent. The tasks related to auditor qualification validation and management actually are performed by the participants in the European scheme already (and apart from that, not very different also in the WebTrust world). 3. Requiring all their externally-operated subordinate CAs review their auditors You said: quote <<< That sounds like a great idea, and sounds like a good compliment to an approach that several (Root) CAs have taken, of requiring all their externally-operated subordinate CAs review their auditors and audit scope with the root CAO, before finalizing the audit engagement. An example of how the public review has been done in the past is available at https://groups.google.com/g/mozilla.dev.security.policy/c/sRJOPiePUvI/m/oRmRffaQmcYJ >>> If we like to suggest that, wouldn’t we then not also need to state at least 1st based upon what rule-set we like the CA to review auditors, 2nd what competences are required at CA level to validate auditors and how those shall be established and maintained, 3rd how the CA is required to do that with regard to process and timing? In order to be clear and transparent, things like these would need to be defined at CA level then. Best regards Clemens _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
