Re: Audit Reminder Email Summary
Dear all, as already mentioned above, qualified auditors (nat person/organization) have been selected which fulfil the points as listed in our previous response. The auditors fulfilled these relevant requirements. Even the organization of TÜV AUSTRIA CERT was accredited according to ISO 17065 by that time –the only thing missing was the formal acknowledgement of the Austrian Federal Ministry for Digital and Economy Affairs (BMDW) for amending that accreditation by the ETSI ENs. The accreditation audit had successfully been performed by the Ministry BMDW in June and a corresponding positive report had been issued to TÜV AUSTRIA CERT. That report had been forwarded immediately to the Browsers. Following this time frame, at the time when our Audit Attestations were issued, the auditors already passed its accreditation audit. Hereafter however, the formal completion of the accreditation process by the Ministry requires time until the accreditation certificate is finally issued. Now – after summer holiday season -, the accreditation certificate is expected to be delivered every day. Along with that all public lists will be updated so that TÜV AUSTRIA CERT’s ETSI expansion of their accreditation according to ISO 17065 will finally be visible. Related to our own SwissSign audit which was required to be performed as soon as possible, we decided to ask the browsers before the audit was started, whether they would accept the audit performed by our auditors under that circumstances described above. Based on the Mozilla Root Policy, clause 3.2, para 2 Mozilla can decide to accept the auditor. On top we considered that as the auditors are well known in the community and have long term experience auditing several CA included in the Root Stores according ETSI and BRG, therefore they should easily be accepted to perform our audit. We discussed that with Mozilla and Microsoft and both finally agreed to a one time exception so that we decided to start the audit project. That given exception included an agreement that the Audit Attestations will be re-issued now, after the formal accreditation process is finalized – which will happen during the next few weeks. All the Browsers will receive an updated Audit Attestation then referring the amended accreditation documentation. On top of that and as already mentioned above, we will repeat all the audits during the next weeks in order to start over and synchronize the audit period for the complete PKI of SwissSign. At this time the expansion of TÜV AUSTRIA CERTS accreditation according ISO 17065 and ETSI EN 319 403 will certainly be visible. Best Regards Reinhard Dietrich ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audit Reminder Email Summary
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 The whole process took its time because of the complexity of such a change. At the end, SwissSign decided to work together with the qualified auditors from TÜV Austria which will perform all audits for all PKI in the future. The upcoming audit for the Silver and Platinum PKI was performed as soon as the contract was agreed and signed. We would also like to point out that both PKI are maintained under exact the same physical, technical, organizational and logical conditions and measures as the Gold PKI which is was audited in October 2017. Additionally, the Platinum PKI is also audited according the Swiss Law on an annual base. In order to avoid such exceeding, the contract with the auditors was signed for the next several years, in order to ensure that the audits are planned and performed in time as required by the CA/B Forum and the Browser Root CA Policies. It is already planned that in September 2018 a new full audit for all PKI (Silver, Platinum and Gold G2 and G3) will be performed. After the audit for all three PKI, completely new audit attestations will be issued covering the period until the last audit day. This will be the start point for a full annual audit for all PKI together so that there is not any timely separation between them. Additionally, the audits for the next years are already planned, so that an exceeding of the audit period will be prevented. We hope that this sheds some lights on the situation. Thanks and kindest regards Reinhard Dietrich ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
SwissSign: Cert issued with a to long validity period
to whom it may concern Last week we have reported a Bug on https://bugzilla.mozilla.org/show_bug.cgi?id=1443731 about a certificate we issued with a to long validity period. We are now asked to publish the same incident report also on this mozilla.dev.security.policy forum: Topic 1: How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. On the evening of 6th March 2018 our CABLint post-issue test system alerted us to this problem. We also received emails from an external source Topic 2: A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. 2018-03-06 15:49 UTC The certificate was issued 2018-03-07 06:00 UTC We started an investigation 2018-03-07 07:00 UTC We contacted the customer in order to replace the certificate and revoke the mis-issued one 2018-03-07 12:36 UTC The certificate was revoked Topic 3: Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. We identified the source of the problem as incorrect use of a rarely used reissue option available only to SwissSign support employees. We immediately prohibited any use of this functionality until the option is fixed (ETA 17th March 2018). Topic 4: A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. https://crt.sh/?id=348592796=zlint,cablint Topic 5: The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. See https://crt.sh/?id=348592796=zlint,cablint Topic 6: Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. The support option in question was not in scope during the initial work to implement ballot 193 - it was planned to be implemented by 17th March 2018. During the interim period support staff were trained to use the functionality with caution and in accordance with the requirements. Topic 7: List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. Immediate action: We have prohibited any use of the problematic reissue functionality until it is technically constrained to 825 days for SSL certificates 7th March 2018: The fixes for the reissue functionality have been rolled out to our test environment 17th March 2018: The fixes for the reissue functionality will be rolled out in production ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
