Re: Questions regarding the qualifications and competency of TUVIT
In addition, I take exception to the statement that open criticism is a bad approach and the implication that private discussions are the best way to make improvements. This is clearly not Mozilla's philosophy. I do believe that we all need to be careful to follow Mozilla forum etiquette [1] and community participation guidelines [2], particularly the section titled "Be Direct but Professional". However, transparent discussions are a core Mozilla Principle [3]: "Transparent community-based processes promote participation, accountability and trust." I look forward to more open and constructive discussions aimed at improving the quality and transparency of CA audits, regardless of the audit scheme. - Wayne [1] https://www.mozilla.org/en-US/about/forums/etiquette/ [2] https://www.mozilla.org/en-US/about/governance/policies/participation/ [3] https://www.mozilla.org/en-US/about/manifesto/ On Mon, Nov 5, 2018 at 1:55 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, Nov 5, 2018 at 3:28 PM Nick Pope via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > It is very unfortunate that at this time the owners of root store > programs > > openly criticise one of the main auditors working on improvements to > > European based audits. After a number of years of audits of European CAs > > based on ETSI EN 319 403 being recognised as meeting the requirements of > > publicly trusted certificates, ETSI is working and with European auditors > > on further updates to improve the acceptability of European audits to > root > > store programs. It seems to be going against this initiative to suggest > > draconian measures of excluding TUVIT audit from the root programs whose > > impact are totally out of proportion the possible impact of the issues > > raised. > > > > I suggest that the providers of root stores to return to the negotiations > > for further improving European based audits that I understood had started > > at the recent CA/Browser forum. The current approach of making public > > criticisms against those who are trying to make improvements to the > > European CA audits is making the current direct discussions with root > store > > providers difficult to progress. So unless it is the objective to > > deliberately exclude European CAs from their root programs, which I > believe > > is not the case, I suggest that we return to the direct discussions with > > the providers of root store on how to further improve European audits so > > that can better take into account the root program requirements. > > > > Nick Pope, Vice-Chair ETSI TC on Electronic Signatures and [Trust] > > Infrastructures > > > > Respectfully, comments like this unfortunately bring even greater concern > with respect to the ETSI process. > > A significant number of improvements have been made to the ecosystem by > recognizing when mistakes are made and taking steps to improve. It has now > seen both TUVIT and the Vice-Chair of the ETSI TC on ESI instead suggest > these are not mistakes and downplay their significance. This prevents > meaningful improvements, because it fails to recognize that there exist > fundamental issues. > > I am all in favor of ensuring that all accepted audit schemes meet the > necessary level of robustness for the community. Much work has been done > with WebTrust, through their active engagement with Browsers to ensure that > the needs of the consumers are being met. ETSI has only recently begun to > recognize these issues, and while we are indeed seeing the beginnings of > fruitful engagement, we should not suggest that such seeds are a reasonable > justification to ignore gross negligence in security-critical functions OR > the deeply concerning dismissiveness of those concerns. > > I'm sure you can understand it would be deeply offensive if, on the basis > of such collaborations with WebTrust, it be suggested that no WebTrust > auditor be disqualified. Similarly, I'm sure you can understand it would be > deeply offensive to the purpose, values, and goals to suggest that because > CAs participate in m.d.s.p., they should be excluded from accountability. > At the end of the day, browsers are accountable to ensuring their users are > secure, and regardless of how productive our conversations may be, if the > level of security is not met, it's entirely appropriate and necessary to > take steps to protect users. > > I hope that, as Vice-Chair of the ETSI TC on ESI, and on behalf of > auditors, careful introspection is performed in comparing how these > statements sound when compared with CAs that have been distrusted due to > gross negligence and misissuance. Failures to acknowledge or recognize the > problem, failures to have implemented reasonable steps to resolve such > issues, repeated failures to achieve the necessary level of security, do > more to harm the brand of that organization and its products than > statements suggesting
Re: Questions regarding the qualifications and competency of TUVIT
On Mon, Nov 5, 2018 at 3:28 PM Nick Pope via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > It is very unfortunate that at this time the owners of root store programs > openly criticise one of the main auditors working on improvements to > European based audits. After a number of years of audits of European CAs > based on ETSI EN 319 403 being recognised as meeting the requirements of > publicly trusted certificates, ETSI is working and with European auditors > on further updates to improve the acceptability of European audits to root > store programs. It seems to be going against this initiative to suggest > draconian measures of excluding TUVIT audit from the root programs whose > impact are totally out of proportion the possible impact of the issues > raised. > > I suggest that the providers of root stores to return to the negotiations > for further improving European based audits that I understood had started > at the recent CA/Browser forum. The current approach of making public > criticisms against those who are trying to make improvements to the > European CA audits is making the current direct discussions with root store > providers difficult to progress. So unless it is the objective to > deliberately exclude European CAs from their root programs, which I believe > is not the case, I suggest that we return to the direct discussions with > the providers of root store on how to further improve European audits so > that can better take into account the root program requirements. > > Nick Pope, Vice-Chair ETSI TC on Electronic Signatures and [Trust] > Infrastructures > Respectfully, comments like this unfortunately bring even greater concern with respect to the ETSI process. A significant number of improvements have been made to the ecosystem by recognizing when mistakes are made and taking steps to improve. It has now seen both TUVIT and the Vice-Chair of the ETSI TC on ESI instead suggest these are not mistakes and downplay their significance. This prevents meaningful improvements, because it fails to recognize that there exist fundamental issues. I am all in favor of ensuring that all accepted audit schemes meet the necessary level of robustness for the community. Much work has been done with WebTrust, through their active engagement with Browsers to ensure that the needs of the consumers are being met. ETSI has only recently begun to recognize these issues, and while we are indeed seeing the beginnings of fruitful engagement, we should not suggest that such seeds are a reasonable justification to ignore gross negligence in security-critical functions OR the deeply concerning dismissiveness of those concerns. I'm sure you can understand it would be deeply offensive if, on the basis of such collaborations with WebTrust, it be suggested that no WebTrust auditor be disqualified. Similarly, I'm sure you can understand it would be deeply offensive to the purpose, values, and goals to suggest that because CAs participate in m.d.s.p., they should be excluded from accountability. At the end of the day, browsers are accountable to ensuring their users are secure, and regardless of how productive our conversations may be, if the level of security is not met, it's entirely appropriate and necessary to take steps to protect users. I hope that, as Vice-Chair of the ETSI TC on ESI, and on behalf of auditors, careful introspection is performed in comparing how these statements sound when compared with CAs that have been distrusted due to gross negligence and misissuance. Failures to acknowledge or recognize the problem, failures to have implemented reasonable steps to resolve such issues, repeated failures to achieve the necessary level of security, do more to harm the brand of that organization and its products than statements suggesting distrust. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Questions regarding the qualifications and competency of TUVIT
It is very unfortunate that at this time the owners of root store programs openly criticise one of the main auditors working on improvements to European based audits. After a number of years of audits of European CAs based on ETSI EN 319 403 being recognised as meeting the requirements of publicly trusted certificates, ETSI is working and with European auditors on further updates to improve the acceptability of European audits to root store programs. It seems to be going against this initiative to suggest draconian measures of excluding TUVIT audit from the root programs whose impact are totally out of proportion the possible impact of the issues raised. I suggest that the providers of root stores to return to the negotiations for further improving European based audits that I understood had started at the recent CA/Browser forum. The current approach of making public criticisms against those who are trying to make improvements to the European CA audits is making the current direct discussions with root store providers difficult to progress. So unless it is the objective to deliberately exclude European CAs from their root programs, which I believe is not the case, I suggest that we return to the direct discussions with the providers of root store on how to further improve European audits so that can better take into account the root program requirements. Nick Pope, Vice-Chair ETSI TC on Electronic Signatures and [Trust] Infrastructures On Friday, November 2, 2018 at 9:00:16 PM UTC, Wayne Thayer wrote: > 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. > > 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. > > 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 > > On Fri, Nov 2, 2018 at 8:25 AM Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Fri, Nov 2, 2018 at 10:24 AM Wiedenhorst, Matthias via > > dev-security-policy wrote: > > > > > 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. > > > > > > > Indeed - and yet do you agree that the Reviewer is tasked with reviewing > > the audit methodology and artifacts to ensure it appropriately meets the > > objectives expected and required? A multi-party failure to assure the > > necessary assurance is just that - a multi-party failure. > > > > >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
