Missing or Inconsistent Disclosure of S/MIME BR Audits

[Rob Stradling]

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.

I recently added tracking to https://crt.sh/mozilla-disclosures to flag missing and inconsistent disclosures of S/MIME BR audits.  Since this crt.sh report is currently flagging issues for a number of CA Owners, I thought I would share a summary of the findings here.  In my view, most (if not all) of these issues should be treated as incidents per https://www.ccadb.org/cas/incident-report.

CA Owners with Missing S/MIME BR Audit details:

GoDaddy:

Several applicable Root Certificate records don’t specify any S/MIME BR audit details.  The WebTrust seals on https://certs.godaddy.com/repository do not include an S/MIME BR seal.  Has GoDaddy undergone an S/MIME BR audit?

TWCA:

No S/MIME BR audit details have been disclosed on one Root Certificate record.  This root CA isn’t directly trusted for S/MIME, but it counts as S/MIME-capable because it’s cross-certified by a root that is trusted for S/MIME.  Is ticking “Audits Same as Parent” the required resolution here?

DigitalSign - Certificadora Digital, S.A.:

Two root certificates have only the Email trust bit set in NSS, but the corresponding Root Certificate records in CCADB have no S/MIME BR audit details disclosed.  Has DigitalSign undergone an S/MIME BR audit?

eMudhra:

Two applicable Intermediate Certificate records don’t specify any S/MIME BR audit details.  Is ticking “Audits Same as Parent” the required resolution here?

Entrust:

Two applicable Root Certificate records don’t specify any S/MIME BR audit details.  Although these roots have been distrusted for further issuance of TLS server certificates, they are still fully trusted for the issuance of S/MIME certificates.  Has Entrust undergone an S/MIME BR audit?

Siemens (externally-operated Sub-CAs under Entrust):

Several applicable Intermediate Certificate records specify no S/MIME BR audit details.  Has Siemens undergone an S/MIME BR audit?

Ministerie van Defensie (externally-operated Sub-CA under PKIoverheid):

One applicable Intermediate Certificate record doesn’t specify any S/MIME BR audit details.  See also https://bugzilla.mozilla.org/show_bug.cgi?id=1911335.

LAWtrust:

One applicable Root Certificate record doesn’t specify any S/MIME BR audit details.  Has LAWtrust undergone an S/MIME BR audit?

Cybertrust Japan (externally-operated Sub-CA under SECOM Trust Systems):

One applicable Intermediate Certificate record doesn’t specify any S/MIME BR audit details.  See also https://bugzilla.mozilla.org/show_bug.cgi?id=1950574.

CA Owners with Inconsistent Disclosure of S/MIME BR Audit details:

Asseco Data Systems:

One applicable Root Certificate record doesn’t specify any S/MIME BR audit details.  Although this root certificate is not present in root stores, its signature can be validated by a doppelganger root that is.  (The serial number of this self-signed root certificate appears in the CRL, but I think it’s questionable as to whether self-signed certificates can actually be revoked in this manner.  This self-signed root certificate is also listed in OneCRL, but AIUI OneCRL is only applicable to Firefox’s use of TLS server certificate chains, meaning that it’s out of scope for Mozilla’s interest in S/MIME).

DigiCert:

Two applicable Root Certificate records don’t specify any S/MIME BR audit details.  These root CAs aren’t directly trusted for S/MIME, but they do inherit S/MIME-capability via cross-certification from other DigiCert roots.  (The CCADB records for the cross-certificates all specify “Audits Same as Parent”, and the corresponding parent records do specify S/MIME BR audit details).

Microsec:

Similar to the Asseco Data Systems case, a doppelganger Root Certificate record doesn’t specify any S/MIME BR audit details.

Cybertrust Japan (externally-operated Sub-CA under SECOM Trust Systems):

One applicable Intermediate Certificate record doesn’t specify any S/MIME BR audit details (see above), whereas a doppelganger Intermediate Certificate record does.  See also https://bugzilla.mozilla.org/show_bug.cgi?id=1950574.

Telia:

