On 06/11/2017 17:05, m.wiedenho...@tuvit.de 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
(This is my interpretation, I don't have authority on this):
The biggest issue (in this thread at least), is that a number of "public
audit reports" (the portion of an audit that are signed by the auditor
and published by the audited CA/TSP) lack the following 3 pieces of
basic information:
1. The specific date of the previous audit (the start of the period
covered by a period-in-time audit), thus making it impossible for
readers of such reports to determine if they did not receive or
otherwise missed a period-in-time audit covering a previous period
(the requirements for the Mozilla root program allow, and in rare
cases require, period-in-time audits more frequently than 1/year).
2. A simple statement that this is a period-in-time audit covering the
period from the stated date (see #1) to the "audit date" and not a
point-in-time audit for the "audit date" only.
3. For audits referring to the older ETSI audit regime (not the current
regime it appears), a statement that the audit was an actual full
audit with period-in-time checking etc. and not a reaffirmation of one
of the weaker schemes permitted by those old rules (forwarding
looking, notification based, not actually checked every year etc.)
Possibly the following are also missing from some audits:
4. A list of the audited CA certificates, stated in full or as hashes.
5. Compliance with any CAB/F BRs introduced after ETSI took its snapshot
of the CAB/F BRs.
6. Compliance with any additional Mozilla requirements for TLS server
("WebPKI") certificates above and beyond the CAB/F BRs. Mozilla need
not be mentioned as long as each item is somehow described as being in
the required way and audited as such.
7. Compliance with the various BR-like requirements for e-mail
certificates as currently listed in the Mozilla policy. Mozilla need
not be mentioned as long as each item is somehow described as being in
the required way and audited as such. Some of these may, for example,
already be audited ETSI requirements under a referenced ETSI standard.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
