1950574 - SECOM: S/MIME CA Modified Opinion Report of Cybertrust Japan (CTJ)

Status: ASSIGNED

(CA Program :: CA Certificate Compliance, task)

Comment 1

[SECOM Trust Systems - ONO Fumiaki]

Audit Incident Report

Cybertrust Japan (CTJ) operates subordinate CAs signed by Security Communication RootCA2 (SECOM).
Therefore, we post an incident report prepared by CTJ on behalf of them.

https://bugzilla.mozilla.org/attachment.cgi?id=9468570
Cybertrust_Japan_2023-2024_WTSM_Modified_Opinion_Report.pdf

Finding #1

This incident report is being posted due to a modified opinion in the WebTrust for S/MIME Baseline Requirements (hereafter "WTSM") audit report for a subordinate CA certificate issued before the S/MIME BR enforcement date on 2025-02-20.
According to CCADB Policy 5.1.2 WebTrust, additionally, if required by the individual Store policy, any qualification and/or modified opinion MAY be considered an incident and have an Audit Incident Report created in a Bugzilla Bug prior to or within seven calendar days of the audit statement’s issuance date.

Root Cause Analysis

Cybertrust Japan SureMail CA G4 functions as a single subordinate CA, but there are two subordinate CA certificates.
One, (1), does not comply with SMBR (issued before S/MIME BR was established), while the other, (2), does comply with SMBR. This resulted in a modified opinion in the WTSM report for (1).
The timeline is as follows:

