1851164 - SwissSign: S/MIME wrong key Usage

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Mike Guenther]

Attachment: SwissSign_Certs_SHA256_Serial_20230901.csv

This is a mis-issuance report for S/MIME certificates with sponsor validated profile issued by the Issuing CA 'SwissSign RSA SMIME NCP ICA 2021 - 1' (https://crt.sh/?caid=217357). The report is created following the CCADB guidelines (https://www.ccadb.org/cas/incident-report#incident-reports)

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 the MDSP or CCADB public mailing list, a Bugzilla bug, or internal self-audit), and the time and date.

The mis-issuance was identified during an internal review of going live with the sponsor-validated profiles on our legacy CA system issuing from "SwissSign RSA SMIME NCP extended ICA 2021 - 1". The mis-issuance happened because we issued a sponsor validated S/MIME certificate with the key usage 'key agreement' which does not match our SwissSign S/MIME CPR.

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 requirement became applicable, a document changed, a bug was introduced, or an audit was performed.

Date / time (UTC)	Action
20230828	Going live with new sponsor-validated S/MIME certificates as preparation for S/MIME BR on 1 Sept 2023. First customers start issuing certificates with the new profile
20230831, 10:00	internal review of sponsor validated profiles -> mis-match between S/MIME CPR and certificate KeyUsage detected
20230831, 10:15	Certificate issuance stopped
20230831, 10:30	confirmation of mis-issuance by second pair of eyes
20230831, 11:00	Emergency change of certificate profile 'sponsor validated'; issuance CA is approved for certificate issuance
20230831, 14:00	Certificate Mis-issuance process is started
20230831, 15:00	Audit body is informed
20230901, 08:00	Starting root cause analysis
20230901, 11:00	Posting of this Bugzilla

3. Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.

Yes, we have stopped the mis-issuances within 30 minutes of detection. The error has been corrected.

4. In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g., OCSP failures, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help measure the severity of each problem.

In total a number of 106 certificates (102 valid, 4 revoked) are mis-issued.
First certificate: 20230828, 19:07
Last certificate: 20230830, 23:31

5. When the incident being reported involves an SMIME certificate, if disclosure of personally identifiable information in the certificate may be contrary to applicable law, please provide at least the certificate serial number and SHA256 hash of the certificate.

See attached list: As it involves S/MIME certificates each certificate is listed by SHA-256 hash and serial number

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

As all CAs we prepared for the change of the S/MIME BR starting for 1 September 2023. For this change we published new certificate profiles in our SwissSign S/MIME CPR. Chapter 3.3.3.8 defines the sponsor-validated profile.

The error was made during the configuration of the legacy CA system when configuring the ICA 'SwissSign RSA SMIME NCP extended ICA 2021 - 1'. The initial analysis concludes that during this configuration the defining team made a correct definition of the profile but the task to the operating team only included the positive delta (meaning add A, modify B) but not the negative delta (remove C).

This lead to the fact that the key Usage 'keyAgreement' was not removed.

7. List of steps your CA is taking to resolve the situation and ensure that such a situation or incident will not be repeated in the future. The steps should include the action(s) for resolving the issue, the status of each action, and the date each action will be completed.

The following steps are taken:
- Revocation of affected certificates until latest Tuesday, 20230905, 10:15
- Deep dive why the negative delta has not reached the operations team.
- Based on the outcome of the deep dive define improvements to prevent this error happening again

I will update this ticket latest on Wednesday, 6 September 2023

Comment 1

[Roman Fischer]

We can confirm that all affected certificates are revoked.
Deep dive and planned improvements are still under way. We will update this ticket on Tuesday, 12 Sept 2023 latest.

Comment 2

[Mike Guenther]

We are looking into automated testings to prevent this from happening again.
Next Update is latest Tuesday, 19 September 2023

Comment 3

[Roman Fischer]

Our deep dive showed that communication between the product management, engineering and QA-teams needs to be improved. We introduced this in our requirement engineering process.

Also our automated tests will be aligned with the update process.

No further action planned on our side. If there are no open questions from the community, we would ask to close this bugzilla.

Comment 4

[Ben Wilson]

Are there any questions or other comments? Otherwise, I intend to close this on Friday, 22-Sept-2023.