On Mon, Aug 27, 2018 at 2:25 AM reinhard.dietrich--- via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> Dear all > > This is a joint answer to Waynes' request. > > it was mentioned that the audit period was exceeded. We would like to > explain the situation and what was undertaken to avoid such situation again. > > We all are aware that the audit period was exceeded by two months. However > the conducted audit from April 2018 also covers the 2 months extension. As > you already mentioned, the reason is that SwissSign decided to change the > auditors after 12 years for quality assurance reason. Additionally, it is a > best practice within the IT security world or the financial sector to > change the external auditors on a regular base. > During the process, SwissSign defined some criteria in order to choose the > new auditors these are: > > The auditors shall: > - possess a knowledge and experience since years performing PKI audits as > a full time job. > > - have experience in auditing different international CA which are also > included in the Root Stores. > > - take their time to understand in detail the processes, infrastructure, > implementations, etc. of SwissSign. > - support SwissSign being conform over time between the annual audits, > e.g. by pre-assessments of new solutions/processes/applications before > these are going in live production. > - be well known in the community. > - be active in international and national working groups in order to keep > their knowledge about requirements up-to-date. > - are /going to be accredited to perform audit according the relevant > standards. > - Fullfills requirement according to BR 8.2 and BR 8.3 > Could you explain a bit more about your selection process? The auditors you selected did not meet BR 8.2 at the time you selected them, hence the e-mail to multiple browser programs to accept audits from a non-accredited entity, on the promise that the principals involved were respected and that accreditation would be coming "soon". In April, an attempt was made to determine the accreditation status of TUV Austria Cert GMBH. Based on EA [1], the NAB for Austria is Akkreditierung Austria's Federal Ministry for Digital and Economi Afairs (BMDW). The list of CABs accredited by the NAB are available at [2] Looking at the BRs, the expectation would be that the auditor is accredited in the application of ISO 17065:2012 with the application of ETSI EN 319 403. Looking at the most recently updated list of Certification Bodies of Products, Processes, and Services, according to EN ISO/IEC 17065:2012, TUV Austria Cert GMBH's certification is [4], which doesn't cover that norm. Looking at the eIDAS list of CABs [5], which is informational but updated as of 2018-07-27, I don't see TUV Austria under AA either. So it doesn't appear to meet either ISO/IEC 17065 or the eIDAS norms (of which 17065 is effectively a pre-requisite). Could you help me understand more how TUV Austria Cert GMBH meets the criteria of BR 8.2 and 8.3? [1] http://www.european-accreditation.org/ea-members [2] https://www.bmdw.gv.at/TechnikUndVermessung/Akkreditierung/Seiten/AkkreditiertePIZ-Stellen.aspx [3] https://www.bmdw.gv.at/TechnikUndVermessung/Akkreditierung/Documents/product%20certification%20bodies.pdf [4] https://www.bmdw.gv.at/TechnikUndVermessung/Akkreditierung/Documents/AA_0943_17065_TueV_AUSTRIA_CERT_GMBH.pdf [5] https://ec.europa.eu/futurium/en/content/list-conformity-assessment-bodies-cabs-accredited-against-requirements-eidas-regulation [6] https://ec.europa.eu/futurium/en/system/files/ged/list_of_eidas_accredited_cabs-2018-07-27.pdf _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