Date	Event
2019-09-27	Cybertrust Japan SureMail CA G4 was created, and the certificate (1) ( https://crt.sh/?id=1947831342 ) for the subordinate CA was issued, with CP ver 1.0 established as the first edition.
2023-07-31	To make Cybertrust Japan SureMail CA G4 compliant with SMBR, the subordinate CA certificate (2) ( https://crt.sh/?id=10256433847 ) was reissued using the same private key as (1), following Appendix B - Transition of Extant S/MIME CAs.
2023-08-04	CP was updated to ver 2.2 to comply with SMBR, and provision of the subordinate CA certificate (2) was started.
2024-02-16	(1) underwent a WTBR Audit for the period 2022-12-11 to 2023-12-10, and (2) underwent a WTSM Audit for the period 2023-08-04 to 2023-12-10, each receiving unqualified opinions.
2025-02-20	(1) and (2) underwent a WTSM Audit for the period 2023-12-11 to 2024-12-10. While (2) received an unqualified opinion, (1) received a modified opinion as it was a subordinate CA certificate issued before the S/MIME BR enforcement date, and a WebTrust Seal was not issued.

• Since declaring SMBR compliance in the CP, the subordinate CA certificate (2) has been provided.
• Considering (2) as an Extant CA as defined in the S/MIME BR requirements, S/MIME CAs have not been issued since "2024-09-15" as stipulated by the BR.
• To resume issuing S/MIME certificates, a subordinate CA (G5) ( https://crt.sh/?caid=386306 ) was constructed with a new key, underwent a Public Review as an Externally-operated CA, and received Mozilla's approval, so issuance was restarted on 2025-01-29.

Action Items

Action Item	Kind	Due Date
Revoke the subordinate CA certificate of (1) after the expiry of EE certificates, as the maximum validity period of EE certificates issued during the period when the intermediate CA certificate (1) was provided is 2025-08-14	Prevent	2025-08-31
Receive a Modified Opinion audit report mentioning the revocation of the intermediate certificate for (1), following a WTSM audit covering the audit period from 2024-12-11 to 2025-12-10	Prevent	2026-02-28
Submit an Audit Incident Report on Bugzilla due to the Modified Opinion for the intermediate certificate of (1)	Prevent	2026-03-07

Best regards,

ONO Fumiaki / 大野 文彰
SECOM Trust Systems Co., Ltd.

Comment 2

[chrome-root-program]

The Root Cause Analysis provided describes a problem, but does not help us understand why that problem existed. Specifically, it seems as if SECOM had revoked the version of SureMail CA G4 that did not conform with the SMBRs upon issuing the conformant version, the modified opinion would not have taken place.

While not yet effective, we’d encourage you to review the updated CCADB Incident Reporting Guidelines and to provide a more effective root cause analysis.

Also, can you help us understand:

(1) SECOM’s rationale for not revoking the original upon issuing the corrected version?

(2) The circumstances that led to this issue not being detected sooner?

(3) What process or procedural changes might be considered to (a) avoid a similar issue in the future and (b) promote better issue detection should issues arise? The Action Items described are all narrowly scoped to this specific issue, and do not describe systemic enhancements that might help prevent future issues.

Comment 3

[SECOM Trust Systems - ONO Fumiaki]

(In reply to Comment #2)

(1) SECOM’s rationale for not revoking the original upon issuing the corrected version?

We did not revoke the subordinate CA certificate because it is stated in the S/MIME BR in "Appendix B - Transition of Extant S/MIME CAs" that revocation of the subordinate CA certificate is not required.
https://github.com/cabforum/smime/blob/main/SBR.md#appendix-b---transition-of-extant-smime-cas

(2) The circumstances that led to this issue not being detected sooner?

• SECOM had recommended to CTJ several times that they establish a new S/MIME CA both before and after 2023-09-01, which is the date when S/MIME BR became effective. After 2023-09-01, SECOM also recommended establishing a new CA because the profile adopted by CTJ's S/MIME CA was the Legacy profile.
  However, we had not received a response regarding establishing a new S/MIME CA.
  We could have asked CTJ how they are planning to continue to issue S/MIME certificates in the future, but we did not. It was partly because we could not sure if it was appropriate to ask about another company's future business plans, which may proceed without SECOM signing the CA. CTJ did not explain their reason to reject.

• Although it was unclear how CTJ would respond in the future, if CTJ had established a new CA, it would have had to go through the approval process as an Externally-Operated CA ( https://wiki.mozilla.org/CA/External_Sub_CAs ), which would have taken time to obtain approval. In addition, existing subordinate CA certificates could have been reissued with a profile that complied with SMBR, so we issued a subordinate CA certificate for "Cybertrust Japan SureMail CA G4" on 2023-07-31.

• SECOM recieved a request to issue a subordinate CA (G5) ( https://crt.sh/?caid=386306 ) by CTJ which was issued on 2024-12-17.
  By receiving the application for issuance of this subordinate CA (G5), we found out that CTJ's intention was to issue S/MIME certificates under the SECOM root.

• As mentioned above, the S/MIME BR "Appendix B - Transition of Extant S/MIME CAs" explained that the pre-renewal subordinate CA certificate and EE certificates did not need to be revoked, so neither was revoked.

• CTJ believed that the subordinate CA certificate issued before the S/MIME BR was not subject to the audit requirements of "WebTrust for CAs - S/MIME", but would continue to be subject to the previously accepted "WebTrust for CAs" and Principle 4 of "WebTrust for CAs - SSL Baseline with Network Security". As explained by CTJ, SECOM also thought that this might be a possible interpretation.

• After receiving an error in CCADB stating that a WebTrust for CAs - S/MIME audit was required for pre-renewal subordinate CA certificates, we checked the S/MIME BR and the policies of each browser vendor again and concluded that a WebTrust for CAs - S/MIME audit also applied to pre-renewal subordinate CA certificates.

• CTJ also underwent a WebTrust for CAs - S/MIME audit on its subordinate CA certificate prior to renewal, but the audit report was a "modified opinion."

(3) What process or procedural changes might be considered to (a) avoid a similar issue in the future and (b) promote better issue detection should issues arise? The Action Items described are all narrowly scoped to this specific issue, and do not describe systemic enhancements that might help prevent future issues.

Cause 1: CTJ did not establish a new CA, and we reissued the subordinate CA certificate using the same private key.

We were aware that renewal was a temporary measure for transitioning to S/MIME BR compliance and that the best practice was to establish a new CA, but CTJ requested renewal in consideration of the impact on customers, and then unwillingly we accepted.

Corrective action: CTJ considered the possibility of service suspension a risk and chose renewal to continue the service to avoid this. After that, SECOM requested that "Cybertrust Japan SureMail CA G4" cease issuing S/MIME certificates in accordance with the requirements of S/MIME BR "Appendix B - Transition of Extant S/MIME CAs", and CTJ accepted. SECOM had previously recommended and discussed with CTJ that they promptly apply for an externally operated CA, but they did not apply because CTJ did not agree. We believe that we should have persuaded CTJ sooner to apply for an Externally-Operated CA.

We will prioritize how to realize best practices, take the necessary actions (including checking and consulting with the community), and make a decision after thoroughly conducting an accurate risk analysis.

Cause 2: Failure to check with the community in advance to prevent misunderstanding of requirements

The S/MIME BR "Appendix B - Transition of Extant S/MIME CAs" did not indicate the audit requirements that apply to subordinate CA certificates before renewal.

Because the subordinate CA certificate was created before the S/MIME BR was established, CTJ assumed that the audit requirements before the S/MIME BR ("WebTrust for CAs" and Principle 4 of "WebTrust for CAs - SSL Baseline with Network Security") applied.

Corrective action: Unless it is definitely mentioned as a requirement, or if there is even the slightest doubt, add a process to check with the community, browser vendors, etc. before making a final decision.

Cause 3: Not revoking subordinate CA certificates before renewal
As per root cause #1.

SECOM and CTJ believed at CCADB that subordinate CA certificates before renewal would not cause errors, reinforcing the belief that there was no need to revoke the certificate.

Corrective action: As per cause #2, if confirmation with the community had been properly conducted, the above mistake would not have occurred, and it would have been assumed that errors would occur, and revocation would have been considered. In other words, we believe that correcting cause #2 will in turn lead to correcting issue #3.

Action Items

Action Item	Kind	Due Date
To avoid similar issues in the future, SECOM and CTJ have strengthened our decision-making process to prioritize Best Practices and enhance our verification process for compliance with requirements	Prevent	2025-02-28
Revoke the subordinate CA certificate of (1) after the expiry of EE certificates, as the maximum validity period of EE certificates issued during the period when the intermediate CA certificate (1) was provided is 2025-08-14	Prevent	2025-08-31
Receive a Modified Opinion audit report mentioning the revocation of the intermediate certificate for (1), following a WTSM audit covering the audit period from 2024-12-11 to 2025-12-10	Prevent	2026-02-28
Submit an Audit Incident Report on Bugzilla due to the Modified Opinion for the intermediate certificate of (1)	Prevent	2026-03-07

Comment 4

[Ben Wilson]

These Action Items appear to extend out over 12 months into March 2026. But by September 2025, the most important ones will have been completed, and the remaining two will have a clear path to resolution. The two 2026 tasks, while important follow-ups, pertain to documenting and reporting compliance outcomes rather than immediate risk mitigation. Given that the affected Subordinate CA is scheduled for revocation by September 2025, I propose that we set a "Next Update" to 1-Sept-2025, and then re-evaluate whether this Bugzilla case could be closed at that time, provided there are no related and unresolved compliance concerns.