On Tue, Oct 31, 2017 at 5:21 AM Dimitris Zacharopoulos via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> > It is not the first time this issue is brought up. While I have a very > firm opinion that ETSI auditors under the ISO 17065 (focused on the > quality of products/services) and ETSI EN 319 403 definitely check > historical data to assess the level of conformance, I will communicate > this to our auditor and ask if they would like to provide more specific > feedback. > > During the CA/Browser Forum F2F 41 in Berlin, it was stated that TUV-IT > (CAB and chair in ACAB-c), was in discussions with Root Programs to > determine an "ETSI audit report template" that would include all > critical information that Root programs would like to be included in the > public (or browser) audit letter/report. Minutes > (https://cabforum.org/2017/06/21/2017-06-21-f2f-minutes-meeting-41-berlin/ > ) > > --- BEGIN QUOTE --- > > Clemens Wanko from TÜVIT/ACABc – “Update: Addressing Browser Audit > Requirements under eIDAS/ETSI” > > Clemens said that there were several discussions with the Browsers that > resulted in an audit report template that would meet the Browser’s > expectations. > > Dimitris asked if this template could be posted on the public mailing list. > > --- END QUOTE --- > > Until today, such a template has not been published or circulated either > in the CA/Browser Forum or the m.d.s.p. I hope this discussion will push > for this template to be published. Do you believe that the requirements stated in the policy are unclear? That is, as Kathleen mentioned, the Mozilla policy states all the information that must be present, as a template of what needs to be there. Perhaps this is just confusion as to expecting, say, Mozilla to provide a PDF of a cover sheet? I believe the issue being raised here is more of an audit report issue > and not of audit criteria. Auditors under the ETSI audit scheme, just as > with the Webtrust scheme, in order for the audit to be "effective", must > obtain evidence of actions that took place in the past. How far back, > should be determined by the audit criteria and requirements. For > example, the Baseline Requirements and Root programs require a full > audit to occur once a year which means auditors must collect evidence > from "at least" one year. Auditors may examine evidence even further > back if they consider that this is required in order for them to get a > better understanding of CA operations for their assessment. I don’t believe this is an accurate representation. You are correct that historical evidence must be examined, but none of the aforementioned audit criteria establish that a year must be examined. The BRs state annual certification, but this is both irrelevant (the audits are to 319 411, not the BRs) and misleading (you can be annually certified without examining annual performance). Perhaps you can highlight where the requirement is to opine on the past year of activities. As you know, 319 411-1 is itself insufficient in this regard, as it expects (full) audits every other year - a problem that has occurred with a number of auditors performing surveillance audits rather than full audits. The 17065 scheme is used to assess products like food. You can't make an > effective assessment in such a critical area by just looking at the > "current status" without looking at historical data. In the ETSI/ISO > audit schemes, CABs are supervised and audited by National Accreditation > Bodies (NABs), at least annually which provides some extra level of > assurance that the audits conducted by CABs are examined by an > independent party. NABs also have the right to witness audits conducted > by CABs. That’s great, but the independence is unrelated. As to your remarks about 17065, note that no one has said that some historic data is not evaluated - Phase 1 and Phase 2 make it clear there’s both document review and historic evaluation - but there is no requirement to consider the fullness of activities over a year. Similarly, if a TSP was derelict in its duties for 6 months, took 3 months to fix, and then compliant for 3 months, they absolutely could be given a clean certification - because they’re currently compliant. Can you highlight where, specifically in the requirements and norms, this scenario is forbidden? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
