Summary

  • A 2 November individual Internet-Draft proposes three EST operations for attested credential enrollment and retrieval. The EST client and server carry the traffic; they may neither judge the evidence nor authorize a key.
  • Fresh issuance belongs to a Credential Authority after proof-of-possession and attestation checks. Release of an existing bundle belongs to a Secret Vault whose policy determines the permitted credential group.

An enrollment server sees the request, handles the route and returns the answer. That is enough proximity to make it look like the bouncer. The new EST attestation draft writes the bouncer out of the job. An EST client or server can carry public key material, evidence, certificate requests, freshness handles and encrypted replies between the parties. It must not manufacture keys, evidence or certificate requests, appraise an attestation result or authorize credential issuance or release. The document says even matching a freshness handle to an earlier request is bookkeeping, not permission.

The proposed system has two doors. At the first, a workload asks for a new credential. It generates its own signing key and certificate signing request, binds attestation evidence to them, and sends both through EST. A Verifier evaluates the evidence. A Credential Authority checks proof that the workload holds the request’s private key and applies its own issuance policy to the attestation result. Only then does a fresh credential return through the server. The server transports the answer; it does not decide who deserves one.

At the second door, the workload asks for a credential bundle that already exists. It makes a Credential Encryption Key and places the public half in the evidence. The Secret Vault, acting on the Verifier’s result and its own policy, chooses a credential group and seals the matching bundle to that public key. The EST intermediaries must treat the sealed container as opaque. The workload checks that the reply names its target, freshness value and credential hint before opening it. A hint may help the vault select among permitted credentials; it cannot widen the set.

That distinction has a cost worth putting on the bill. The draft says shared credentials remove per-instance attribution. A vault can efficiently equip replicas, but a later signature made with one shared key will not identify which replica used it. The text points to per-instance keys with common identity claims or a central signing service when attribution is required. A fast distribution design therefore shifts the audit problem; it does not make it disappear.

The IETF record identifies this as an individual draft, intended for discussion and implementation experience. It supplies example exchanges, not an independently tested deployment. The decisive evidence would be an interoperable trial that rejects a server’s attempted policy shortcut, a mismatched evidence-to-key binding and a credential hint outside the vault’s allowed set. For now, the proposal has drawn a useful line on the counter: the messenger may carry the key request, but the issuer or vault must make the call.