(Writing with an individual hat) I would like to suggest that consideration be given to rejecting future audits from TUVIT and from that of Matthias Wiedenhorst and Dr. Anja Widermann, for some period of time. I would suggest this period be at least one year long; however, given the technical details of ETSI accreditation, believe a period of three years may be more appropriate.
As part of an investigation into the incorrect qcStatements reported at https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/x3s3CSKdIlY , I've used this as an example to explore the complaint handling process under ETSI EN 319 403. For those not familiar with the process, ETSI EN 319 403 normatively incorporates various portions of ISO/IEC 17065, which is an international standard for Conformity Assessment Bodies. Under the eIDAS scheme, auditors (henceforth called Conformity Assessment Bodies, or CAB) are assessed by their National Accreditation Body, or NAB, as being accredited under EN 319 403 to conduct audits against the schemes in ETSI EN 319 411-1 and ETSI EN 319 411-2. When a CA (called a Trust Service Provider, or TSP, by eIDAS) has been audited (accredited) by a CAB against the scheme in EN 319 411-1 or 411-2, the CAB is applying the principles in EN 319 403. If there is a belief that a TSP has failed to meet the requirements of their accreditation, EN 319 403 describes a process for which complaints may be made to either the TSP or to the CAB. This complaint process is further expanded upon in ISO/IEC 17065, which 319 403 incorporates. This same process also applies when there have been mistakes by the CAB to adhere to its scheme requirements under EN 319 403 - a complaint may be made with either the CAB or the NAB regarding the CAB's accreditation. Each CAB and NAB must make available their information for processing complaints. Given that 100% of the qualified certificates issued by T-Systems have failed to comply with the requirements of ETSI EN 319 411-2, by virtue of failing to comply with ETSI EN 319 412-5, I lodged a complaint regarding T-System's certification with TUVIT, which certified T-Systems. As part of processing the complaint, the following issues regarding TUVIT's handling of complaints and overall approach to audits were revealed. Issue A) As part of their initial response to my complaint, TUVIT, by way of Matthias Wiedenhorst (Head of Certification Division TSP) stated "As a very first, quick cross check with our audit evidence record, I can only say that we did check issued certificates from within the declared period and that they did contain the proper qcStatement-6.3 / id-etsi-qcs-QcType 3". However, this statement was in direct conflict with the TSP's own investigation and incident report, provided at https://bugzilla.mozilla.org/show_bug.cgi?id=1498463#c3 , which states the mistake was introduced during the development of support - that is, no such properly issued certificates were issued. In follow-up with TUVIT, I requested they provide any evidence to support the claim that such certificates were issued, knowing the matter reported by T-Systems means this is highly improbable. In subsequent reply, Matthias Wiedenhorst acknowledged that their methodology for testing compliance with ETSI EN 319 412-5 stated that the process was "the auditors have to check the website certificates manually for the presence of the QC-statement. In this case, the existence of the id-etsi-qct-web was identified, but for any reason it was not realized that the esi4-qcStatements-6 was missing. We informed the auditors about how to check the QC-statement correctly so that we are confident, that in future an incorrect coding will be detected. " This implies a significant lack of core competencies within TUVIT to assess against the criteria of ETSI EN 319 412-5, which provides a normative ASN.1 module within its specification. Issue C) In regards to remedies, I requested a suspension of T-Systems current ETSI EN 319 411-2 accreditation, and a subsequent assessment of a Full audit, given concerns with respect to the audit team performing the initial audit. TUVIT declined this, on the basis that they assess such technical non-compliance to be a 'minor non-conformity' that, per ETSI EN 319 403, may be resolved in the next three months by T-Systems without adversely affecting their accreditation. Further, T-Systems and TUVIT decided that, on the basis that it is a non-conformity, such certificates do not need to be revoked according to the Baseline Requirements' timeline. Furthermore, the failure to revoke according to the Baseline Requirements' timeline was a further minor non-conformity, not adversely affecting the certification decision of T-Systems, and may be remedied over the next 3 months. Furthermore, in response to whether or not such matters of non-conformities would be reported by TUVIT (the CAB), Matthis Wiedenhorst acknowledged that they are not required to make such information public at this time. I believe this significantly undermines the level of confidence and assurance that relying parties should place in audits conducted by TUVIT. The inducement to non-compliant actions, combined with the non-disclosure of these "non-conformities" to affected parties, is at odds with the principles and values of the respective Root Programs' goals. In addition to these concerns with respect to the audits provided, I will be further lodging a complaint with the German National Accreditation Body, Deutsche Akkreditierungsstelle GmbH, regarding TUVIT's accreditation under EN 319 403 to asses TSPs against EN 319 411-1 and EN 319 411-2. The handling of this incident, the material misstatement as to what was examined, combined with the failure to ensure appropriate and prompt notification to the CAB and the Supervisory Body (as detailed in https://bugzilla.mozilla.org/show_bug.cgi?id=1498463#c3 ) call into serious question the compliance with Regulation (EU) N°910/2014 on behalf of both T-Systems and TUVIT. In particular, the failure to perform a timely notification under Article 19(2) of the "loss of integrity that has a significant impact on the trust service provider" represents a significant breach of trust. With respect to what constitutes a "loss of integrity", both Article 8 and Article 7(f) note compliance to the appropriate technical standards and the prohibition of any "specific disproportionate technical requirements on relying parties ..." that would "significantly impede the interoperability of the notified electronic identification schemes". Through their failure to assure a timely disclosure, and the failure to revoke, TUVIT's certifications disproportionately and adversely affect Relying Parties. Such certificates assert that they are qualified certificates, and thus Relying Parties should be able to rely upon them for their constitutive value. However, in the absence of the appropriate and mandatory notice as to the qualified purpose of such certificates, as this incident demonstrates, Relying Parties are left without an interoperable means of determining whether or not such Qualified Certificates are indeed qualified, and thus subject to the protections afforded by eIDAS. Furthermore, the complaint process established under EN 319 403 refers to that of ISO/IEC 17065:2012. Under ISO/IEC 17065:2012, the requirement is put forward within 7.13.5 and 7.13.6 that the complaint resolution process be independent from those from those involved in the audit or those who have consulted with or been employed by the subject of the audit. Matthias Wiedenhorst's involvement in, and resolution of, this complaint, calls into question whether TUVIT has acted according to this, given that they are represented as Lead Auditor for T-Systems' audit. At this point, the only objective means of resolving whether or not the process was followed is to lodge a complaint such that the NAB may themselves investigate the handling of this complaint. Given that the Supervisory Body and National Accreditation bodies exist to protect the legal value of this scheme, the failure by TUVIT to uphold the safety and security of the eIDAS regime represents an ongoing threat to the ecosystem. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
