1731586 - SwissSign: Certificate with key length 16258

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Mike Guenther]

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.

During our yearly internal certificate review we detected one certificate issued on 20210521 with the key length 16258. This key length violates the Mozilla root store policy v.2.7 (effective May 1, 2021)

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.

20210920 08:00 CEST SwissSign finds an SMIME certificate with the key length 16258 during our internal certificate review.
20210920 08:30 CEST Information Security & Compliance is informed and an investigation is started
20210920 09:45 CEST The reason for the mis-issuance is detected
20210920 11:00 CEST The mis-issued certificate process is started
20210920 13:45 CEST An emergency change of the configuration is approved and executed to correct the available key length
20210920 14:30 CEST Reporting of the mis-issuance into Bugzilla and inform our auditors

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 changed the configuration in the above mentioned emergency change. We identified only one certificate with a unapproved key length.

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, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.
Issue: Wrong key length
Number of certificates: 1
Date Issuing of certificate: 20210521

5. In a case involving certificates, 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. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.

Serial of certificate: 726f3935bbece219458f519813f759b4c2224df6

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

In 20210209 we reported the following Bugzilla 1691704 with a similar issue. We also reported that we have a control in place (introduced in January 2020) that prevents the use of unapproved key length.

Since the introduction of this control we tested it several times by opening certificate requests with unapproved key length and the control never failed. So we were confident that the control itself works. Therefore, we checked the configuration and found that our configuration contained the unintended key length '16258'.

Our next step was to check when this configuration was introduced: Our logs showed that the configuration was introduced at the same time we build the control back in 2020.

After talking with the involved teams/persons we conclude the following:

• The internal processes/workflows have been followed
• The intended key length was 2^14 = 16’384
• The requester of the configuration change either miscalculated or mistyped the key length
• The reviewer (dual control) of the configuration change did not detect the mistake

7. List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.

• Today: We inform the customer to request a new certificate and afterwards to revoke the certificate
• Latest this Friday, 20210924 17:00 CEST: If the customer has not revoked the certificate SwissSign will execute the revocation
• The issue will be discussed in the next 'lessons learned' meetings with the relevant teams. Main topic is the need for accuracy when handling configuration and when doing reviews.
• Update this ticket until the internal incident is closed

Comment 1

[Matthias]