In two cases, the S/MIME BR audit Statement Date differs between a Root Certificate record and a corresponding Intermediate Certificate (cross-certificate) record.

apple-disclosures

I have also added tracking to https://crt.sh/apple-disclosures to flag missing and inconsistent disclosures of S/MIME BR audits.  This report currently flags issues for some additional CA Owners, but since crt.sh is not yet tracking all of the intricacies of Apple’s root store metadata there may be some false positives. 

--

Rob Stradling

Distinguished Engineer

Sectigo Limited

[Chya-Hung Tsai]

Hi Rob,

Thank you for providing a summary of the S/MIME BR Audit disclosure status. On behalf of TWCA, I would like to raise a few questions regarding the alerts on https://crt.sh/mozilla-disclosures:

1. [Root] TWCA CYBER Root CA is a TLS-only certificate hierarchy. In CCADB, the trust bits are only set for "website," but it appears as both "Server" and "Email" in the report. Could you clarify why?
2. Following the previous point, since this Root CA does not issue S/MIME certificates, it should not require an S/MIME Audit. Is this assumption correct?
3. [Root] TWCA Global Root CA G2 does not have TLS issuance capabilities. In CCADB, the trust bits are only set for "email," but it is displayed as both "Server" and "Email" in the report. Could you clarify why?
4. Following the previous point, since this Root CA does not issue TLS certificates, it should not require a BR or EV Audit. Is this assumption correct?
5. TWCA Global Root CA G2 has indeed cross-certified  by TWCA Global Root CA. The cross-certificate (D53BF4968A7DB3C8...) has "Audits Same as Parent" checked,. Could you confirm?
6. We have noticed warnings regarding CRL expiration, but after verifying the CRLs downloaded from the CDP, they all appear to be valid. Could you confirm?
7. We observed that in the Subject CN field, only TWCA includes the word "Root," while other CAs only list Intermediate CAs. Is this a coincidence, or does TWCA need to make any adjustments?

If we have misunderstood the information presented on the disclosure page or misinterpreted any CCADB attributes, please let us know. If this is confirmed as an incident, we will disclose it on Bugzilla following the latest CCADB incident reporting template.

Thank you.

Best regards,
ChyaHung Tsai
TWCA

Rob Stradling 在 2025年3月6日 星期四清晨5:03:38 [UTC+8] 的信中寫道：

[Ben Wilson]

Dear ChyaHung Tsai,

Could these alerts be due to the cross-signing of the roots by the TWCA Global Root CA?

