On 13/11/2018 04:08, Ryan Sleevi wrote: > Jakob, > In the following, I have added a new subject category:
Subject U: [T-Systems local] Issues at T-Systems, rather than issues in TUVIT's auditing of T-Systems. I will use the following number: U1: T-Systems misencoded the qc-statement extension required by the EU scheme, but not present in X.509, BR nor WebPKI except for the general requirement not to misencode anything. (Subject T is TUVIT's auditing of issue U1). > Please see > https://groups.google.com/d/msg/mozilla.dev.security.policy/Q9whve-HJfM/lpwKQXOfAgAJ > , which was already provided previously. > It includes details regarding T-Systems areas of non-compliance that were > 1) Demonstrably not identified by the auditor > 2) Covered by existing audit criteria > 3) Sharing the similar root cause as this incident > So your additional complaints are: O1 TUVIT did not list the issues from bug #1391074 (see below) in the audit reports for 2017, and maybe didn't discover them, neither by management assertion, nor by TUVIT searching Mozilla systems for mention of T-Systems issues, nor by the various concrete audit steps (such as sampling). T2 You believe TUVIT should have done extra checks based on their knowledge (if any!) of the issues in bug #1391074, and that those extra checks might have increased the chance of TUVIT discovering issue U1. T3 You believe that there is a common root cause at T-Systems for the issues in bug #1391074 and issue U1. The one commonality I could dig out is that in bug #1391074 something in the PKI system (not the templates apparently), had incorrect ASN.1 definitions of two standard X.509 objects, while in the qc-statements bug, something in the system (not sure what), had an incorrect ASN.1 definition of an object not in any part of X.509, PKIX or the BRs . The message you linked above (Which seems to be message id <mailman.103.1541172329.1183.dev-security-pol...@lists.mozilla.org>) is a random point in your ongoing debate, and seems to be full of arguments rather than a clear, classified enumeration of issues. It does not state clearly, except by a nameless numerical link to a past bug, what previous incidents are being considered. I have tried to summarize that bug below. The referenced bug #1391074 seems to mention the following issues at T-Systems (U1 is the qc-statements encoding issue itself, not its auditing): U2. A failure by T-Systems (not TUVIT) to respond within 24 hours to an issue described only by another link to a discussion, specifically: https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/w2AMK81jAQAJ Unfortunately, the bug log did not capture what the problem reporting addresses in CCADB were at the time, or which of those was used. U3. One or two cases of T-Systems (not TUVIT) issuing certificates with syntactically invalid dnsNames described only by two other such links: https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ and https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ U4. Some instances of T-Systems (not TUVIT) issuing certificates with minor syntax errors in the distinguished name (described, confusingly, as metadata-only field values), again detailed only in the form of a discussion link: https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ According to later replies in the bug discussion, this was apparently a case of some kind of nonsense (such as empty string) in the OU field, and some cases of empty ST field. U5. Some instances of T-Systems (not TUVIT) issuing certificates with double dots (a clear syntax error) in dnsNames, described by a discussion link and a list of certificates: https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ online certificate list https://misissued.com/batch/13/ U6. A list of cablint results not clearly classified as to their relationships with prior mentions in the bug log. U7. 3 instances, found by T-Systems themselves of T-Systems (not TUVIT) issuing certificates with "Key Encipherment" enabled for ECDSA keys due to bugs and configuration errors. U8. 1 instance, found by T-Systems themselves of T-Systems (not TUVIT) issuing a certificate with no SAN extension. U9. 10 instances, found by T-Systems themselves of T-Systems (not TUVIT) issuing certificates with IP addresses in the dnsName SAN fields instead of the IP-address SAN fields (a clear violation). This was apparently deliberate but with no attempt to obtain a dispensation from the BRs and Mozilla policy. U10. 4 instances, found by T-Systems themselves of T-Systems (not TUVIT) issuing certificates with non-existant country codes. This is clearly a mis-issuance, as it gives an untrue identity of the certificate holder. U11. 1 instance, found by T-Systems themselves of T-Systems (not TUVIT) issuing a certificate with an O field but neither L nor ST field. A clear BR violation. U12. Inadequate answers by T-Systems (not TUVIT) about root causes and preventative measures. S2. Discussion between Mozilla and T-Systems (not TUVIT) about how to handle conflicts between a legally mandatory privacy law at the time and a wish for full certificate details to be published. > Even if we accept a notion that an auditor would not have been looking for > those issues at that time (despite the clear auditable criteria that > existed), the examination of root cause reveals a common pattern shared > with this incident, You have not stated what you think that common pattern is. Is it general sloppiness? Is it ASN.1 encoding errors? > and a pattern where the auditor would have been > responsible for the review of the changes as part of the certification> > scheme. What changes specifically? What part of the certification scheme specifically? > T-Systems has still not provided a satisfactory response to the > questions raised by Gerv and Wayne in response to the past incident ( > https://bugzilla.mozilla.org/show_bug.cgi?id=1391074 ), which, while Do you mean T-Systems has not provided a sufficiently detailed root cause analysis of the issues in bug#1391074? Do you mean T-Systems has not provided a clear statement of specific corrections for the root causes of the issues in bug#1391074 ? > separable from the concerns of TUVIT, should have factored into any such > considerations - such as Gerv's prescient expectation of exactly this issue > in https://bugzilla.mozilla.org/show_bug.cgi?id=1391074#c22 > Comment 22 in Bug #1391074 merely asks for more information, including clear statements of measures to prevent similar errors in the future. It also mentions bad templates as an example. Comment 28 answers most (not all) of comment #22, although briefly. In particular it explains that the one issues that caused Gerv to ask about templates was not a bad template, but a software bug that used a different template than the one configured. Thus if issue U1 was in a template, it would likely not have been caught by measures based on the identified root causes of the issues in bug#1391074. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