(In reply to Mike Guenther from comment #0)

5. In a case involving certificates, 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. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.

Serial of certificate: 726f3935bbece219458f519813f759b4c2224df6

I'd like to point out that this certificate doesn't seem to have been logged into CT logs, or has not been picked up by crt.sh (search on that serial number has no results [0]), likely due to it being an S/MIME certificate. Could you attach the certificate as an attachment, or link to the CT logs that we can find this certificate in?

The intended key length was 2^14 = 16’384

Was that a typo in your incident report? If not, could you clarify what you mean with "The intended key length was 16’384", and why this was not intended to be 2^11 = 2’048?

[0] https://crt.sh/?serial=726f3935bbece219458f519813f759b4c2224df6

Comment 2

[Mike Guenther]

(In reply to Matthias from comment #1)

I'd like to point out that this certificate doesn't seem to have been logged into CT logs, or has not been picked up by crt.sh (search on that serial number has no results [0]), likely due to it being an S/MIME certificate. Could you attach the certificate as an attachment, or link to the CT logs that we can find this certificate in?

Yes that is correct. It is an S/MIME certificate (see initial post under 2.).
For S/MIME certificates we disclose only the serial number to not violate the privacy of the customer. This has been an accepted practice in the past.

Was that a typo in your incident report? If not, could you clarify what you mean with "The intended key length was 16’384", and why this was not intended to be 2^11 = 2’048?

No, that was no typo. Of course we have several other key length defined (Including the 2048). The other key lengths are correct.

Comment 3

[Matthias]

For S/MIME certificates we disclose only the serial number to not violate the privacy of the customer. This has been an accepted practice in the past.

I'm having trouble finding the "accepted practice" exemption for not including the S/MIME certificate data in the incident report. Do you have a reference?

Ben, if this is indeed accepted practice, could you update the wiki page accordingly to reflect this? Currently the "Responding To An Incident" page (that is the basis of my expectations) does not distinguish between certificate types.

No, that was no typo. Of course we have several other key length defined (Including the 2048). The other key lengths are correct.

Ah, I misunderstood the problem.

I misremembered the requirements as limiting the RSA signatures to 1 key size (through the specific subset of encodings of signature types) and thus this uncommon key size (fast reading: both occurrances 16k) being invalid. But, the requirement that you were in non-compliance with was the 'modulus size in bits is multiple of 8' requirement as found in MRSP s5.1 (1). So, sorry for the noise on that part.

Comment 4

[certreporter]

(In reply to Mike Guenther from comment #2)

For S/MIME certificates we disclose only the serial number to not violate the privacy of the customer. This has been an accepted practice in the past.

Your CPS states that all information included in a certificate is deemed public, so making the above statement about privacy actually goes against your own policies

Comment 5

[Ben Wilson]

I can see why publicizing personal information that is in the certificate, even though the CPS says it's deemed public, is a sensitive matter. I don't have a great answer yet. However, from a Mozilla perspective, there is Principle 4 to consider - "Individuals’ security and privacy on the internet are fundamental and must not be treated as optional." I'll continue contemplating how we can provide better guidance on this going forward with regard to SMIME certificate information and the "Responding To An Incident" wiki page.

Comment 6

[Mike Guenther]

(In reply to Matthias from comment #3)

For S/MIME certificates we disclose only the serial number to not violate the privacy of the customer. This has been an accepted practice in the past.
I'm having trouble finding the "accepted practice" exemption for not including the S/MIME certificate data in the incident report. Do you have a reference?
If the email address clearly identifies the person (such as [e-mail]) it is protected by Swiss as well as EU Privacy laws (the customer lives in Switzerland but is a EU citizen). Personally I am convinced that the serial number offers the necessary information to handle the issue within this public ticket.

Comment 7

[Mike Guenther]

(In reply to Mike Guenther from comment #0)

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.

During our yearly internal certificate review we detected one certificate issued on 20210521 with the key length 16258. This key length violates the Mozilla root store policy v.2.7 (effective May 1, 2021)

I have to correct the above statement. This bugzilla is not only based on a violation of the Mozilla Root Store Policy but also a violation against 6.1.5 of the BR (there was an alignment of the documents).

7. List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.

• Today: We inform the customer to request a new certificate and afterwards to revoke the certificate
• Latest this Friday, 20210924 17:00 CEST: If the customer has not revoked the certificate SwissSign will execute the revocation
• The issue will be discussed in the next 'lessons learned' meetings with the relevant teams. Main topic is the need for accuracy when handling configuration and when doing reviews.
• Update this ticket until the internal incident is closed
  The revocation has taken place on Wednesday 20210922

Comment 8

[Ben Wilson]

Hi Michael,
Could you please provide the SHA256 hash of the certificate? I think that is what we (Mozilla) will additionally require in the future for Incident Reports when we encounter this type of privacy issue.
Thanks,
Ben

Comment 9

[Ben Wilson]

I have amended https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report to state, "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."

Comment 10

[Mike Guenther]

(In reply to Ben Wilson from comment #9)

I have amended https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report to state, "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."

of course. here is the update to point 5 of my original post:

5. In a case involving certificates, 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. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.

Serial of certificate: 726f3935bbece219458f519813f759b4c2224df6
SHA256 of the certificate: F83C0721ACC086DE5057ADBE460C8571BA1F29890E4FE51CA211FEC55AD4FFFA

Comment 11

[Mike Guenther]

Short update:
As written in comment 7 the certificate has been revoked 20210922.
A lessons-learned meeting will take place next week. I will update this ticket afterwards.

Comment 12

[Mike Guenther]

Update of Lessons learned:

In our lessons learned meeting we concluded that it was human error.

• As a remediation we add a new control that checks if all configured key lengths are divisible by 8 as required by the BR.
• Additionally we plan to introduce an internal linter that checks each certificate key length if it is divisible by 8.

The improvements above are planned to be implemented with the November release. Next Update after implementation

Comment 13

[Mike Guenther]

We updated our systems as of yesterday. The additional controls (see above) are implemented.

There are no other steps planned from our side.

Comment 14

[Ben Wilson]

I will close this on Friday, 12-Nov-2021, unless there are additional questions to be resolved.