This post links to https://bugzilla.mozilla.org/show_bug.cgi?id=1506607
Issue description: Misissuing of Intermediate Certificates because of incorrect organizationIdentifier For the intermediate CA listed below the organizationIdentifier= NTRL-FL-0002.523.017-8 is wrong. The correct value is 'NTRLI-FL-0002.523.017-8' This is an incident report for the issue above according to https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report 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 Friday Nov 09, 2018 during an internal review as a preparation for a new product we became aware of the issue described above. 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. a. Nov 09, 2018 A SwissSign employee detected as part of an internal review a possible issue. He discussed the finding with his colleagues and contacted the internal Information Security group (InfSec) b. Nov 09, 2018 (afternoon) SwissSign InfSec started the internal incident management process. Next to other tasks this included i. Confirming the issue by checking https://www.etsi.org/deliver/etsi_ts/119400_119499/11941201/01.02.01_60/ts_11941201v010201p.pdf chapter 5.1.4; 2 character ISO 3166 is demanded => 'LI' for the EU Member state Liechtenstein, but 'L' had been used in the intermediate certs ii. Checking for additional affected certificates: a total of 6 intermediate certificates with the same issue are detected. iii. Checking for affected leaf certificates: no leaf certificates (client certs) were issued by these CA. A total of 0 (zero) leaf certificates (client certs) was detected to be hit by the problem. iv. Informing responsible management v. Informing our Auditors TÜV Trust IT (TÜV Austria) vi. Checking deadlines for revocation: 24h for leaf certificates, 7 days for intermediate certificates c. Nov 12, 2018 SwissSign starts the root cause analysis to gather data for this incident report i. Check of Key Ceremony protocol (as IC are affected): The organizationIdentifier had been set correctly in the key ceremony protocol (for all 6 IC). ii. A review of the CP/CPS (http://repository.swisssign.com/SwissSign-LI-Platinum-CP-CPS.pdf) showed that the organizationIdentifier had not been documented correctly for some of the issuing CAs: organizationIdentifier is documented as 'FL-0002.523.017-8' instead of 'NTRLI-FL-0002.523.017-8' d. Nov 12, 2018 Preparation for revocation of intermediate certificates e. Nov 12, 2018 SwissSign publishes this incident report on Bugzilla and mozilla.dev.security.policy The following follow-up measures are scheduled: ○ Publish the affected CP/CPS with correct organizationIdentifier ○ internal check for similar flaws like those started. ○ process improvement procedure started. ○ correction process for CP/CPS started. ○ external auditor asked to schedule re audit. The details of the follow-up will be posted as soon as corresponding results are available. 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. The listed CAs were not yet used to issue leaf certificates (end user certs) other than internal test certificates during audits. These test certificates have been revoked during those audits. 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. A total of 6 intermediate CAs are affected. These CAs were not yet productive. There are no leaf certificates except for the OCSP responder which we consider a part of the PKI infrastructure and therefore are not revoked within 24h. The CAs were created on June 27, 2017. 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. ○ SwissSign LI Platinum Person CA 2017 - G22 https://crt.sh/?sha256=8e35171dbc1351cf19e4d9911f367786a3b88c540529602cef9c9eba4ebac33e ○ SwissSign LI Platinum Server CA 2017 - G22 https://crt.sh/?sha256=a2f021cfe19a1c56986f0dfa6398f1a0fcc1b6504e47e0ad7fcbe5330e04aa2f ○ SwissSign LI TSA Platinum CA 2017 - G22 https://crt.sh/?sha256=988ba0b6eb48cb076060bcda65ef2c3022788dafa37948341c67d15fb17f8ae7 ○ SwissSign LI Platinum Server CA 2017 - G3 https://crt.sh/?sha256=5dcdaf64fd220b593d5905332b9f49f76b45c98d548fe02165f6b2c473945e82 ○ SwissSign LI Platinum Person CA 2017 - G3 https://crt.sh/?sha256=d1b3e166d428c329218a8f5b613c77576c2af702e3d99db477dbacee1bfd1b3a ○ SwissSign LI Platinum TSA CA 2017 - G3 https://crt.sh/?sha256=fda6049b266153b9c843662a77c50d2f0a06b8cdc8111666378bb118e7215ace 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. Based on the data gathered we concluded that the mistake was based on a human error. During the setup in the CA GUI the organizationIdentifier was miswritten throughout the certificate generation ceremony and then copy/pasted for the 5 other CAs. We did not detect these misissuances as none of the CAs were in production. While preparing for a first product the engineer discovered the issue and reported it to Information Security. 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. a. Re-publish corrected CP/CPS b. Short term we improve the creation process for issuing CAs by additional items in the checklist c. At the same time we plan to improve the quality of the creation process for IC by analyzing the creation as well as the documentation guides for CP/CPS d. Additionally we will development technically enforced safeguard that checks the compliance of the OrganizationIdentifier during the setup process (e.g. first block needs to be 5 letters or letters 4 and 5 are an ISO country code as defined in ISO 3166) This bug is originally posted on Bugzilla (https://bugzilla.mozilla.org/show_bug.cgi?id=1506607) Thank you Mike Guenther Information Security Officer SwissSign AG _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
