Open Bug 1952639 Opened 11 days ago Updated 2 days ago

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

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
ASSIGNED

People

(Reporter: chtsai, Assigned: chtsai)

Details

(Whiteboard: [ca-compliance] [audit-failure])

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.

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.

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

Flags: needinfo?(bwilson)
Assignee: nobody → chtsai
Status: UNCONFIRMED → ASSIGNED
Type: defect → task
Ever confirmed: true
Flags: needinfo?(bwilson)
Whiteboard: [ca-compliance] [audit-failure]

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

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.

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?

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.

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

(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?

You need to log in before you can comment on or make changes to this bug.