1718675 - certSIGN: CPS specifies md5 and sha1WithRSAEncryption as useable signature types

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Matthias]

In section 7.1.1, in table Table 7.1. "Profile of the basic fields of certificates", the CPS of the 'certSIGN ROOT CA' (https://crt.sh/?id=6385) [0] specifies 3 allowed algorithms in the "SIGNature Algorithm" field:

• md5WithRSAEncryption (OID: 1.2.840.113549.1.1.4 ) or
• sha1WithRSAEncryption (OID: 1.2.840.113549.1.1.5) or
• sha256WithRSAEncryption (OID: 1.2.840.113549.1.1.11)

Of those, I believe that md5 shouldn't be there as there shouldn't be any valid certificates left that were signed using MD5 (the notBefore of the root is 2006, md5 was already considered weak or even broken at that point), and SHA-1 should at the very least be marked as "we're not putting this in new certificates", but even better should be removed or moved to an 'old certificate profiles' section.

[0] https://www.certsign.ro/wp-content/uploads/2021/03/CP-certSIGN-Law-v1.10.pdf

Comment 1

[Gabriel PETCU]

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 Bugzilla ticket on 2021-06-29 11:21 PDT that certSIGN CPS specifies md5 and sha1WithRSAEncryption as useable signature types.
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-06-29 22:00 EEST Short review of the bug to asses the urgency/priority
2021-06-30 09:00 EEST Analysis of the issue raised; checking causes & solution
2021-06-30 10:43 EEST First draft proposal for the response to be validated
2021-06-30 17:00 EEST Internal validation of the solution & response
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.
There were no certificates issued with md5 or sha1, therefor certSIGN did not need to stop issuing certificates. Technical controls were in place at CA and issuance of certificates using md5 or sha1 is not permitted.
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.
There were no certificates issued with md5 or sha1.
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.
Not applicable.
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

The text in CPS regarding md5 and sha1 mentioned in the CPS on “Table 7.1. Profile of the basic fields of certificates” had been considered as capabilities in the past. In chapter 7.1.3 “Algorithm object identifiers” we clearly specified:
“In the case of certSIGN, algorithm used is sha256WithRSAEncryption.”

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.

The steps to correct the situation are:

1. 2021-06-30 – discuss, update and validate the CPS documentation in which md5 and sha1 will be removed from “Table 7.1. Profile of the basic fields of certificates”
2. 2021-07-02 – get approvals to publish the updated version of the CPS

Comment 2

[Gabriel PETCU]

All the proposed steps planned to correct the situation had been done.
The CPS with version 1.33 had been published in certSIGN Repository.

Comment 3

[Gabriel PETCU]

This bug had been fully resolved.
https://www.certsign.ro/wp-content/uploads/2021/03/certSIGN-ROOT-CA-Certification-Practice-Statement-v1.33.pdf
Please review it to mark it as Resolved or Fixed.

Comment 4

[Ben Wilson]

I will close this as "fixed" next Wed. 14-July-2021.