Thank you for clarification.
Do you think the terms "/approval scheme/", "/supervision scheme/",
"/accreditation//scheme/" etc. (used in some ETSI TSs or the Commission
Decisions) have the same meaning and ETSI EN 319 403 is just one of
possible "/certification scheme/s"?
Thanks,
M.D.
On 11/6/2017 6:05 PM, m.wiedenhorst--- via dev-security-policy wrote:
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
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
