Channel binding interop across QUIC stacks (§6.1)

[arkstack-dev]

§6.1 binds SCRAM-SHA-256-PLUS channel binding material to the end-entity certificate from the QUIC TLS 1.3 handshake.

For implementers: does your QUIC library of choice (quinn, msquic, quiche, ngtcp2, lsquic, picoquic, s2n-quic, Java's incoming QUIC support, anything else) expose the negotiated end-entity certificate to application code in a way that matches the API a SCRAM client expects?

If not — where's the gap, and is it fixable at the library level or does the spec need to accommodate it?

[arkstack-dev]

Adding some structure to this since it's the §6.1 question I'm least sure about. Here's what I think is true per stack — corrections welcome, especially from anyone who's implemented SCRAM PLUS against these:

• OpenSSL-based (quiche, ngtcp2+OpenSSL, lsquic): leaf cert reachable via the usual SSL_get_peer_certificate-style surface, so tls-server-end-point should compute identically to TCP+TLS today. Low risk.
• BoringSSL-based (Chromium QUIC, some quiche builds): API differs, but the DER bytes of the leaf cert should be obtainable. The hash input has to be byte-identical to the OpenSSL path or PLUS auth breaks across implementations.
• Rust-native (rustls under quinn / s2n-quic): rustls exposes peer certs, but I haven't verified the DER encoding matches what an OpenSSL server presents byte-for-byte.
• JVM: JEP 517 (JDK 26) exposes QUIC only as HTTP/3 transport, no standalone QUIC API. Unclear whether a v3-over-QUIC client on the JVM can reach the leaf cert without dropping to a non-JDK stack (Netty etc.).

Two questions beyond "does the cert reach app code":

• Is the hash input unambiguous across stacks? RFC 5929 says the cert in DER, but is "the leaf the server sent" byte-identical everywhere, or subject to re-encoding somewhere in the chain?
• Should the spec lean on tls-exporter (RFC 9266) instead of, or alongside, tls-server-end-point? TLS 1.3 exporters are arguably a cleaner fit for QUIC than cert hashing. v0.1 leaves tls-exporter optional — I'm starting to think that might be backwards.