Situation from ACAB'c ETSI auditors point of view: On one hand it is quite simple: if the auditor cannot perform the audit as foreseen in the certification program no certificate can be issued. In case a surveillance audit cannot be performed, the certification body must withdraw the affected certificate.
On the other hand the situation is complex because the reason for not performing the audit is neither the fault of the CA neither the fault of the auditor but due to a force majeure. In this case, the questions to ask comprise: 1. What is the reason for having the audit? 2. What is the reason to perform the audit now? 3. Can the audit be postponed? 4. Would it help to perform the audit in a reduced scope? In the present case the reason for having the audit and having it at a certain time comes from rules defined by the consumer of the audit attestations/certificates, i. e. the browsers. In this case browsers should think about answers to questions 3 and 4 and considering the possibility of adapting the rules for the case of force majeure. This happens in public life, too. According to the law, kids must go to school (at least in Germany). But today, some (but not all) schools are closed because of the virus. So the rules were changed. Hence, it is hard to define a universal rule valid for all CAs (schools). The following focuses on the possibilities in case of travel restrictions. Details might be different for other cases like natural disasters. One possible scenario could be that the Auditors of the accredited CAB are under restriction: Such a case would mainly be addressed by business continuity provisions of the conformity assessment body (CAB), considering e.g. the following questions: - What is the duration until return to normal operation? Can the audit still be performed in time after the restrictions have been lifted? - How is the auditing personnel distributed? With personnel in different locations, maybe not all auditors are affected at the same time. - Can the CAB subcontract non-affected external auditors? - If the CAB does not have sufficient options, can another ACAB’c member CAB jump in? In any case will the accredited CAB take care of the requirement conformant treatment of the travel restricted situation based upon its quality controlled ruleset following ISO/IEC 17065 in conjunction with ETSI EN 319403. The other possible scenario would be that the TSP or a TSP location is under restriction: A general rule is, that the scope of the assessment (including “in terms of facilities”) must be clearly defined (ETSI EN 319 403, 7.4.1.0) and that the complete scope must be audited to perform an ETSI certification. Another general rule is that, depending on some pre-conditions, a sample-based approach could be possible for TSPs using multiple sites. (ETSI EN 319 403, 7.4.3) In some cases, it might be possible to choose a sample that does not include locations under restriction. However, as the CABF requires full audits, this does not apply in this context. If facilities can’t be audited by auditors of the CAB in person, possible alternatives are more or less identical to those stated for Webtrust - “Network-assisted auditing techniques” are possible (ETSI EN 319 403, 7.4.1.2) - CAB may subcontract auditors that do not fall under the restriction, if they fulfil the auditor requirements. The CAB always remains fully responsible for such outsourced activities. (ISO/IEC 17065, 6.2.2 ). If such alternatives were accepted by the CAB to provide reasonable assurance with regard to the requirements to be audited, this would result in a normal audit conclusion and would not be visible on an audit attestation letter. If none of the two alternatives is possible, a general rule is, that everything which can be audited will be audited - there is especially no restriction to do a full Stage 1 document audit. If facilities cannot be audited by auditors of the CAB in person and the alternatives stated above are not possible or the CAB does not regard them to provide reasonable assurance with regard to the requirements to be audited in order to draw a reasonable audit conclusion this shall be documented in the audit report. An audit attestation letter shall be issued stating which parts have not been covered by the audit. How to deal with the situation, after travel restrictions have been lifted? From the viewpoint of an ETSI certification, no ETSI certificate has been issued: - It is possible to re-use the original audit results and perform an additional audit just with regard to the non audited requirements (ISO/IEC 17065, 7.4). Usually, the period during which this is possible is limited by the CAB (ACAB’c: 6 month). Once the original audit becomes too old, a completely new audit would be necessary. From the viewpoint of an Audit Attestation Letter (AAL) under ETSI, either an updated version of the original audit attestation letter or a completely new audit attestation letter shall be issued based on the additional audit activities described before. We are afraid in all cases this might result in deviations from the Mozilla requirements on audit letters: - An updated version / new letter for the original period would most likely be dated more than 3 month after the end of the audit period. - An updated version / new letter with an extend period would most likely result in a period of more than 12 month. Please note: An extend period would only be possible, if a new full audit has been performed (covering the time of the original period plus the extension till the last day of the audit), because the original audit of course can’t cover a time period after that audit. As far as we know, there is no general restriction on how far back in time the audited period may start. But it should be obvious that for some kind of evidences the information value might decrease over time or that it might become more and more complicated to determine a certain state of a certain thing at the certain time. Matthias & Clemens _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
