1952639 - TWCA: Missing or Inconsistent Disclosure of S/MIME BR Audits

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[chtsai]

Preliminary Incident Report

Summary

• Incident description:
  Based on disclosures at https://crt.sh/mozilla-disclosures, TWCA CYBER Root CA is considered to be missing an S/MIME BR Audit report.

• Relevant policies:
  Per the Mozilla, Apple, and Microsoft root program policies, all CA Owners with one or more Root or Intermediate CAs trusted for the issuance of S/MIME certificates should have completed an S/MIME BR audit by now and disclosed the audit details on each applicable CCADB record.

  • MRSP 5.3
  • S/MIME BR 8.4

• Source of incident disclosure:
  On 2025-03-05 at 21:03 UTC, a post regarding Missing or Inconsistent Disclosure of S/MIME BR Audits was made in the CCADB Public group, which mentioned that TWCA is missing an S/MIME BR Audit report.

Comment 1

[chtsai]

We have two questions and kindly request Mozilla’s assistance in clarifying them:

Question 1: Should the TWCA CYBER Root (self-signed certificate) be included in the S/MIME audit report?

• This certificate belongs to a dedicated root certificate for TLS purposes.
• In the CCADB classification under Certificate Record Type, it is categorized as a Root Certificate.
• In CCADB value under Trust Bits For All Root Stores, it supports only Server Authentication.
  • None of the intermediate certificates issued by this certificate contain the emailProtection EKU.
• Based on reports from this bug, including this certificate in the audit report may result in upload failures.

Question 2: Does the definition of Intermediate Certificates in MRSP 5.3 also apply to the TWCA CYBER Root (self-signed certificate)?

• We agree with the statement “...directly or transitively chain to a CA certificate...”, but based on the latter part stating “...MUST contain an EKU extension...”, we think that section 5.3 may not apply to self-signed root certificates.
• Our situation is slightly different from that case, in which the example involved two self-signed root certificates sharing the same private key.
  • TWCA CYBER Root (self-signed certificate) and TWCA CYBER Root (cross-certificate) are issued by different issuers.
  • Among these, the TWCA CYBER Root (cross-certificate) has already been included in the S/MIME audit scope.

We hope Mozilla can understand our questions and advise us on the appropriate next steps.
Thank you very much.

Comment 2

[Ben Wilson]

