Hi Matt, Our replies are inline below.
2024年6月5日水曜日 8:57:16 UTC+8 Matt Palmer: On Tue, Jun 04, 2024 at 04:31:15PM -0700, 'Amir Omidi (aaomidi)' via [email protected] 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! 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 -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/2d90e900-24d7-46bb-8cd9-b9ae498f644fn%40mozilla.org.
