1691117 - D-TRUST: Certificate with RSA key where modulus is not divisible by 8

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Enrico Entschew]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36 Edg/88.0.705.56

Steps to reproduce:

This is a preliminary 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.
We were informed by a third party about D-TRUST’s Incident Report Mechanism that D-TRUST has issued a certificate whose RSA key does not comply with the Mozilla Root Store Policy as well as the Baseline Requirements of the CA/Browser Forum.

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.
2021-02-05, 00:41 (CET): initial report
2021-02-05, 07:00 (CET): Start of investigation
2021-02-05, 10:30 (CET): Preliminary internal feedback with investigation result
2021-02-05, 11:00 (CET): Information to the subscriber about the incident
2021-02-05, 11:22 (CET): Information to the submitter on further procedure

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.
D-TRUST already has measures in place to prevent the issuance of certificates for RSA keys that are not divisible by 8.

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.
Number of affected certificates: 1
Issuing date of first certificate: 2019-02-14
Issuing date of last certificate: 2019-02-14

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.
All affected certificates can be found here:
https://crt.sh/?id=1285854635

6.) Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Investigation is still ongoing. Result will be published with the final incident report.

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.
We already contacted the certificate holder and we will have the certificate revoked at short notice.
Further action, if required, will be published with the final incident report.
We plan to publish a final incident report by 2021-02-10.

Comment 1

[Matthias]

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.
D-TRUST already has measures in place to prevent the issuance of certificates for RSA keys that are not divisible by 8.
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.
Number of affected certificates: 1
Issuing date of first certificate: 2019-02-14
Issuing date of last certificate: 2019-02-14

Should I understand that as "we've queried our current valid certificate corpus for this problem, and have found no other certificates", or is it "this certificate was supplied, others might exist, but we won't sign new certificates with this problem"? That is not quite clear from your statements.

Comment 2

[Enrico Entschew]

Thank you for your question. Our investigation is still ongoing. What I can say in the meantime is that the affected certificate was issued via D-TRUST's application processing system for retail customers. This system was shut down for good on 19/07/2019. Please see here https://bugzilla.mozilla.org/show_bug.cgi?id=1563772

D-TRUST's Managed PKI platform is now the only system for issuing TLS certificates and has always taken measures to prevent this type of error.

Comment 3

[Enrico Entschew]

This is the final 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.
We were informed by a third party about D-TRUST’s Incident Report Mechanism that D-TRUST has issued a certificate whose RSA key does not comply with the Mozilla Root Store Policy as well as the Baseline Requirements of the CA/Browser Forum.

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.
2021-02-05, 00:41 (CET): initial report
2021-02-05, 07:00 (CET): Start of investigation
2021-02-05, 10:30 (CET): Preliminary internal feedback with investigation result
2021-02-05, 11:00 (CET): Information to the subscriber about the incident
2021-02-05, 11:22 (CET): Information to the submitter on further procedure
2021-02-09, 15:20 (CET): Revocation of the affected certificate
2021-02-10, 10:00 (CET): End of thorough analysis according to internal problem management procedures
2021-02-10: Final incident report

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.
D-TRUST already has measures in place to prevent the issuance of certificates for RSA keys that are not divisible by 8. Since 19/07/2019 no certificate can be issued with this kind of error.

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.
Number of affected certificates: 1
Issuing date of first certificate: 2019-02-14
Issuing date of last certificate: 2019-02-14

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.
All affected certificates can be found here:
https://crt.sh/?id=1285854635

6.) Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The affected certificate was issued via D-TRUST's application processing system for retail customers. This system was shut down for good on 19/07/2019.
We have followed up the discussions on MDSP and on Bugzilla. Based on the published bugs, we started an internal investigation in July 2020 to see if we had issued certificates in the past whose RSA key size was not divisible by 8. The analysis showed that no certificate was issued whose RSA key size was not divisible by 8. Due to a misunderstanding, the analysis was only carried out via the database of the currently used Managed PKI platform, but not via the database of D-TRUST's application processing system for retail customers. This application processing system for retail customers was shut down for good on 19/07/2019. Please see here https://bugzilla.mozilla.org/show_bug.cgi?id=1563772
This is how the affected certificate was not detected in our internal analysis.

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.
We revoked the certificate within the timeframe specified by BR.
We have ensured through a thorough analysis across all databases that no valid certificate exists whose RSA key size is not divisible by 8.
We have re-examined all technical measures to ensure that the issuance of a TLS certificate whose RSA key size is not divisible by 8 is prevented. In addition, the specification documents for future product design have been adapted to include the test for divisibility by 8.
We have extended the specification documents so that future analyses must always be carried out on all TLS databases as long as they contain at least one TLS certificate that is still valid.

Comment 4

[Ben Wilson]

Is there a pre-issuance check that ensures future RSA key sizes will all be divisible by 8? You state in comment #3 that there are "specification documents for future product design have been adapted to include the test for divisibility by 8." When will those be implemented? (Section 7 of the Incident Report should provide a timeline for completing remedial measures.)

Comment 5

[Enrico Entschew]

We already have pre-issuance checks that ensures future RSA key sizes will be divisible by 8. Let me explain our pre-issuance checks in detail: There is one check before the application system accepts the public key to be signed from the applicant. Currently just RSA keys with a size of 2048, 3072 and 4096 are accepted. In an error case an error code will be returned to the applicant. Additionally there is a linting check of the pre-certificate before being sent to the ct logs based on the current version of ZLint.

The production systems that have been in place since July 19, 2019 have always checked for and prevented this error. The system that produced the certificate in question was shut down on that day.

To be more specific, what I meant by writing that our specification documents have been adapted is that we use these documents to manage how we design new production systems or define new products which will be produced in the future via our existing production system. Nothing needs to be implemented because we already changed our documentation.

Comment 6

[Ben Wilson]

I believe this matter can be closed and intend to close it on Wed. 10-Mar-2021.