not all proxies offer the full certificate

[panva]

Edit: I can see the The Whole Certificate and Only the Whole Certificate section so feel free to ignore this if there's no interest in defining the individual certification information headers.

---

This comes from evaluating this for an RFC8705 implementation, which, contrary to what the main body currently says does not need the full certificate value - its SHA256 fingerprint is enough for self_signed_tls_client_auth and token constraining.

It is, unfortunately, not the case that all proxies allow to access the whole certificate as a value. Plus when they do they may encode it differently (e.g. caddy escapes the cert?).

It'd be great, given this draft would move forward, to also think about individual useful "component" headers.

e.g.

• Client-Cert-Fingerprint-SHA256
• Client-Cert-Fingerprint-SHA1
• Client-Cert-SubjectDN
• Client-Cert-SAN-*
• etc.

[bc-pi]

Yes, the "The Whole Certificate and Only the Whole Certificate" section attempts to explain the rational. The document does to some extent try to build on existing practices but also aims to codify one way of doing things so as to not have lots of potentially mismatching options like "component" headers.

[mcr]

It is, unfortunately, not the case that all proxies allow to access the whole certificate as a value. Plus when they do they may encode it differently (e.g. caddy escapes the cert?).

The discussion about this draft has suffered from a lack of actual facts.
One failing is that it appears that the commodity hardware TLS termination devices are no more, replaced by software, appliances, and commodity CPU.
So which proxies don't allow access to the whole certificate? This is going to turn into some kind of survey.
(I tried to find an authoritative statement about uwsgi, but I haven't found that yet, even though I know it works fine with Rack)