TÜViT as a conformity assessment body would like to add some explanations to clear up some misunderstandings about ETSI auditing. First of all, we would like to give one preliminary remark. ETSI has separated the TSP technical requirements (ETSI EN 319 411-1, ETSI EN 319 401) from the CAB auditing requirements (ETSI EN 319 403). This is an ISO international standardization best practice (principle 1 of ISO / IEC 17007) not to mix technical requirements (“what to audit”) with auditing requirements (“how to perform such audits”).
Given that, the main issue of this thread seems to be the question about the point-in-time vs. period-of-time audit approach. Of course, every properly conducted audit has to include and examine the point-in-time situation at the time of the current audit. But beyond that, every properly conducted audit must cover the operations performed since the last audit. The latter is defined by ETSI EN 319 403. In its section 7.9 it deals with surveillance and re-assessment. It has already been agreed upon without objections (during the CABF F2F Bilbao meeting, if we remember correctly) that only annual full system audits are eligible in the context of CABF BR and/or EVG. As a consequence, every audit (aside from the very first initial audit => point-in-time / pre-issuance readiness assessment) must be performed as re-assessment and the relaxations for surveillance audits introduced in this section do not apply in the BR / EVG context. In its last sentence this section declares, that auditors must cover a sample of records on the operations performed since the previous audit. It is our firm opinion, shared by our national accreditation body, that this defines an audit period ranging from the date of the last audit up to the date of the current audit and that the complete period needs to be examined, not only certain bits and pieces of it. However, if the current phrase is causing problems, we are absolutely willing to approach ETSI in order to request an explicit clarification of this in a future version of the standard. As you correctly pointed out, the ETSI EN 319 403 in section 7.10 includes a notification scheme, where the CA’s are required to notify changes affecting the certification to the conformity assessment body. But as stated above, this is not a replacement for the backward-looking period-of-time audit approach. It is a supplement in order to perform auditing of security-relevant changes (and identify changes that would be non-conformant!) in a timely manner and not only at the next annual full audit. Summarizing this, a properly conducted ETSI audit includes both point-in-time and period-of-time (and the latter both backward- as well as forward-). Another issue obviously is the proper format of a publicly facing audit report / audit attestation to be presented to the root programs. With this we are totally on your side, an acceptable report / attestation must clearly state the required facts in order to enable to deal with it. These reports are not and cannot be completely defined in the ETSI EN 319 403 standard, as different use cases (“consumers”) might require different sets of information. However, in our opinion the CABF and browser root programs give sufficient information about the required contents. We are willing to readopt the idea of creating a mandatory template for such audit attestation. This idea had been in the field since some CABF F2F-Meetings but obviously has never been finalized. Root programs could then simply decline all attestations that do not conform to the template. We are open to further discussions, e.g. at the next CA-Day (https://www.tuvit.de/en/news/events/events-detail/details/9-ca-day-2017/) or at any upcoming CABF F2F meeting. Best regards Matthias Wiedenhorst, TÜViT _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