(In reply to chtsai from comment #1)

Anyone, please correct me if I have misunderstood these questions.

We have two questions and kindly request Mozilla’s assistance in clarifying them:

Question 1: Should the TWCA CYBER Root (self-signed certificate) be included in the S/MIME audit report?

No. Our records indicate that this root certificate is designated solely for TLS with the websites trust bit.

Question 2: Does the definition of Intermediate Certificates in MRSP 5.3 also apply to the TWCA CYBER Root (self-signed certificate)?

No. Self-signed root certificates were not intended to be included, but cross certificates issued to roots are still considered included in this statement of policy. Apparently, the TWCA CYBER Root (cross-certificate)](https://crt.sh/?id=8244056240) - subordinate certificate to TWCA Global Root CA, with SHA256 hash of:
C619F4E6F7B1BAA7A6C6F244092A3F82E46A6D67BEE26337FBAF02546F33133F - was included in the S/MIME audit dated 11-Mar-2024 with a hash of:
C619F4E6F7B1BAA7A6C6F244092A3F82E46A6D67BEE26337FBAF02546F33133F.

Comment 3

[Dimitris Zacharopoulos]

Ben,

If I'm not mistaken, doppelgänger CA Certificates (self-signed, using the same key as the Mozilla-trusted ones) should also be included in audit reports.

Also, if a CA cross-signs a dedicated use-case Root with an older multi-purpose Root, the dedicated use-case Root becomes in scope of the multi-purpose standards, at least until the multi-purpose Root gets distrusted.

The applicability of standards is not based on the "intent" but on the "technical capability". For example, if a TLS-only Root hierarchy not intended to issue S/MIME certificates but is cross-signed with a Root that is trusted for S/MIME and the cross-certificate does not technically restrict the id-kp-emailProtection KeyPurposeId in the extKeyUsage extension, it is in-scope of the S/MIME BRs and corresponding policies.

Comment 4

[Ben Wilson]

Thanks, Dimitris.

I think I understand your position—the requirements should focus on technical capability rather than policy intent, and if my policy interpretation is to hold, then I think it would be advisable to clarify the policy language further.

Currently, MRSP section 5.3.2 states:

All certificates that are capable of being used to issue new certificates, that are not technically constrained, and that directly
or transitively chain to a certificate included in Mozilla’s root store MUST be audited in accordance with this policy, and the
corresponding audit statements MUST be disclosed in the CCADB according to section 5 of the CCADB Policy.

But this language doesn't help clarify things much, and I don't think there is much more.
Section 5.3.2's opening language:

The operator of a CA certificate included in Mozilla’s root store MUST publicly disclose in the CCADB all CA certificates
it issues that chain up to that CA certificate trusted in Mozilla’s root store that are technically capable of issuing working
server or email certificates, including such CA certificates that are revoked but not yet expired and those CA certificates
that share the same key pair whether they are self-signed, doppelgänger, reissued, cross-signed, or other roots.

only addresses CCADB disclosure -- and all of these certificates have been disclosed in the CCADB.

Given this discussion, do you think it would be beneficial to explicitly clarify in policy whether self-signed root certificates need to be covered by audits, and under what conditions?

Also, I didn’t mention that the CCADB does not currently support audit-checking with transitive chain building back to self-signed roots—it only handles subordinate CA certificates that chain below a root. (Root store operators would have to manually update self-signed root certificates by monitoring and adding or removing trust bits on a continual basis.) And CA Owners rely on CCADB’s structure for compliance, so expecting them to manually track additional audit obligations could create gaps or inconsistencies. This technical limitation in the CCADB reinforces why a strict, technical-capability approach might not be feasible in this situation and why a policy decision is preferable.

Given these practical constraints, how should we balance policy intent with the technical realities of CA certificate processing in the CCADB?

I think the policies should be updated to reflect the CCADB's current operational model.

Thoughts?

Comment 5

[chtsai]

Thank you, Ben and Dimitris, for helping to clarify the issue.

Update

Although there are still some clarifications needed regarding the regulations, to mitigate the risk of non-compliance, we have obtained approval from the auditor to include the TWCA CYBER Root (self-signed certificate) in last year's S/MIME audit report (audit period: 2024/1/1 – 2024/12/31). We have already opened a case in CCADB and expect to complete the audit report upload by the end of March.

Comment 6

[Jesper Kristensen]

I think that given the cross-certificate https://crt.sh/?id=8244056240 does not have an EKU extension, it is unrestricted and the root https://crt.sh/?id=8697291574 needs to be S/MIME audited. The root https://crt.sh/?id=8697291574 is multi-purpose and needs to be transitioned to a dedicated root according to Mozilla and Chrome policies by either removing the new root or revoking the cross-certificate (and possibly replacing it with one that has a restricted EKU).

Comment 7

[Dimitris Zacharopoulos]

(In reply to Ben Wilson from comment #4)

Thanks, Dimitris.

I think I understand your position—the requirements should focus on technical capability rather than policy intent, and if my policy interpretation is to hold, then I think it would be advisable to clarify the policy language further.

Currently, MRSP section 5.3.2 states:

All certificates that are capable of being used to issue new certificates, that are not technically constrained, and that directly
or transitively chain to a certificate included in Mozilla’s root store MUST be audited in accordance with this policy, and the
corresponding audit statements MUST be disclosed in the CCADB according to section 5 of the CCADB Policy.

But this language doesn't help clarify things much, and I don't think there is much more.

Why not? If you would like to clarify the word "capable", you can use similar language as in 1.1, 3.1 and 5.3.2, and make it "technically capable".

How about adding language as guidance to technically constrain the scope of cross-certification between multi-purpose and single-purpose hierarchies, or between EV and non-EV hierarchies, by the use of extKeyUsage and/or certificatePolicies extensions?

Comment 8

[chtsai]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000054

• Incident description: Based on disclosures at mozilla-disclosures, TWCA CYBER Root CA(self-signed certificate) is considered to be missing from the S/MIME BR Audit report.

• Timeline summary:

  • Non-compliance start date: 2024-03-07
  • Non-compliance identified date: 2025-03-06
  • Non-compliance end date: 2025-03-15

• Relevant policies:

  • MRSP 5.3
  • S/MIME BR 8.4

• Source of incident disclosure: Third Party Reported

Impact

• Total number of certificates: N/A
• Total number of "remaining valid" certificates: N/A
• Affected certificate types: N/A
• Incident heuristic: N/A
• Was issuance stopped in response to this incident, and why or why not?: No, it is not related to certificate issuance.
• Analysis: N/A
• Additional considerations: N/A

Timeline

All times are UTC+8.

2025-03-06 05:03

• A post regarding "Missing or Inconsistent Disclosure of S/MIME BR Audits" was made in the CCADB Public group, which mentioned that TWCA is missing an S/MIME BR Audit report.

2025-03-06 09:30

• Responded to the post and raised some questions to clarify the cause.

2025-03-06 11:44

• Continued responding and discussing, including whether the cross-certificate, which is already covered in the S/MIME audit, implies that a standalone TLS-only self-signed root certificate also needs to be included.

2025-03-07 11:44

• Continued responding and discussing.

2025-03-08 20:51

• Published the Preliminary Incident Report on Bugzilla.

2025-03-10 16:55

• After discussions with the external auditors, they agreed to include TWCA CYBER Root(self-signed certificate) in the S/MIME audit report.

2025-03-12 09:03

• The audit report was re-signed and finalized.

2025-03-14 18:00

• The annual audit case update on CCADB was completed.

Related Incidents

N/A

Root Cause Analysis

Contributing Factor 1: The relevant requirements are not clearly defined.

• Description:
  In various Root Program Policies, the term "technical capability" applies to Intermediate CAs (including cross-certificates) but does not specifically apply to Root CAs.
  We may have had a misunderstanding all along; for self-signed Root certificates, we have been using the "trust bit(s)" to determine whether they should be included in the audit report.

• Timeline:
  2025-03-06：Rob's explanation in this response seems reasonable to us.

• Detection: N/A

• Interaction with other factors:
  Because of Factor 2, we believed that our understanding was correct.

• Root Cause Analysis methodology used: N/A

Contributing Factor 2: CCADB's ALV processing algorithm may not be entirely consistent with the policy

• Description:
  It seems that CCADB’s ALV relies on the "trust bit(s)" to determine whether a self-signed Root certificate should be included in the audit report.
• Timeline:
  2024/03/29：The S/MIME audit report can pass the ALV check.
  2025/03/15：Ben explained the current CCADB implementation in comment 4.
• Detection:
  When uploading the S/MIME audit report, CCADB ALV did not trigger any alerts.
• Interaction with other factors: N/A
• Root Cause Analysis methodology used: N/A

Contributing Factor 3: Cross Certificate does not include EKU

• Description:
  When TWCA CYBER Root (cross-certificate) was issued on December 9, 2022. In TLS BR 1.8.6, the EKU field for Cross certificates was optional.
• Timeline:
  2022-06-01：Chrome Root Program Policy 1.1 first introduced the concept of dedicated PKI hierarchy.
  2022-11-07：TLS BR 1.8.6 published. The EKU field for Cross Certificates is optional.
  2022-12-09：Issuance of TWCA CYBER Root(cross-certificate).
  2023-09-15：TLS BR 2.0.0 published. The profile of Cross Certificates marked EKU as SHOULD be included.
• Detection:
  This issue was discovered through the CCADB Public group.
• Interaction with other factors:
  Although Chrome has introduced the concept of dedicated PKI hierarchy, the content only contains requirements for Intermediate CAs and Subscriber Certificates beneath the Root CA, which is similar to the situation in Factor 1
• Root Cause Analysis methodology used: N/A

Lessons Learned

• What went well:
  Since we were closely following various discussion channels, we noticed the issue very quickly and reported it to the management team right away. This helped us handle the situation fast and clearly share our position.
• What didn’t go well:
  There are still some ambiguities in this issue, and certain aspects differ from our previous understanding.
• Where we got lucky:
  We happened to be in the process of preparing last year’s audit report. After understanding the issue, the auditor was willing to re-sign the audit report.
• Additional:
  There may still be unresolved discussions regarding this incident. However, from a CA’s perspective, we adopt a stringent approach to all possible issues. We acknowledge the perspectives of all parties and recognize that there is room for improvement. Therefore, we will do our best to eliminate these inconsistencies.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
In the future, for similar situations, we should take a stricter approach and consider including root certificates in the audit report.	Prevent	Root Cause # 1 and # 2	N/A	2025-03-14	Complete
Reissue TWCA CYBER Root (cross-certificate) with EKU.	Mitigate	Root Cause # 3	Will be disclosed in CCADB	2025-05-31	Ongoing
Revoke TWCA CYBER Root (cross-certificate) without EKU	Mitigate	Root Cause # 3	Will be disclosed in CCADB	2025-05-31	Ongoing

Appendix

N/A

Comment 9

[chtsai]

Hi Ben, if no other questions, we request setting the next update for May 31st. Thanks.

Comment 10

[chtsai]

TWCA held a PMA meeting on April 30 and reached the conclusion to cancel items 2 and 3 of the action items, for the following reasons:

• The issue regarding the scope of the CA covered by the original S/MIME audit report has already been resolved through item 1 in the action items.
• The current profile of the cross certificate does not violate the BR requirements in effect at the time.
• Internal evaluation suggests that re-signing the cross certificate would result in a NotBefore date later than that of the SubCA certificate, and we are unable to assess whether this might affect any relying party software during certificate chain validation.
• The previous generation multi-purpose RCA is approaching sunset, so the cross certificate without EKU will not exist for long.

Based on the above, we are updating the status of the action items to "Cancelled".

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
In the future, for similar situations, we should take a stricter approach and consider including root certificates in the audit report.	Prevent	Root Cause #1 and #2	N/A	2025-03-14	Complete
Reissue TWCA CYBER Root (cross-certificate) with EKU.	Mitigate	Root Cause #3	Will be disclosed in CCADB	2025-05-31	Cancelled
Revoke TWCA CYBER Root (cross-certificate) without EKU	Mitigate	Root Cause #3	Will be disclosed in CCADB	2025-05-31	Cancelled

If there are no further issues, we plan to submit the Report Closure Summary in one week.

Comment 11

[Jeremy]

I don't think you can move those action items to canceled.

The issue regarding the scope of the CA covered by the original S/MIME audit report has already been resolved through item 1 in the action items.
Having an audit going forward doesn't cover the missed audit period required by the SMIME BRs. The better way to fix this would be to amend the audit report to include the missing cross-certs. If you can't amend the audit report to cover those cross-certs, then you need to revoke or added to OneCRL. There are lots of examples:
https://bugzilla.mozilla.org/show_bug.cgi?id=1367842
https://bugzilla.mozilla.org/show_bug.cgi?id=1586125
https://bugzilla.mozilla.org/show_bug.cgi?id=1600844

All of these examples are TLS roots not listed in an audit, but I do not see why the same rules wouldn't apply here, especially when you can likely get an updated audit report that covers these cross-certs from the effective date of the SMIME BRs to today.

Internal evaluation suggests that re-signing the cross certificate would result in a NotBefore date later than that of the SubCA certificate, and we are unable to assess whether this might affect any relying party software during certificate chain validation.
This isn't a good reason. The cross certs need an audit or need to be on OneCRL.

The previous generation multi-purpose RCA is approaching sunset, so the cross certificate without EKU will not exist for long.
Yet it still exists today. That's not a good reason to not revoke a non-compliant cert.

Comment 12

[chtsai]

Hi Jeremy, thank you for your attention.

(In reply to Jeremy from comment #11)

I don't think you can move those action items to canceled.

The issue regarding the scope of the CA covered by the original S/MIME audit report has already been resolved through item 1 in the action items.
Having an audit going forward doesn't cover the missed audit period required by the SMIME BRs. The better way to fix this would be to amend the audit report to include the missing cross-certs. If you can't amend the audit report to cover those cross-certs, then you need to revoke or added to OneCRL. There are lots of examples:
https://bugzilla.mozilla.org/show_bug.cgi?id=1367842
https://bugzilla.mozilla.org/show_bug.cgi?id=1586125
https://bugzilla.mozilla.org/show_bug.cgi?id=1600844

Our issue is not that the cross-certs were excluded from the S/MIME audit report — they were correctly included from the beginning.
The actual issue was that the single-purpose TLS root cert was not covered in the S/MIME audit report.

Additionally, according to the timeline in comment 8, we updated the audit report on March 10, 2025, to include the single-purpose TLS root cert under the S/MIME audit scope, and uploaded it to CCADB on March 14.

As of now, the issue has been resolved on the Mozilla Disclosures page.

All of these examples are TLS roots not listed in an audit, but I do not see why the same rules wouldn't apply here, especially when you can likely get an updated audit report that covers these cross-certs from the effective date of the SMIME BRs to today.

Internal evaluation suggests that re-signing the cross certificate would result in a NotBefore date later than that of the SubCA certificate, and we are unable to assess whether this might affect any relying party software during certificate chain validation.
This isn't a good reason. The cross certs need an audit or need to be on OneCRL.

This was the main reason we decided not to reissue the certificate.
We were uncertain whether any software would validate the NTB relationship between the issuer and the subordinate certificate, and whether having the issuer's NTB date later than that of the subordinate certificate might cause validation failures.

The previous generation multi-purpose RCA is approaching sunset, so the cross certificate without EKU will not exist for long.
Yet it still exists today. That's not a good reason to not revoke a non-compliant cert.

This cross-certificate is not non-compliant.
As stated in Contributing Factor 3, the BR at that time did not mandate the presence of an EKU field in cross-certificates.

We hope these responses have cleared up your concerns.

Comment 13

[chtsai]

Report Closure Summary

• Incident description:
  The TWCA CYBER Root CA is not included within the scope of the S/MIME audit report.

• Incident Root Cause(s):

  • There is a gap between our understanding of certificate issuance capabilities and that of the community. Even a self-signed root certificate meant only for TLS should still be reviewed together with its cross certificate that uses the same key.
  • Since the cross certificate does not restrict its usage via the EKU field, the self-signed root certificate must be considered capable of issuing S/MIME certificates, even if it does not have the email trust bit.

• Remediation description:

  • We have included the TWCA CYBER Root CA in the latest S/MIME audit report. In addition, following the same logic, we have revised and re-signed the other relevant audit reports accordingly.
  • All updated reports were uploaded to CCADB on March 14.

• Commitment summary:

  • In addition to complying with the relevant standards, we also listen carefully to the community’s suggestions and concerns.
  • We are committed to applying stricter scrutiny to the scope of future audit reports.
  • From now on, all new cross certificates will have the EKU field, following the current BRs.

All Action Items disclosed in this report have been completed as described, and we request its closure.

Comment 14

[chtsai]

We are continuously monitoring this incident and request closure.

Comment 15

[incident-reporting]

This is a final call for comments or questions on this Incident Report.

Otherwise, it will be closed on approximately 2025-05-23.