On Wed, Oct 31, 2018 at 11:43 AM Wiedenhorst, Matthias via dev-security-policy <[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. 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. > 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. 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. 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 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. 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 >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. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
