Thanks for focussing the discussion on the substance and thus allowing the community moving towards a common understanding and towards defining adequate requirements for treating such kind of incidents. We are very much interested in improving the existing requirements as we have done in the past by participating actively in drafting of ETSI standards, including EN 319 403.
I am particularly disturbed by three points made by TUVIT during this discussion: 1. A malformed qcStatement extension is a minor non-conformity because there is no known security risk - This argument is incredibly dangerous and harmful. It implies that all sorts of well-defined requirements can be ignored if the CA and/or auditor decide that there is no risk in doing so. We agree that neither CAs nor Auditors may ignore a failure against well-defined requirements independent of their classification as critical or non-critical. This is already currently not the case as both are non-conformities. CAs and auditors have to address every non-conformity and cannot ignore them. The classification (just) refers to the timeframe for remediation. Every major non-conformity has to be remediated before ETSI certification is possible. In case of existing certificates, the certificate is withdrawn. With minor non-conformities, an auditor may issue an ETSI certificate under the condition that every minor non-conformity is remediated within timeframe of 3 month (maximum) after conclusion of the audit. Existing certificates may stay valid but must be withdrawn if the CA fails to remediate within the deadline. 2. Citing ISO 17065 as requiring non-conformities be kept confidential - adding on Ryan's comments, we're seeing increasing disclosure of audit findings (another example: https://netlock.hu/download/etsi-certification-netlock/?wpdmdl=57340), leading me to believe that this is TUVIT's own interpretation of the confidentiality requirements. I don't believe that TUVIT needs "the establishment of rules with in the CAB/Forum for making such kind of incidents public" in order to begin making these disclosures. Section 4.5 of ISO/IEC 17065 states that in general all non-public information shall be regarded as confidential. However, that section also allows that CAB and TSP can agree between each other about information not to be regarded as confidential. Our interpretation (which we think is aligned with current interpretation of general data protection legislation informally stated as “everything which is not explicitly required/allowed is forbidden”), indeed follows a minimum principle. So you are right, with consent of the TSP it is possible and we are willing to request such consent in future. We suggest the establishment of general rules / requirements valid for all auditors instead of individual / different commitments. These rules could be on the content of public audit reports and on the roles of audits during security incidents including reporting and should allow browsers and the interested community to obtain the necessary information to get a good picture on the incident and the assessment of the auditor. 3. The argument that T-Systems has 3-months to revoke these certificates - while I understand that under ETSI TSPs have 3 months to correct minor non-conformities, using that as an excuse to ignore CAB Forum revocation requirements is unacceptable, and perhaps explains why we see such poor compliance with this requirement. If this is indeed the accepted interpretation (please confirm), then I will look for ways to fix this via Mozilla policy. - Wayne >From the ETSI certification point of view, this is the interpretation. Failure >to revoke within the required timeframe is clearly a non-conformity. >Nevertheless, if the non-conformity has been rated as minor non-conformity >(due to the individual circumstances), there would be a period of 3 month >before the corresponding ETSI certification would be withdrawn. However, we do see your concern and it is a very reasonable one. Using this construct to deliberately delay revocation is not at all desired. How could we deal with it? One possibility would be for the CAB to mandatorily require the TSP to publish the failure to adhere to the certificate revocation timeline requirement as bug in the Bugzilla (as already required from the TSP by Mozilla Policy) before the rating as minor non-conformity is possible. Without publication, it has to be rated as major non-conformity and hence an existing ETSI certificate will be withdrawn. This would facilitate the interest of transparency and would allow Mozilla, if regarded necessary, to take further action regardless of a still existing ETSI certificate. In the past, the ETSI certificate was not regarded as the primary audit deliverable by root store operators; this is the audit attestation letter. Combined with number 2 above, in such the case the next audit attestation letter would also state the failed revocation deadline as non-conformity. Best regards Matthias ______________________________________________________________________________________________________________________ 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
