Summary

  • A 28 October individual draft gives attested TLS two identity paths: a key vouched for by attestation, or that key plus a PKI certificate carrying a workload identifier.
  • Identical measurements identify a workload type, not a particular running instance. The draft puts the final identity-and-measurement authorization decision with the relying party.

Two identical confidential workloads walk up to a TLS gate. Their measurements say the same thing about the software they run. If the gate only needs any approved copy, that is enough. If it must reach the copy that received a particular task or secret, the measurement has lost the name tag.

That is the choice in Tirumaleswar Reddy and colleagues' new draft. It is an individual proposal for the SEAT discussion, with no selected working-group solution. The document first separates a measured type from a running instance, then offers two ways to distinguish one instance from its twin.

The first gives the workload a key made inside its attested environment. The public key travels in the attestation Evidence and appears again in the TLS handshake, as a raw public key or a self-signed certificate. The attestation key vouches for the association. There is no certification authority and no separate durable workload name. A peer can recognize this attested key for the connection, but a rotated key does not, by itself, tell the peer that yesterday's instance has returned.

The second path adds an identity issuer. A proposed WIMSE workload certificate binds a workload identifier to the key; the attestation Evidence carries that same key. The certificate's name can persist through key rotation. WIMSE lets an issuer name one instance or a logical workload shared by several; a certificate is no automatic answer to "which twin?" That convenience installs a new authority in the story: the issuer chooses the name's scope, while the relying party decides whether the named workload belongs in the measured environment presented today.

The last check is where the tidy diagram can lie. A certificate may be valid and the measured environment may be genuine, yet the image can be the wrong one for that workload identity. The draft says the relying party must appraise the name and measurements together when that pairing matters. Its key-provenance section adds another sharp edge: matching public keys and a valid proof of possession alone cannot show where the private key was generated or whether it can leave the protected environment.

RFC 9334 already assigns Evidence appraisal and the eventual action to distinct roles. The new draft exposes the decision hidden between them. Which copy is this, who named it, and did the named copy arrive in an approved form? The SEAT discussion still has to choose whether a specific instance needs a durable name at all.