1695993 - SECOM: Outdated audit statements for intermediate certificates

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Kathleen Wilson]

Audit statements are past due for the following intermediate certificates.

• Certificate Name: JPRS Organization Validation Authority - G3
  SHA-256 Fingerprint: 21C066332D6B92DD9A253E2637684A5BC3E31357F863BED7A2F98C8459A33B62
  Standard Audit Period End Date (mm/dd/yyyy): 10/29/2019
  BR Audit Period End Date (mm/dd/yyyy): 10/29/2019

• Certificate Name: JPRS Domain Validation Authority - G3
  SHA-256 Fingerprint: 659B7A518C6C9EB18AA1EB35AEBA7A0247817B898C1FA1840F97D2877D9A20E4
  Standard Audit Period End Date (mm/dd/yyyy): 10/29/2019
  BR Audit Period End Date (mm/dd/yyyy): 10/29/2019

SECOM did provide audit statements for the doppelgangers of these certificates.
WebTrust CA: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=248472
and
WebTrust BR: https://bug1313445.bmoattachments.org/attachment.cgi?id=9202076

So maybe SECOM should revoke these two particular intermediate certificates.

Comment 1

[Ryan Sleevi]

Please also see Bug 1695938, which is also rather worrying.

Comment 2

[Hisashi Kamo]

Kathleen-san,

These two particular intermediate certificates you pointed out were revoked on March 9th.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Comment 3

[Kathleen Wilson]

Please also provide an incident report to explain why the SHA-256 fingerprint for these particular intermediate certificates were not listed in the audit reports. Thanks.
https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

Comment 4

[Hisashi Kamo]

Kathleen-san,

Please let us provide you 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 mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

We became aware of this issue in "[Bug 1695993] SECOM: Outdated audit statements for intermediate certs" posted to Bugzilla on March 3, 2021 at 03:51 (JST).

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.

07/10/2020 We issued two intermediate certificates in question.
03/03/2021 We noticed the report in Bugzilla.
03/09/2021 We revoked the two intermediate certificates in question.

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.

On March 9, 2021, we revoked the two intermediate certificates in question.

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 the intermediate certificates in total: 2
https://crt.sh/?id=3067358277
https://crt.sh/?id=3067358278

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.

Please refer to the contents of 4 above.

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

We issued the intermediate certificates on July 10, 2020, but because the serial number entropy for those intermediate certificates was not as we intended, we decided not to use them, and thus, we did not inform end users and others to use those certificates.

https://crt.sh/?id=3067358277
https://crt.sh/?id=3067358278

The intermediate certificates in question were mistakenly not included in the scope of the audit because, as mentioned above, we had decided not to use them.
Hence, audit statements for those intermediate certificates were not provided.

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.

In order to have all the intermediate certificates that can be used to issue subscriber certificates subject to be audited, we have revised manuals and check sheets to prevent any recurrence of the problem.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Comment 5

[Ryan Sleevi]

Thanks. I think, as with other SECOM reports, this opens up more questions than it answers.

1. Can you describe the serial number entropy issue?
2. Why didn't you immediately revoke those certificates when you were aware there were issues?
3. What exactly was the old process, and what is the new process? Mozilla's Responding to an Incident page is quite clear that:

   For example, it’s not sufficient to say that “human error” of “lack of training” was a root cause for the incident, nor that “training has been improved” as a solution.

The issuance of improper intermediates, and the failure to revoke them, is hugely serious; even more serious than failing to validate the domain. Please try to provide as much technical detail as possible, so that we can learn more about how this error was introduced, and how we can be confident there are both not additional serious errors lurking or possible.

Comment 6

[SECOM Trust Systems - ONO Fumiaki]

Attachment: OK

Comment 7

[SECOM Trust Systems - ONO Fumiaki]

Ryan-san,

This is Fumiaki Ono at SECOM Trust Systems.
On behalf of Hisashi Kamo, I am writing this comment.

1.Can you describe the serial number entropy issue?

