Approval of Taiwan CA's Root Inclusion Request

[Ben Wilson]

Greetings,

Public discussion regarding inclusion of the TWCA CYBER Root CA (websites trust bit with EV) and the TWCA Global Root CA G2 (email trust bit) began on the CCADB Public List on April 22, 2024 (https://groups.google.com/a/ccadb.org/g/public/c/rAsxoNILZ6A/m/vqn7iTHEAwAJ) and concluded recently (https://groups.google.com/a/ccadb.org/g/public/c/rAsxoNILZ6A/m/eapyrQcjBgAJ).

 

Additional details concerning this request may be found in the above-referenced discussions, in Bugzilla #1849702, and in CCADB Case Number 00001244.

The inclusion process is outlined here: https://wiki.mozilla.org/CA/Application_Process#Process_Overview. Additional information about application review may be found here: https://wiki.mozilla.org/CA/Application_Verification.

This is Mozilla's notice of intent to approve Taiwan CA’s root inclusion request.

 

This begins a 7-day “last call” period for any final objections.

Thanks,

Ben

[Amir Omidi (aaomidi)]

TWCA has a couple of incidents open for revocation delays. I think until this CA can show that it can follow its own CP/CPS and BRs, new trust anchors from that CA should not be accepted into the Mozilla Trust Store. Beyond that looking at the document linked here: https://www.twca.com.tw/upload/saveArea/filePage/20240313/05926332a5cb42bbb70bc7a0c841dff4/05926332a5cb42bbb70bc7a0c841dff4.pdf in section 4.9.2, they seem to not actually include non-subscribers as entities that can request revocation. For example, if some subscriber manages to issue a certificate for a domain I own, and I decide to get that revoked, under this document it doesn't seem like I have the authority to do that.

My objection is that while the CA is showing that they're comfortable ignoring the BRs, they should not be permitted to have additional roots join the trust store. Specifically, on this incident: https://bugzilla.mozilla.org/show_bug.cgi?id=1886110 0 they didn't even understand what revocation actually entails.

I'll go even further that Mozilla should consider a motion of distrust on this CA rather than extending trust to them even further than it already has - but that is a discussion for another thread.

[Matt Palmer]

On Tue, Jun 04, 2024 at 04:31:15PM -0700, 'Amir Omidi (aaomidi)' via dev-secur...@mozilla.org wrote:
> TWCA has a couple of incidents open for revocation delays. I think until
> this CA can show that it can follow its own CP/CPS and BRs, new trust
> anchors from that CA should not be accepted into the Mozilla Trust Store.

This exchange (in
https://bugzilla.mozilla.org/show_bug.cgi?id=1884568#c10) gives me reason
for concern:

> > Can you share how customers are being advised to explore alternate
> > methods to certificate pinning and what those methods might be?
>
> We currently suggest three possible methods:
> 1. Binding the public key instead of the certificate fingerprint.

This will work really great, right up until the point that the key gets
compromised... is it expected that a two-week delay in revocation for a
compromised private key is reasonable, just because the certificate is
pinned in a banking app?

The only answer to "how should we pin WebPKI certs?" that is in any way
defensible is "DON'T". If you want/need to pin, then don't do it with
WebPKI certs -- or, heck, don't use certs at all. If you've got an
out-of-band mechanism for determining trust in a given bunch of secret
bytes, X.509 isn't buying you anything except a widely-supported public
key delivery mechanism.

I'd personally like to see Mozilla strongly and actively discourage
certificate pinning, as it is a dangerous practice that is, quite
clearly, detrimental to the security of the WebPKI (it seems to be the
de rigeur plausible-looking excuse for CAs delaying revocation). As a
bonus, maintenance of private PKIs for those organisations for whom
pinning is deemed a security benefit can be a lucrative source of income
for CAs.

Seems like a win-win to me!

Also, from that same bug:

> 1 is used for communication with Financial Information Service Co.,
> Ltd. (FISC, the national interbank processing center) and requires
> system update on FISC side.

Using a WebPKI certificate for client authentication seems...
particularly unwise. I know I'm not going to get it, but I'd *really*
like to hear what the rationale for doing that was.

- Matt

[Hao-Chun Li]

Hi Amir,

Although we are dedicated to complying with the BRs, unfortunately, incidents of BR violations have still occurred. I believe this community understands that incidents can happen with any CA, but what truly matters is the CA's attitude towards addressing the problems and working to resolve their root causes. Over the past three months, we have made every effort to disclose these incidents with maximum transparency and promptness. We have followed Mozilla and CCADB requirements in writing incident reports and have responded to community questions in a timely manner. Additionally, we have conducted thorough internal reviews and implemented numerous technical and administrative preventive measures. Although the process may not have been perfect, I believe we have not ignored the existence of the BRs.

Regarding your concern about CPS section 4.9.2, according to your example, if the domain owner and the subscriber are different individuals, our CPS states, "If anyone other than the above-mentioned persons suspects that the certificate key has been compromised or other security matters,..." You still have the right to request revocation.

In [comment 26 of Bug 1886110](https://bugzilla.mozilla.org/show_bug.cgi?id=1886110#c26), we have detailed the timeline for certificate status publication. We also understand that according to BR 4.9.5, the time frame for the revocation process is considered complete only when it is published. In the future, when encountering similar urgent situations, we will activate the forced publication feature rather than relying on scheduled routine operations.

Thank you for your feedback.

Hao-Chun Li
TWCA

2024年6月5日水曜日 7:31:15 UTC+8 Amir Omidi (aaomidi):

[Hao-Chun Li]

Hi Matt,

Our replies are inline below.

2024年6月5日水曜日 8:57:16 UTC+8 Matt Palmer:

You are correct. Currently, we do offer private PKI for certain ecosystems. However, in some situations, the same site not only provides browser connections for users but also supports connections from other applications, including webview connections within apps. Therefore, subscribers have a reason to use public PKI. Of course, if clients could segment their website architecture into domains for public and private applications, this might resolve the issue. Additionally, most of the pinning cases we encounter are in the banking industry and the local banking regulations require certificate pinning for mobile banking apps.

  

Also, from that same bug:

> 1 is used for communication with Financial Information Service Co.,
> Ltd. (FISC, the national interbank processing center) and requires
> system update on FISC side.

Using a WebPKI certificate for client authentication seems...
particularly unwise. I know I'm not going to get it, but I'd *really*
like to hear what the rationale for doing that was.

 

In FISC's application, the issue is not related to client authentication but actually similar to the aforementioned certificate pinning. FISC connects to surrounding banks, so when a bank's certificate is updated, FISC also needs to update its whitelist.

 

- Matt

 

Thanks,

Hao-Chun Li

TWCA