Dear all, Still posting on behalf of TÜViT.
On Wed, Oct 31, 2018 at 11:43 AM Wiedenhorst, Matthias via dev-security-policy <[email protected]<mailto:[email protected]>> wrote: · Since January 2018, T-Systems issued EV certificates with an incorrect qcStatement. T-Systems was made aware of the problem in October 2018, i.e. for about 9 month the error was not detected/reported https://bugzilla.mozilla.org/show_bug.cgi?id=1498463#c3 T-Systems fixed the error in a timely manner so that certificates now contain the correct qcStatement. T-Systems identified a deficiency within their systems, made a change on October 5, but did not notify their CAB and SB until October 16. Under the requirements provided by EN 319 401, 7.9, that does not seem consistent with meeting those requirements. · TUVIT performed an audit of T-Systems according to ETSI policies EVCP and QCP-w in the beginning of 2018. During the audit the incorrect coding of the qcStatement was not detected. Yes. I believe this is a significant issue, given the assessment report. · In several emails, we answered to his complaint, explained our procedures and justified the classification of the encoding error as minor (non-critical) non-conformity. For non-critical non-conformities, our certification requirements foresee a maximum period of 3 month for remediation before the certification shall be withdrawn. (see also ETSI EN 319 403, section 7.6 b) Based on the classification as minor, we do not see a necessity for revocation. That’s about the relevant facts. Let me now reply in detail to Ryans private contribution: >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. Dr. Anja Wiedemann (please mind the correct spelling) was not part of the audit team. We do not understand why her name is mentioned here. One / three years exclusion from audit sounds like a punishment. We do not understand where this time frame comes from and why such a time frame is needed. Auditor and Reviewer, as stated on https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018072001_Audit_Attestation_E_Deutsche-Telekom-Root-CA-2_20180718_s.pdf - the parties tasked with ensuring that the audit is meaningfully able to ensure the criteria were met and the testing procedures were able to meet those requirements. Auditors and reviewers need to be distinguished: ISO/IEC 17065 §7.5.1 forbids that the person(s) performing the review is involved in the audit process. The time frame selected is one that has been consistently used in the past regarding questions about audits. Unfortunately, there lacks suitable means to objectively determine whether or not the auditor is sufficiently competent in remediation of problematic audits. Past procedures have resulted in indefinite suspensions for some auditors, or temporary suspensions of their recognition. The choice of three years, rather than one year, is based on the fact that we have now seen auditors who were not accredited perform audits against the frameworks, later become accredited, and retroactively issue reports covering their activities prior to accreditation. This does not instill confidence in the ETSI approach to auditor supervision, and thus the longer period is to ensure that no in-process audits are retroactively certified upon the expiration of the period. Three years thus aligns with both the 1 year (CA/B Forum) and 2 year (eIDAS) time periods in ensuring that such a possibility is not technically achievable. >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. TSPs are not accredited but certified, ETSI EN 319 403 §7.13 does not make any additional requirements on complaint procedures but just reference ISO/IEC 17065. (The requirements from ISO/IEC 17065 [1], clause 7.13 shall apply.) In particular, no procedures for complaints to TSPs or NABs are defined (only to CABs). 4.1.2.2 (j) provides for the client (the TSP) to inform the CAB any complaints made known to it. You're correct that procedures for complaints directly to the TSP are not normatively specified by ISO/IEC 17065 or that of EN 319 403; however, the countenance is made that a client (the TSP) may have knowledge of and records of complaints outside the scope and purview of the CAB's complaints. With respect to the NAB process, https://www.dakks.de/sites/default/files/71_sd_0_009_e_beschwerdeverfahren_20111118_v1.0_0.pdf and in the context of ISO/IEC 17011 https://www.dakks.de/en/content/dakks-successfully-evaluated-ea >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. We do not understand why the important fact that Matthias was not in office and replied what he remembered from an audit that was month ago is not mentioned here. In addition, he replied that he would verify and come back as soon as possible (when he is in office again). That actually happened, see below. Wrong or misleading information - which was only corrected upon specific questioning and a request for proof or evidence of the claim - has been used to disqualify CAs in the past. This statement was made after the TSP had themselves already investigated and confirmed this was not possible. The same standard being applied to CA incident reports is being proposed here - that incomplete and improper investigations raise serious questions. Let’s stay with present case (not with the past): In his email, Matthias said that he is not in his office and will begin to investigate the situation as soon as possible. We think that it is clear, that further information contained in the email cannot be based on the result of the investigation. Back in his office after looking into the audit logs and verifying the qcStatement he gave the proper answer. We do not agree at all that core competencies are missing. As you described, back in his office Matthias accessed the audit logs, did the manual check and found the wrong encoding. IT is obvious, that he has the competency to read ASN.1. In addition, it is not correct, that TUVIT does not use any tools for certificate checking but the currently available lint tools do not support the checking of the qcStatement. I disagree with this claim as to core competency - the problem had already been highlighted and identified by external members of the community. I also disagree that an acceptable response is that the tools did not support checking the qcStatement; it is expected that the auditor should be checking for conformity as part of their core competencies. To that extent, the extension of such tools to check was something the auditor could have performed. Alternatively, the auditor could have devised testing procedures to evaluate compliance against the specified module. At no point was the auditor prevented from examining nor absolved of the expectations simply because someone else had not written the tool for them yet. As said before, we are using tools in the audit process. The sentence about lint tools should be seen as additional information and nothing else. Considering the significance of misencoding of profiles - which has lead to critical misissuance and security risk (see, for example, Turktrust) - the question about whether or not TUVIT's testing procedures are adequate to ensure compliance are extremely relevant and appropriate. TUVIT could, for example, attempt to resolve these concerns by providing documentation about their approach to assessing compliance with the relevant certificate profiles, including methodologies for sampling (not normatively specified by the relevant documents), their testing and training procedures, and other evidence that would feel suitable to highlight that this was, indeed, a 'one off' approach. Let’s stay with the present case: We have not seen any security breach due to the miscoding of the qcStatement and have not seen any arguments how certificates with wrong qcStatement could be used to breach the security in future. That is the reason why believe the non-conformity is a non-critical non-conformity with respect to the performed assessment. In addition, a correct qcStatement is not required by the Baseline Requirements (but by ETSI EN 319 412-5). Having this in mind, we expect that Browser Ecosystem should not be directly affected. This is no different than the "Incident Reports" requested of CAs that fail to adhere to the requirements - understanding how 100% total and complete misissuance could be failed to be detected by the auditor IS a very real, and very pressing, question. It does not have the ease of explaining away via, say, statistical sampling issues, as this was 100%. It does not have the ease of explaining away as confusion, given that precise ASN.1 modules were given. It does not have the ease of explaining away as not significant, given this was a mandatory field with respects to the profile asserted. I reject the premise that this is 'minor' for exactly that reason, and there does not seem a reasonable explanation that has been offered, other than: 1) TUVIT's assessment methodologies are fundamentally flawed and do not meet the level of assurance expected of the community This is an exaggerated conclusion based on the only fact that a wrong coded qcStatement was not detected. 2) TUVIT's and T-Systems' incident handling approach does not meet the level of expectations of the community. This includes both the oversight of revocation, but also the approach to auditing for when such a critical non-conformity has been found. A resolution of "They promise to fix it" does not provide a reasonable level of assurance, given that at fundamental question is what other issues TUVIT failed to consider or assess. The lack of introspection, by TUVIT, as to its auditing process and procedures is concerning. How one single person (with his private hat on) can speak for the community? We explained before why we believe that the wrong qcStatement coding is a non-critical nonconformity (the security of ecosystems is not affected). Where did you copy "They promise to fix it" from? We have not used this expression. With respect to confidentiality and the disclosure of non-conformities, we've seen auditors make such disclosures - e.g. https://bug1425805.bmoattachments.org/attachment.cgi?id=9013271 Currently, there is no requirement for disclosing such kind of information. If there is no requirement, the confidentiality requirement from ISO/IEC 17065 is binding for us. As said before, we offer to support the establishment of rules with in the CAB/Forum for making such kind of incidents public in an adequate form. >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. Wrong again. Please have another look at 7.13.5, it talks about the <<decision>> to resolve the dispute and not of the process of resolving itself. The decision shall be made by an independent person. It is more than natural that for resolution process itself, concerned auditors needs to be involved. As I stated - the only information that has been provided has been by the Lead Auditor. Whether or not this complaint was formally resolved by TUVIT's management - which I intentionally CC'd in such messages - has not been forthcoming to date. As a consequence, the only way to determine objectively is to request an independent evaluation of the complaint resolution process to ensure that independence has been maintained. Why not asking TUVIT, if the complaint is formally resolved? We never said anything like that in our statements. Best regards Matthias Wiedenhorst ______________________________________________________________________________________________________________________ Sitz der Gesellschaft/Headquarter: TÜV Informationstechnik GmbH * Langemarckstr. 20 * 45141 Essen, Germany Registergericht/Register Court: Amtsgericht/Local Court Essen * HRB 11687 * USt.-IdNr./VAT No.: DE 176132277 * Steuer-Nr./Tax No.: 111/57062251 Geschäftsführung/Management Board: Dirk Kretzschmar TÜV NORD GROUP Expertise for your Success Please visit our website: www.tuv-nord.com<http://www.tuv-nord.com> Besuchen Sie unseren Internetauftritt: www.tuev-nord.de<http://www.tuev-nord.de> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