What we explained in the previous report was insufficient.
The serial number issue here is an issue with JPRS's policy, instead of a compliance problem with BR and so on.
Please note that the CA subject to this incident is issued by SECOM which manages the Root CA and undergoes a Web Trust audit, and JPRS undergoes a separate Web Trust audit for that CA.
It was also a case that occurred at the boundary between the two companies, SECOM and JPRS.
Allow us to explain how this happened is as follows:
SECOM issued JPRS the intermediate CA certificate with serial number of 32 hexadecimal digits on July 11, 2019 (one year ago). (*1-1)

In 2020, JPRS wanted to issue the certificate which also has the same number of digits in the serial number as in 2019.
Since neither JPRS nor SECOM explicitly confirmed the number of digits in the serial number, the certificates were issued with the serial number with18 hexadecimal digits, which is the default setting of SECOM. (*1-2)
Upon the request of JPRS, SECOM changed the number of digits of the serial number to 32 hexadecimal digits and reissued it. (*1-3)

(*1-1)
https://crt.sh/?id=1671982905
https://crt.sh/?id=1671982906

(*1-2)
https://crt.sh/?id=3067358277
https://crt.sh/?id=3067358278

(*1-3)
https://crt.sh/?id=3068756691
https://crt.sh/?id=3068756692

2.Why didn't you immediately revoke those certificates when you were aware there were issues?

SECOM and JPRS observe in July 10, 2020 that it would not be a BR violation to set the serial number of the intermediate CA certificate to 18 hexadecimal digits. Then JPRS did not request for immediate revocation and SECOM agreed to the matter too.
JPRS planned to revoke the certificates in April 2021, along with other intermediate CA certificates for the same subject, and SECOM approved the decision.
The reason for planning to revoke at the same time is that if there is a certificate with the same public key as the Subject but with a different serial number, JPRS were concerned the risk that revoking one of the intermediate CA certificates would affect the verification of end-user certificates (Subscriber Certificates).
JPRS noticed that there was a problem with BR via this Bugzilla (Bug 1695993), and requested for revocation to SECOM and the revocation was completed.
SECOM should have ensured that the issued certificates were tracked, and should have revoked when confirmed that they were not included in the audit report.

(*2-1)
https://bugzilla.mozilla.org/show_bug.cgi?id=1649962
https://bugzilla.mozilla.org/show_bug.cgi?id=1652610

3.What exactly was the old process, and what is the new process?

Old process:
JPRS considered that only the intermediate CA certificate used during the target period is scope of audit, and the target intermediate CA certificates were extracted from Repository.
They only presented the intermediate CA certificates that they used to the audit corporation.

New process:
To revise the current manual and check sheet to prevent recurrence.
SECOM and JPRS do the following, specifically:
・Intermediate CA certificates that are no longer used will be promptly revoked with a revocation plan.
・JPRS will maintain list of intermediate CA certificate, SECOM will extract list of intermediate CA certificate from log data, and identify those lists regularly, so that we would check the "List of intermediate CA certificates that we grasp"
・We treat all JPRS intermediate CA certificates as the subject to be audited（without any exception）, which can be used to issue web server authentication certificates, regardless of whether they are used or not, and we will conduct an audit based on the "List of intermediate CA certificates that we grasp".

Best regards,
Fumiaki Ono
SECOM Trust Systems CO., LTD.

Comment 8

[SECOM Trust Systems - ONO Fumiaki]

Ryan-san,

This is Fumiaki Ono at SECOM Trust Systems.

The description of (*2-1) was omitted in the text, so the text has been corrected.

2.Why didn't you immediately revoke those certificates when you were aware there were issues?

・Before correction
JPRS planned to revoke the certificates in April 2021, along with other intermediate CA certificates for the same subject, and SECOM approved the decision.

・After correction
JPRS planned to revoke the certificates in April 2021, along with other intermediate CA certificates for the same subject, and SECOM approved the decision. (Support for Bug 1649962 and Bug 1652610 (*2-1))

Best regards,
Fumiaki Ono
SECOM Trust Systems CO., LTD.

Comment 9

[Ben Wilson]

I believe this bug can be closed and will schedule it for closure on Friday, 16-Apr-2021, unless there are additional matters to discuss.