In the CCADB, both of these roots also appear as subordinate CAs because they are signed by the TWCA Global Root CA (it doesn't matter that they are called "roots"), so they would inherit the trust of that root, which has both trust bits indicated. I think that might be the reasoning.

I'm not sure about the expiring CRL you mention.

Ben

[Chya-Hung Tsai]

Dear Ben,

Maybe our Cross‑Certified Subordinate CA Certificate (TWCA Global Root to TWCA CYBER Root) does not include an EKU, which causes the program to also identify TWCA CYBER Root as having the capability to issue S/MIME (inheriting the capabilities of TWCA Global Root)?

Additionally, our S/MIME audit report includes this Cross‑Certified Subordinate CA Certificate, but does not include the self‑signed TWCA CYBER Root, because that TWCA CYBER Root does not have the mail trust bit, and therefore the "Audits Same as Parent" flag does not apply. 

   

ChyaHung Tsai
TWCA

Ben Wilson 在 2025年3月6日 星期四上午10:45:39 [UTC+8] 的信中寫道：

[dr. Szőke Sándor]

Hi Rob,

 

thank you for your efforts to improve the security of the web PKI.

 

We have conducted a quick investigation into the reported S/MIME audit issue and believe we have found the possible root cause of the issue.

For the problematic "Microsec e-Szigno Root CA 2009" root, Microsec has a "working" root certificate that is included in several Root Programs.

For different reasons, two doppelganger certificates have been issued for this root, which are not active and are not directly trusted by any of the Root Programs.

These two doppelganger certificates have been added to CCADB as subordinate certificates under the "working" root CA certificate and the audits are marked "as parents".

Microsec has a total of 3 root certificates for this root entity, but there are 4 instances in CCADB, as shown in the following table.

We do not know how and why, but one of the doppelganger certificates has been added to CCADB as a separate root as well, and this may be the source of the problem.

 

Microsec e-Szigno Root CA 2009

SHA256 hash	Cert Serial Number	CCADB Unique ID	Included in CCADB as	Included in Root Programs
3C5F81FEA5FAB82C64BFA2EAECAFCDE8E077FC8620A7CAE537163DF36EDBF378	00C27E43044E473F19	A000164	root	included
8E8C6EBF77DC73DB3E38E93F4803E62B6B5933BEB51EE4152F68D7AA14426B31	00C27E43044E473F18	A010460	root	not included
8E8C6EBF77DC73DB3E38E93F4803E62B6B5933BEB51EE4152F68D7AA14426B31	00C27E43044E473F18	A004417	subordinate	same as parent
72F9AF2158181BAF16D60C9B4E6F4BD7CA8D2341AD48AFDB67CB4C8332D546F6	00E8849639AB66105A	A006945	subordinate	same as parent

 

 

We contact the CCADB operators and ask them what to do to solve this issue.

 

Kind Regards,

 

Sándor

 

Dr. Sándor SZŐKE

dep. Director of eIDAS Trust Services

 

 

Microsec Ltd.  |  Ángel Sanz Briz Road 13.

Budapest, H-1033 Hungary
Graphisoft Park Southern Area, Building SP3, 3th floor

T: +36 1 802-4418  |   +36 1 505-4477 / 488
sandor...@microsec.com

microsec.com

--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion visit https://groups.google.com/a/ccadb.org/d/msgid/public/MW4PR17MB47298BAE9940F13E86CB678BAACB2%40MW4PR17MB4729.namprd17.prod.outlook.com.

[Rob Stradling]

Hi ChyaHung Tsai.  Firstly, I'd like to commend TWCA for its prompt attention to this matter and for seeking to understand what needs to be addressed.

> Maybe our Cross‑Certified Subordinate CA Certificate (TWCA Global Root to TWCA CYBER Root) does not include an EKU, which causes the program to also identify TWCA CYBER Root as having the capability to issue S/MIME (inheriting the capabilities of TWCA Global Root)?

Yes, that's correct.

> Additionally, our S/MIME audit report includes this Cross‑Certified Subordinate CA Certificate, but does not include the self‑signed TWCA CYBER Root, because that TWCA CYBER Root does not have the mail trust bit, and therefore the "Audits Same as Parent" flag does not apply. 

MRSP 5.3 says "All certificates that are capable of being used to issue new certificates and that directly or transitively chain to a CA certificate included in Mozilla’s root store MUST be operated in accordance with this policy."

The self-signed TWCA CYBER Root certificate "chain[s] to a CA certificate included in Mozilla's root store" that has the Email trust bit enabled, and so it "MUST be operated in accordance with" the S/MIME provisions of the MRSP.

It's a suboptimal chain, but it is nonetheless a valid chain:

TWCA Global Root

  -> TWCA CYBER Root (cross-certificate)

    -> TWCA CYBER Root (self-signed certificate)

      -> Intermediate CA Certificate

        -> Leaf Certificate

> 6. We have noticed warnings regarding CRL expiration, but after verifying the CRLs downloaded from the CDP, they all appear to be valid. Could you confirm?

You're correct that unexpired CRLs are being returned in response to Unconditional GET requests.

Example:

$ wget -nv "http://RootCA.twca.com.tw/TWCARCA/cyber_root_revoke_2022.crl" -O /dev/stdout | openssl crl -inform der -lastupdate -nextupdate -noout

2025-03-06 14:43:17 URL:http://rootca.twca.com.tw/TWCARCA/cyber_root_revoke_2022.crl [719/719] -> "/dev/stdout" [1]

lastUpdate=Mar  6 09:00:00 2025 GMT

nextUpdate=Mar  7 08:59:59 2025 GMT

Expired CRLs are being flagged because TWCA's CRL server is responding incorrectly to the Conditional GET requests that crt.sh's crl_monitor sends.

Example:

$ wget -nv --header="If-Modified-Since: Wed, 30 Jun 2024 21:00:00 GMT" "http://RootCA.twca.com.tw/TWCARCA/cyber_root_revoke_2022.crl"

http://rootca.twca.com.tw/TWCARCA/cyber_root_revoke_2022.crl:

2025-03-06 14:38:40 ERROR 304: Not Modified.

---

From: Chya-Hung Tsai <ncku...@gmail.com>
Sent: 06 March 2025 03:44
To: CCADB Public <pub...@ccadb.org>
Cc: Ben Wilson <bwi...@mozilla.com>; ncku...@gmail.com <ncku...@gmail.com>; Rob Stradling <r...@sectigo.com>
Subject: Re: Missing or Inconsistent Disclosure of S/MIME BR Audits

 

This Message Is From an Untrusted Sender

You have not previously corresponded with this sender.

Report Suspicious

 

[Rob Stradling]

Hi Dr. Sándor.

> thank you for your efforts to improve the security of the web PKI.

You're welcome!  Thank you for your prompt attention and investigation into this matter.

> We do not know how and why, but one of the doppelganger certificates has been added to CCADB as a separate root as well, and this may be the source of the problem.

It looks like the doppelganger root certificate was previously present in the Microsoft root store, since the "Microsoft Status" on https://ccadb.my.site.com/0018Z00002iKhM2QAK is "Removed".  This is presumably why a Root Certificate record for this certificate exists in CCADB.

> We contact the CCADB operators and ask them what to do to solve this issue.

Good move.

(I'm guessing the solution will be to (1) populate the S/MIME BR audit details in the Root Certificate record and (2) remove the Intermediate Certificate record; but let's wait and see if the CCADB operators agree or have a different preference).

---

From: pub...@ccadb.org <pub...@ccadb.org> on behalf of dr. Szőke Sándor <szoke....@microsec.hu>
Sent: 06 March 2025 12:02
To: Rob Stradling <r...@sectigo.com>
Cc: 'CCADB Public' <pub...@ccadb.org>
Subject: RE: Missing or Inconsistent Disclosure of S/MIME BR Audits

 

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

To view this discussion visit https://groups.google.com/a/ccadb.org/d/msgid/public/!%26!AAAAAAAAAAAuAAAAAAAAADQphbWDqFVAuLX8xgdsj74BAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAACI7VDwreqhT5TEHKoQW28nAQAAAAA%3D%40microsec.hu.

[Michael Lettona]

Hi Rob,

These 2 roots are covered by our S/MIME audit.  However, these are single purpose roots and CCADB's ALV will fail because it won't take an audit report for S/MIME for a CA that does not have the Email trust bit set. We suspect that as others transition to single purpose and cross-sign with their older multi-purpose roots they will see similar issues, so we've filed this https://bugzilla.mozilla.org/show_bug.cgi?id=1952383 today and are waiting for guidance from the browsers on how to proceed.

[Chya-Hung Tsai]

Hi Rob,

We agree that the TWCA CYBER Root (self-signed certificate) meets the definition of "directly or transitively chain" as described in MRSP 5.3. However, we believe that according to MRSP 1.1, Root CAs and Intermediate CAs should be defined separately, while MRSP 5.3 specifically applies to Intermediate CAs.

For example, MRSP 5.3 requires that Intermediate CAs must include an EKU, which is impossible for a Root CA to satisfy, as Root CAs do not contain an EKU field. Similarly, both the BRs and the CCADB Policy define Root CAs and Intermediate CAs separately, with different profile requirements for each.

For instance, our TWCA CYBER Root has an Intermediate CA that chains up to TWCA Global Root, but we do not include it in our S/MIME audit report, as it contains an EKU field but does not include emailProtection. Since Root CAs cannot contain an EKU field, we believe that the trust bit should determine whether a CA is included in the audit scope (including both currently trusted CAs and those under application for inclusion).

Including TWCA CYBER Root (self-signed certificate) in the S/MIME audit report would be highly inappropriate, as it is already designated as a single-purpose TLS hierarchy. If a Root CA is considered a subordinate CA of a cross-certificate, then that Root CA would no longer be a single-purpose TLS hierarchy.

We request clarification from Mozilla or CCADB on the following matter:
Should a self-signed certificate registered as a Root CA in CCADB have its audit scope determined by the trust bit, rather than being required to meet the Intermediate CA requirements?

Best regards,

ChyaHung Tsai

TWCA

Rob Stradling 在 2025年3月6日 星期四晚上11:16:41 [UTC+8] 的信中寫道：

[dr. Szőke Sándor]

Hi Rob,

 

we sent an email to CCADB operator yesterday, and we opened an incident ticket in Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1952519

 

I feel that the management of doppelganger root certificates is problematic in CCADB, it would be useful to develop clear rules for this.

 

Kind Regards,

 

Sándor

[Rob Stradling]

> Should a self-signed certificate registered as a Root CA in CCADB have its audit scope determined by the trust bit, rather than being required to meet the Intermediate CA requirements?

In my view this comment from Ryan Sleevi is relevant to this discussion.  The comment addresses a slightly different scenario, but I interpret it as supporting the crt.sh logic that is flagging the TWCA CYBER Root CA (self-signed certificate) in https://crt.sh/mozilla-disclosures#disclosureincomplete.

---

From: Chya-Hung Tsai <ncku...@gmail.com>
Sent: 07 March 2025 03:07
To: CCADB Public <pub...@ccadb.org>
Cc: Rob Stradling <r...@sectigo.com>; Ben Wilson <bwi...@mozilla.com>; Chya-Hung Tsai <ncku...@gmail.com>

[Bruce Morton]

On Wednesday, March 5, 2025 at 4:03:38 PM UTC-5 Rob Stradling wrote:

Entrust:

Two applicable Root Certificate records don’t specify any S/MIME BR audit details.  Although these roots have been distrusted for further issuance of TLS server certificates, they are still fully trusted for the issuance of S/MIME certificates.  Has Entrust undergone an S/MIME BR audit?

Yes, Entrust has undergone an S/MIME BR audit https://www.entrust.com/sites/default/files/documentation/licensingandagreements/ecs/entrust-webtrust-for-smime-baseline-requirements.pdf. We have posted the following incident to track progress to correct the missing disclosure of S/MIME BR Audits, https://bugzilla.mozilla.org/show_bug.cgi?id=1952635.    

Siemens (externally-operated Sub-CAs under Entrust):

Several applicable Intermediate Certificate records specify no S/MIME BR audit details.  Has Siemens undergone an S/MIME BR audit?

Yes, the Siemens CA have undergone S/MIME BR audit in 2024 see https://www.dqsglobal.com/de-de/kunden-datenbank/siemens-ag36#. The CAs have also completed an audit in 2025. The report has not been received, but is due by 31 March 2025. CCADB will be updated after the audit report is posted.

We believe the CCADB issue is that the CAs in question are issued from a Technically Constrained CA, where the CA certificate is reissued on an annual basis, and the previous certificate is then revoked. In CCADB, we change the CA hierarchy to point to the most recent Technically Constrained CA  certificate, which unfortunately is not included in the audit report. This breaks the AVI test. The test should pass after the new compliance report is referenced in CCADB.

 

[Ben Wilson]

Hi Rob,

Could you copy-and-paste Ryan Sleevi's comments here?  It seems I'm having difficulties accessing them.

Thanks,

Ben

[Brittany Randall]

Hi Rob,

Thank you for sharing! To answer your question - GoDaddy has not undergone an S/MIME BR audit. We initiated contact with Chrome, Mozilla, Microsoft, and Apple root stores via root store program emails in November 2024 and subsequently filed a Bugzilla item: https://bugzilla.mozilla.org/show_bug.cgi?id=1943135 to have the S/MIME trust bits removed for these roots since there are no plans to issue those type of certificates receiving trust from these roots. 

Thanks,

Brittany Randall

GoDaddy

---

From: 'Rob Stradling' via CCADB Public <pub...@ccadb.org>

Sent: Wednesday, March 5, 2025 2:03 PM
To: CCADB Public <pub...@ccadb.org>
Subject: Missing or Inconsistent Disclosure of S/MIME BR Audits

 

This Message Is From an External Sender

This message came from outside your organization.

 

[Rob Stradling]

> Could you copy-and-paste Ryan Sleevi's comments here?  It seems I'm having difficulties accessing them.

The link I posted previously (https://www.mail-archive.com/dev-secur...@mozilla.org/msg00293.html) is working for me right now.

The same message is also available at https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/VDlemooJg5U/m/Hikd7TgFAgAJ.

Here's the main paragraph of interest, which talks about doppelgangers being "in scope" and describes "disclosure" to CCADB as just one "example" of what being "in scope" means in practice:

'Note that, in tools like CCADB and crt.sh, there's been an understanding that both A and A', because they share (Key, DN), are considered "in-scope". For example, disclosure is required for these certificates; if A' is encountered in CT, for example, and not disclosed in CCADB (at minimum, as an intermediate of A), then it's been treated as a failure to disclose and a violation of policy. This is what I mean when I say that doppelgangers have been considered in scope. Section 5.3 of Mozilla's policy makes this very explicit, in the discussion of "directly or transitively chain to a CA certificate", by defining the technical properties that apply here, and Section 5.3.2 applies the audit and disclosure requirement.'

Let's also not forget that the MRSP is not the only root store policy that CA Owners need to consider.  The Apple Root Certificate Program Policy (https://www.apple.com/certificateauthority/ca_program.html) says:

"Effective December 1, 2024, CA providers must ensure their S/MIME enabled root CAs and all subordinate CAs capable of issuing S/MIME certificates have been and will continue to be audited against the current version of at least one of the below sets of criteria at least annually:

• (Preferred) "WebTrust Principles and Criteria for Certification Authorities" and "WebTrust Principles and Criteria for Certification Authorities – S/MIME"
• (Accepted on a case-by-case basis) "ETSI TS 119 411-6" LCP, NCP, or NCP+"

In my view, when a root certificate is trusted for S/MIME by the Apple root store, its (untrusted) doppelganger root certificate is "enabled" for S/MIME (and so must be covered by a BR S/MIME audit) due to what Ryan described as a "self-loop":

"The distinction here is that doppelgangers for CA certificates also serve as self-loops between these (Key, DN) tuples. If you have Cert A (using Key 1, Issuer DN == Subject DN == DN Foo), and Cert A' (using Key 1, Issuer DN == Subject DN == DN Foo), then we can say that A issued A', and A' issued A. If we're imagining these as vertices and edges, then for A and A', there are two edges between the vertex (Key, DN) - the first edge is a self-loop A, the second edge is a self-loop A'.

When it comes to building paths to the vertex (Key, DN), then we can build a path [A], [A'], [A, A'], and [A', A], while paths such as [A, A], [A', A'], [A, A', A], and [A', A, A'] are prohibited by X.509 (specifically, Section 10.1(a), at least in 08/2005).

This is explicitly called out in RFC 4158, Section 5.2 (and Section 2.4.2), when discussing paths that are valid in RFC 5280 (Section 6.1.3) but can otherwise cause suboptimal loops. From an RFC 5280 perspective, if we imagine a CA A, CA A' (as above), and EE B, then the possible valid paths here are [[A, B], [A', B], [A', A, B], [A, A', B]]."

---

From: Ben Wilson <bwi...@mozilla.com>

Sent: 10 March 2025 18:03

To: Rob Stradling <r...@sectigo.com>
Cc: Chya-Hung Tsai <ncku...@gmail.com>; CCADB Public <pub...@ccadb.org>

Subject: Re: Missing or Inconsistent Disclosure of S/MIME BR Audits

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious