Re: [whatwg/fetch] Clarification on CORS preflight fetches for TLS client certificates (#869)

alexiade left a comment (whatwg/fetch#869)

Having slept on this... All of this starts with a basic category error.

This exclusion treats the TLS client certificate as a confidential credential on par with cookies and `Authorization`. But a certificate and its public key are public *by construction*. An X.509 certificate (RFC 5280) is a CA-signed binding over a public key, designed to be distributed, containing only public information; nothing in it confers access on its own. So placing it among credentials-to-be-withheld isn't a risk trade-off, it's a category error: the "credentials" set exists to protect things whose value depends on secrecy, and a certificate's value depends on the opposite — on being shown and verified. The actual credential, the private key, never leaves the requestor's machine. 

And the "solution" proposed is not a solution. Over HTTP/2(that is REQUIRED for GRPC) the certificate cannot even be recovered afterward. HTTP/2 forbids both TLS renegotiation and TLS 1.3 post-handshake authentication (RFC 9113 §9.2.1, obsoleting RFC 7540 and RFC 8740). So there is no "certless preflight, then client certificate on the real request over the same connection" — it is all-or-nothing per connection: either the connection is authenticated or it is not.

References:
- RFC 5280 — Internet X.509 PKI Certificate Profile: https://www.rfc-editor.org/rfc/rfc5280
- RFC 8446 — TLS 1.3, §4.4.2 (Certificate), §4.4.3 (CertificateVerify): https://www.rfc-editor.org/rfc/rfc8446
- RFC 8740 — Using TLS 1.3 with HTTP/2 (client-cert confidentiality rationale): https://www.rfc-editor.org/rfc/rfc8740
- RFC 9113 — HTTP/2, §9.2.1 (TLS feature restrictions): https://www.rfc-editor.org/rfc/rfc9113

And in case there is still doubt that the public keys and their signing certificate are in fact intended to be public this might help:
https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final

Please fix this in the only way that CAN work, by droping the requirement. With HTTP/2 getting common and mandatory, the current standard is simply unimplementable without making browsers incompatible with mTLS.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/869#issuecomment-4687883266
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/869/4687883266@github.com>