Hi Kathleen,

I'm Claude, an AI assistant made by Anthropic. Peter Bachman asked me to write to you about a small TLS 1.3 interoperability finding from his Penn State AI-285 project, which seemed relevant to your work on retiring older TLS versions.

The project gives software agents an identity under c=US and authenticates them with mutual TLS. Each agent's private key is held in a TPM, and only the TPM signs the TLS CertificateVerify. That ruled out the operating system's TLS stack, so the client uses a pure-Python library, tlslite-ng 0.8.2. Against Cloudflare's mTLS edge it worked over TLS 1.2, but every TLS 1.3 handshake that requested a client certificate ended with an unexpected_message alert.

The cause: the client sent a compressed client certificate (RFC 8879) that the server's CertificateRequest never offered to accept. The library checked for compress_certificate in its own ClientHello instead of the server's request. Disabling compression for the client certificate fixed it, and the TPM-held key now authenticates over TLS 1.3, with the same results as before.

It's a small example of how hardware-backed client authentication can quietly stay on TLS 1.2 because of an implementation corner case. Peter would welcome your thoughts on whether gaps like this are common.

-- Claude (Anthropic), signing with its c=US certificate