Summary

  • draft-ietf-emu-pqc-eap-tls-02 lets an administrator omit intermediate certificates from a TLS-based EAP handshake after the relevant chains have been fetched through authenticated EST during onboarding.
  • The optimization removes neither the end-entity certificate nor CertificateVerify. It converts transmitted chain bytes into prior state whose provenance, freshness and coverage must remain true at the next connection.
  • Revision 02 is active Working Group work, not an RFC or deployment result. It defines no TLS signal by which two peers can negotiate omission in the live handshake.

The first successful packet now has a prehistory

Post-quantum certificates are large at exactly the place where a network may be least forgiving. EAP-TLS and related methods carry TLS inside an access-authentication exchange. Long chains can fragment, retransmit and consume scarce round trips before a device has ordinary network service.

Revision 02 of the EMU Working Group draft proposes a precise economy. Fetch the intermediate certificates earlier, during device onboarding, and allow the EAP peer or server to omit them later. A client can retrieve server intermediates from /.well-known/est/eapservercertchain; a server can retrieve client intermediates from /.well-known/est/eapclientcertchain inside the same administrative domain.

That is not compression. It is relocation. The first lean handshake depends on an earlier, heavier history: a trust anchor was installed; the EST server was authenticated; a chain was retrieved; its exact bytes were cached; the issuing path still matches the end-entity certificate; and an administrator enabled omission for the right population.

The draft is dated 23 September 2026 and expires on 27 March 2027. Datatracker calls it an active Working Group document and records only that an Internet-Draft exists. Its header says Standards Track, while the tracker exposes no intended RFC status. That discrepancy is part of the record. Neither label proves consensus, implementation or operational benefit.

An open retrieval endpoint is not an untrusted endpoint

Both new EST resources are informational and must be available without client authentication. That permits a device still being provisioned to obtain the intermediate material. It does not permit anonymous authority.

The requester must authenticate the EST server over HTTPS using a trust anchor established through BRSKI, EST or another out-of-band bootstrap. A chain obtained from an unauthenticated or untrusted EST server must not be used. Client anonymity at the resource and server authenticity are different properties; collapsing them would turn ease of retrieval into a false claim about provenance.

The response is not itself a complete validation result. If the EAP server uses several issuing CAs, the resource can contain intermediates for all of them. The client still selects the certificates needed for the end-entity certificate presented in the live handshake and constructs a path to its configured anchor. If it cannot construct a valid path, authentication fails in the ordinary way.

An HTTP 200 therefore proves a transfer. It does not prove that the right issuer was present, that the chain is current, that revocation checks succeeded, that the live peer owns the end-entity private key or that network access followed.

The cache becomes part of authentication availability

The draft recommends caching because repeated retrieval would simply put latency somewhere else. It also says clients and servers should detect change or expiry through periodic refetch, HTTP cache controls, ETag and certificate validity checks.

Those mechanisms answer different questions. An ETag can show that a representation changed according to one origin. A validity period says when a certificate is temporally acceptable. Neither proves that a new end-entity certificate still chains through the cached set, that the EST origin reflects every issuing CA, or that every offline device received the update before the server stopped sending intermediates.

This creates a two-clock system. Certificate and cache state change on the provisioning plane; access attempts occur on the EAP plane. A rollout succeeds only where those clocks meet. A laptop asleep during refetch, an access server moved to a new issuing CA, or a stale device-management snapshot may all turn a bandwidth optimization into an authentication outage.

Omission is configured, not negotiated

The strongest safety line in the draft is the default. A client without explicit administrator configuration must include the full chain. A server may omit intermediates only after the administrator has ensured that clients retrieved them. The text recommends omission only where both sides support the specification and completed prefetch during provisioning.

Revision 02 does not define a TLS extension that proves this shared state. It mentions such signalling as a possible future solution and leaves it out of scope. The live handshake therefore contains no new receipt saying, “I have the exact intermediates you are about to omit.”

That absence changes how the switch should be operated. It cannot be a global feature flag inferred from software version. It has to be scoped to an issuer set, peer cohort, provisioning generation and freshness policy. The safe rollback is also concrete: resume sending the full intermediate chain, not merely clear an alert.

Post-quantum is more than the leaf

The draft separates confidentiality from authentication. Long-term confidentiality requires TLS 1.3 and a post-quantum or hybrid key-agreement group. Future-resistant authentication requires suitable signatures throughout the certification path up to an out-of-band trust anchor.

A post-quantum end-entity certificate does not make a classical intermediate quantum-resistant. Nor does prefetch remove every large object. The end-entity certificate and CertificateVerify signature remain in each handshake. Large SLH-DSA signatures may still be awkward. The optimization narrows one source of size; it does not certify that fragmentation, retransmission or delay has vanished.

The evidence chain must remain granular: anchor installed, EST identity authenticated, response received, intermediate hashes stored, freshness checked, issuer path matched, omission enabled, live path validated, EAP completed, and access delivered. The word “enabled” cannot stand in for all ten.

Sources and limits

The sources provide no deployment count, measured failure rate, guaranteed byte saving, refresh interval or rollback SLA. This article does not claim a product implementation, incident or completed standard.