I suppose I had unreasonably hoped it would be self-evident, particularly for someone who claims to follow the issues, to understand how directly that issue was related. Unfortunately, whether for intent or otherwise, it appears not.
While I do not believe nor agree with your approach to framing the issues, I do hope you can agree that both through the bug - which itself is an amalgamation of and reference to several bugs - that during the prior two audit cycles, T-Systems contained a substantial amount of misissuance that were undetected by TUVIT and that shared the same root cause: misconfiguration and misapplication of the relevant rules, both in terms of ASN.1 and in terms of normative requirement. If you are attempting to excuse such misissuance, rather than address it, one would take a similar tact as you are here; suggesting, for example, that it was T-Systems rather than TUVIT that did the misissuance or by suggesting that the incidence was low to be insignificant. I was careful not to try to muddy the conversation through an indictment on T-Systems, to avoid diluting the conversation, and because they’ve already provided several enumerations of the issues and that doing so again, as you’ve done, does not add value. However, it should be readily apparent from both the bug discussion and the list of issues a common pattern of misconfiguring relevant profiles and failing to ensure they comply with the relevant requirements. In the context of ETSI, each of these configuration changes - particularly once qualified - undergoes some review; whether after the fact (pre-qualification) or prior to such change. Similarly, misissuance involves a degree of notification to the CAB. As such, it is entirely reasonable to expect a degree of supervision, as that is the value of the certification scheme. All of this information would have been available at the time of configuring qualified certificates, including the pattern of issues existing when configuring profiles and templates. As such, we functionally see two issues; the inadequate supervision that resulted in the first batch of misissuance, which can be attempted to be argued away by suggesting it was some small volume that sampling would not have caught (despite the inconsistencies of that argument with the criteria), and inadequate supervision leading to this current issue, despite having all of that previous information available as context during the review and despite their being 100% misissuance rate. Both of these share a clear commonality of inadequate supervision, a key role played over the past several years. Audits understandably and obviously do not prevent a CA from making a change tomorrow that undermines the past audits; there is no guarantee they won’t start actively misissuing once the auditor has left the building. It is, however, meant to provide assurance regarding the present (and past) configuration. When a CA like T-Systems does misissue, whether this or previous incidents, it is entirely reasonable to ask “Was this configuration something the auditor previously reviewed, and did they catch it?” and, in the case of ETSI, “was this a change the auditor approved in relation to ongoing certification?” The qcStatements demonstrates a failure of the latter, the bug demonstrates a failure of the former, both speak to the process of review and the qualifications of the reviewer. If you don’t agree with the large swath of undetected past misissuance being a concern, it would be helpful if you could explain why it isn’t concerning. For example, do you believe that these requirements (collectively, for any of these issues) were not covered by existing criteria? Do you believe that sufficient documentation of TUVIT’s methodology exists so as to explain why such failure to detect may be seen as reasonable? Do you believe that ETSI does not require consideration by auditors prior to operational and configuration changes? In short, do you disagree that, when presented with CA misissuance, such as by T-Systems, that it is both relevant and appropriate to question why the auditor failed to detect and/or prevent such misissuance? I am not arguing that an audit be a guarantee against misissuance; for example, a statistical sample will be just that, a sample, and stuff can reasonably slip through. I am, however, advocating that it’s both appropriate and necessary to question whether sampling was even done, and how it was constructed (e.g. CA selects the samples and sizes vs auditor), and what was reviewed, in order to ascertain whether or not it was “reasonable” to have missed something. In the case of T-Systems past misissuances, the collective sum - especially with respect to things like misconfigured templates - raises legitimate concerns about TUVITs approach and methodology, and those concerns are each themselves distinct issues with TUVIT for every misissuance “type” by T-Systems. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
