Hi Rob, Could you copy-and-paste Ryan Sleevi's comments here? It seems I'm having difficulties accessing them. Thanks, Ben
On Fri, Mar 7, 2025 at 12:31 PM Rob Stradling <[email protected]> wrote: > > 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 > <https://www.mail-archive.com/[email protected]/msg00293.html> > 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 <[email protected]> > *Sent:* 07 March 2025 03:07 > *To:* CCADB Public <[email protected]> > *Cc:* Rob Stradling <[email protected]>; Ben Wilson <[email protected]>; > Chya-Hung Tsai <[email protected]> > *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 > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/J5K_pWsD!CWYXECd0fYqSgVOq2XhdQ-9i-55jghkuB-DnQc-iQyvLGMFQKTfG2Vw3uTHxSXeAz4mjZ5MmwTwDx8QH1tt1qlJ_-lsx2dc$> > > 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] 的信中寫道： > > 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 > <https://urldefense.com/v3/__http://RootCA.twca.com.tw/TWCARCA/cyber_root_revoke_2022.crl__;!!J5K_pWsD!z3Fr2aGClqXaxeOCT3jrWZU43kzMh6-m1GAUa5-f-3sUaIl_WHUXRE7gg1wKf2Eax3aQP7O9LLxfhQ$>" > -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 > <https://urldefense.com/v3/__http://rootca.twca.com.tw/TWCARCA/cyber_root_revoke_2022.crl__;!!J5K_pWsD!z3Fr2aGClqXaxeOCT3jrWZU43kzMh6-m1GAUa5-f-3sUaIl_WHUXRE7gg1wKf2Eax3aQP7P8_QnvNA$> > [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 > <https://urldefense.com/v3/__http://RootCA.twca.com.tw/TWCARCA/cyber_root_revoke_2022.crl__;!!J5K_pWsD!z3Fr2aGClqXaxeOCT3jrWZU43kzMh6-m1GAUa5-f-3sUaIl_WHUXRE7gg1wKf2Eax3aQP7O9LLxfhQ$> > " > http://rootca.twca.com.tw/TWCARCA/cyber_root_revoke_2022.crl > <https://urldefense.com/v3/__http://rootca.twca.com.tw/TWCARCA/cyber_root_revoke_2022.crl__;!!J5K_pWsD!z3Fr2aGClqXaxeOCT3jrWZU43kzMh6-m1GAUa5-f-3sUaIl_WHUXRE7gg1wKf2Eax3aQP7P8_QnvNA$> > : > 2025-03-06 14:38:40 ERROR 304: Not Modified. > > ------------------------------ > *From:* Chya-Hung Tsai <[email protected]> > *Sent:* 06 March 2025 03:44 > *To:* CCADB Public <[email protected]> > *Cc:* Ben Wilson <[email protected]>; [email protected] < > [email protected]>; Rob Stradling <[email protected]> > *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 > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/J5K_pWsD!CWYdUWf1Haq5StOq2FiXQ9er4LR3Z6Nd0cyyezsSfdO1LdRl1XvBoIxL1YkLTksAZ7otboH0aCWqF-jGQpNwGkA6Z6_mUj8$> > > 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] 的信中寫道： > > 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 > > On Wednesday, March 5, 2025 at 6:30:51 PM UTC-7 [email protected] wrote: > > 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 > <https://urldefense.com/v3/__https://crt.sh/mozilla-disclosures__;!!J5K_pWsD!yasWOllrX91fE5MB_c22RVmjkVN3I1l_ArKr0Mj1LSpP3ggyCjbi89Rf1bnsQM1ch-O2oM39ojqOiw$> > : > > 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] 的信中寫道： > > 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 > <https://urldefense.com/v3/__https://crt.sh/mozilla-disclosures__;!!J5K_pWsD!yasWOllrX91fE5MB_c22RVmjkVN3I1l_ArKr0Mj1LSpP3ggyCjbi89Rf1bnsQM1ch-O2oM39ojqOiw$> > 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 > <https://urldefense.com/v3/__https://www.ccadb.org/cas/incident-report__;!!J5K_pWsD!yasWOllrX91fE5MB_c22RVmjkVN3I1l_ArKr0Mj1LSpP3ggyCjbi89Rf1bnsQM1ch-O2oM3ofm3a4Q$> > . > > *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 > <https://urldefense.com/v3/__https://certs.godaddy.com/repository__;!!J5K_pWsD!yasWOllrX91fE5MB_c22RVmjkVN3I1l_ArKr0Mj1LSpP3ggyCjbi89Rf1bnsQM1ch-O2oM1YytVqvg$> > 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 > <https://urldefense.com/v3/__https://bugzilla.mozilla.org/show_bug.cgi?id=1911335__;!!J5K_pWsD!yasWOllrX91fE5MB_c22RVmjkVN3I1l_ArKr0Mj1LSpP3ggyCjbi89Rf1bnsQM1ch-O2oM026d-DxA$> > . > > 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 > <https://urldefense.com/v3/__https://bugzilla.mozilla.org/show_bug.cgi?id=1950574__;!!J5K_pWsD!yasWOllrX91fE5MB_c22RVmjkVN3I1l_ArKr0Mj1LSpP3ggyCjbi89Rf1bnsQM1ch-O2oM1CjFi7NA$> > . > > *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 > <https://urldefense.com/v3/__https://bugzilla.mozilla.org/show_bug.cgi?id=1950574__;!!J5K_pWsD!yasWOllrX91fE5MB_c22RVmjkVN3I1l_ArKr0Mj1LSpP3ggyCjbi89Rf1bnsQM1ch-O2oM1CjFi7NA$> > . > > 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 > <https://urldefense.com/v3/__https://crt.sh/apple-disclosures__;!!J5K_pWsD!yasWOllrX91fE5MB_c22RVmjkVN3I1l_ArKr0Mj1LSpP3ggyCjbi89Rf1bnsQM1ch-O2oM2MBBqsOQ$> > 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 > > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaad%2BUcGLMA0x0Yy95zV3ee0nVnxBphcX_NgpAZBmYu6-Q%40mail.gmail.com.
