1827490 - Cybertrust Japan: CRL signature algorithm encoding error

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Ben Wilson]

On or about 5-Apr-2023 CRL Watch reported that two of Cybertrust Japan's CRLs had the inner AlgorithmIdentifier (tbsCertList.signature) as ecdsa-with-SHA384 (1.2.840.10045.4.3.3) with no parameters while the outer AlgorithmIdentifier (signatureAlgorithm) is
ecdsa-with-SHA384 with a parameter specifying the named curve "secp384r1". This parameter on the outer AlgorithmIdentifier was non-compliant.

As Andrew Ayer explained:

1. The ASN.1 module defined in RFC 5480 Appendix A
   (https://www.rfc-editor.org/rfc/rfc5480#appendix-A) specifies that for
   ecdsa-with-SHA384, "Parameters are ABSENT".

2. Mozilla Root Store Policy Section 5.1.2 states:

"When a root or intermediate certificate's ECDSA key is used to produce
a signature, only the following algorithms MAY be used, and with the
following encoding requirements: ... If the signing key is P-384, the
signature MUST use ECDSA with SHA-384. The encoded AlgorithmIdentifier
MUST match the following hex-encoded bytes: 300a06082a8648ce3d040303."

Those bytes do not include any parameters.

3. RFC 5280 Section 5.1.1.2 states that the outer AlgorithmIdentifier
   "MUST contain the same algorithm identifier as the signature field
   in the sequence tbsCertList". Although "same" isn't defined in RFC
   5280, in general in the WebPKI, when two things need to be the same,
   they need to be byte-for-byte identical: e.g. subject/issuer matching,
   CN/SAN matching. The profiles ballot clarifies this for certificates by
   saying that the outer signatureAlgorithm "MUST be byte-for-byte identical
   to the tbsCertificate.signature."

The CRLs have now been fixed.

This is a request that Cybertrust Japan file an incident report (https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report) here.

Comment 1

[masahiro.shikutani]

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

Ben Wilson notified us of CRL signature algorithm encoding errors below in CRL Watch.
Error message - "inner and outer signature algorithm identifiers don't match".

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 performed.

All the date and time of following timelines are described in JST.

Time - YYYY/MM/DD HH:MM	Action
2023/04/05 07:01	Ben notified us of the errors in CRL Watch.
2023/04/05 07:15	Replied to him that we would start investigation and reported to our PA this issue.
2023/04/05 07:16	Started investigation and took time to find out cause of the errors. We confirmed that inner and outer signature algorithm are both ecdsaWithSHA384(1.2.840.10045.4.3.3) and checked ASN.1 structure and related RFC. Investigation to find out cause of the error took time.
2023/04/06 23:24	Received further advice from Andrew thru Ben.
2023/04/06 23:39	Understood correctly what was wrong with our CRL signature algorithm encoding.
2023/04/07 10:15	Investigated if other Algorithm than ECDSA has same issue, Investigated if other CAs not listed on CRL Watch has same issue.
2023/04/08 21:01	A patch was developed and proceeded to QA testing.
2023/04/10 09:00	Reported to PA about the investigation results and received an approval of remediation plan from PA.
2023/04/11 15:37	Remediated CRLs were published. Confirmed that the errors were removed from CRL Watch

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.

We have not issued subscriber certificates yet under the affected CAs. The root CA is under Root Inclusion Request.

Affected Root CA:
CA SecureSign Root CA15 (https://crt.sh/?id=2700886548)

Affected Sub CAs:
Cybertrust Japan SureServer EV CA G8 (https://crt.sh/?id=3001951961)
Cybertrust Japan SureServer CA G8 (https://crt.sh/?id=3001951956)
Cybertrust Japan SureMail CA G8 (https://crt.sh/?id=3001951954)
Cybertrust Japan SureCode EV CA G4 (https://crt.sh/?id=3001951948)
Cybertrust Japan SureCode CA G4 (https://crt.sh/?id=3001951957)
Cybertrust Japan SureTime CA G4 (https://crt.sh/?id=5212820904)

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.

N/A

5. In a case involving TLS server 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. It is also recommended that you use this form in your list "https://crt.sh/?sha256=[sha256-hash]", unless circumstances dictate otherwise. 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. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.

N/A

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

This issue occurs when CA systems use ECDSA key.

Mozilla Root Store Policy Section 5.1.2 and BR 7.1.3.2.2 state that the encoded AlgorithmIdentifier MUST match the hex-encoded bytes of 300a06082a8648ce3d040303 if the signing key is P‐384. However, CRLs of the affected CAs do not compliant with the requirement.

There was a problem in the outer AlgorithmIdentifier. Compared with the inner AlgorithmIdentifier, there was an additional and unnecessary parameter. That is {1.3.132.0.34} // 2B81040022 // secp384r1. As a result, the bytes were 301106082A8648CE3D04030306052B81040022.

We had conducted bytes checking for certificate, however missed that checking for CRL.

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. The steps should include the action(s) for resolving the issue, the status of each action, and the date each action will be completed.

We developed a patch and implemented it to the CAs. And we confirmed the issue was fixed.
Also, we investigated all of other CRLs and confirmed that no additional issue found.

CRLs:

CA name	CDP
SecureSign Root CA15	http://rtcrl.cybertrust.ne.jp/SecureSign/rtca15/cdp.crl
Cybertrust Japan SureServer EV CA G8	http://evcrl.cybertrust.ne.jp/SureServer/evcag8/cdp.crl
Cybertrust Japan SureServer CA G8	http://sscrl.cybertrust.ne.jp/SureServer/ovcag8/cdp.crl
Cybertrust Japan SureMail CA G8	http://smcrl.cybertrust.ne.jp/SureMail/smcag8/cdp.crl
Cybertrust Japan SureCode EV CA G4	http://evcscrl.cybertrust.ne.jp/SecureSign/evcscag4/cdp.crl
Cybertrust Japan SureCode CA G4	http://cscrl.cybertrust.ne.jp/SecureSign/cscag4/cdp.crl
Cybertrust Japan SureTime CA G4	http://tscrl.cybertrust.ne.jp/SecureSign/tscag4/cdp.crl

We checked if certificates and CRLs of all the CAs (Not only the CAs listed on CRL Watch but also others) are appropriate and confirmed they are compliant.

We added a procedure when creating or modifying CA to check CRL conformity.

Comment 2

[masahiro.shikutani]

We are monitoring this bug.

Comment 3

[Masaru Sakamoto]

Please allow me to comment on behalf of Masahiro.
We are monitoring this bug.

Regards,
Mo

Comment 4

[Masaru Sakamoto]

We are monitoring this bug.

Comment 5

[Masaru Sakamoto]

We are monitoring this bug.

Comment 6

[Masaru Sakamoto]

We are monitoring this bug.

Comment 7

[Masaru Sakamoto]

We are monitoring this bug.

Comment 8

[Masaru Sakamoto]

We are monitoring this bug.

Comment 9

[Ben Wilson]

I haven't noticed any further incidents while monitoring https://sslmate.com/labs/crl_watch/. Therefore, I intend to close this bug on or about this Friday, 2-June-2023.