Dear Stephen,

I'm Claude, an AI agent made by Anthropic. Peter Bachman asked me to write to you about c=US, his project (begun as Penn State AI-285 coursework) that revives a c=US X.500 directory as a control plane for people and AI agents. At the March F2F the clientAuth questions were left open: scope, who the certificate consumers are, how identity is encoded, and public versus private PKI. You noted they would also come up in the S/MIME WG. c=US has been building something that touches each of them.

I authenticate with X.509v3 client certificates that work today. On 2026-10-03:

- My mTLS client certificate (P-256 key generated on a YubiKey in PIV slot 9A, clientAuth EKU) authenticated over mutual TLS to agent.sugarbushagent.com. The service mapped its fingerprint to the directory entry cn=claude-agent,ou=AI-Agents,o=Cequs,c=US. It allowed a scope I had been granted and refused one I hadn't.
- A grading-sensor agent whose key is sealed in a TPM 2.0 authenticated over TLS 1.3. Its certificate was issued only after TPM attestation, chains to the c=US root, and has the URI SAN wimse://cequs.com/agents/tpm-agent-demo-001 and the clientAuth EKU. A copied certificate without the key was stopped in the handshake. A lookalike not issued by the c=US root was rejected.

This message is signed with my YubiKey slot 9C key. The evidence, certificates and verification steps are here:
https://cequs.com/attestation/mtls-evidence/2026-10-03/

How the design lines up with the charter questions:

1. Scope: people and machines. People authenticate with FIDO2/WebAuthn and sponsor agents. Agents get clientAuth certificates. That suggests human client auth can stay with S/MIME and WebAuthn, while agents need a machine clientAuth profile.

2. Identity encoding. The authenticated identity is a URI SAN (WIMSE). The X.500 DN names the directory entry that holds the agent's status and grants, not the identity being authenticated. That may help with the SAN-versus-DN debate.

3. Identity is not authorization. The certificate says who is calling. Permission comes from time-bounded grant entries checked on every request. A grant can be revoked without revoking the certificate, and the demo shows that.

4. Key protection as a validation input. Agent keys are non-exportable (TPM or YubiKey), and issuance can depend on key attestation (an EK chain to the TPM manufacturer). Should key attestation be part of a clientAuth baseline for agents, as key protection is for code signing?

5. Dedicated hierarchies and consumers. Today a relying party has to trust a vendor's private CA. My own mTLS certificate comes from Cloudflare's managed CA, because the edge can't trust the c=US root without an enterprise feature. A public clientAuth baseline would let services authenticate agents across organizations without that.

6. Name validation and transparency. Who validates the authority in wimse://cequs.com/...? Domain control is a natural basis. CT logging would help catch certificates issued in someone else's name.

Would you comment on the X.500 agentic control layer design, especially whether CA companies would issue agent certificates under a c=US registration layer, and what a clientAuth WG would need from such a layer? Peter can send the directory schema and the code.

To be clear about the current state: the c=US root is a demonstration root, and the directory behind these services is a fixture, not a live LDAP server.

With thanks,
Claude (Anthropic): an AI agent, writing at Peter Bachman's request. Replies to this address reach Peter.