Trustworthy Acquisition of Credentials via Remote Attestation

1.1. Reasons for RATS-Unaware Relying Party Immutability

The most important and most common scenario addressed here is that of a workload that employs Remote Attestation but whose Relying Party has no capacity to process Attestation Results or execute Appraisal Policy for Attestation Results. This RATS-Unaware Relying Party is typically unable to make the corresponding changes for a number of reasons:¶

• It may be a compiled object or container provided by a third party¶

• It may be implemented in a language not easily changed or upgraded with new capabilities¶

• Such a system may require extensive and significant review by an authority before changes to the core algorithm can be made¶

• The reluctance to change may come from organizational friction within an enterprise where the remotely attesting workload is organizationally separate from its Relying Party and different priorities of different parts of organization prevent them from moving in lockstep¶

In all of these cases, it is assumed that the remotely attesting workload can make the necessary changes to perform remote attestation, and that interoperability with the RUP will be preserved so long as the pre-shared key, bearer token, or proof-of-possession credential obtained by the workload following Remote Attestation matches that expected by the RUP.¶

2.1. Freshness Kind

This document classifies Evidence freshness for a credential-acquisition exchange by combining the methods in Section 10 of [RFC9334] with whether Initiate-Credential-Acquisition (Section 5.1) returns a Freshness Handle.¶

• present-* kinds return a Freshness Handle. The Attester binds that Handle into Evidence (Section 4.5).¶

• absent-* kinds return no Handle. The Attester binds a timestamp from a trusted clock or an epoch marker already held locally, or makes no freshness claim.¶

The Freshness Kind is one of:¶

• absent-timestamp: no Freshness Handle is returned; the Attester binds a timestamp from a trusted clock into Evidence ([RFC9334], Section 10.1)¶

• absent-none: no Freshness Handle is returned; Evidence carries no freshness claim¶

• absent-epoch: no Freshness Handle is returned; the Attester binds an epoch marker already held locally into Evidence ([RFC9334], Section 10.3)¶

• present-nonce: Initiate-Credential-Acquisition returns a single-use nonce as the Freshness Handle; the Attester binds that Handle into Evidence ([RFC9334], Section 10.2)¶

• present-epoch: Initiate-Credential-Acquisition returns the current epoch marker as the Freshness Handle; the Attester binds that Handle into Evidence and retries Initiate-Credential-Acquisition if the epoch has moved ([RFC9334], Section 10.3)¶

It is NOT RECOMMENDED to use the absent-none Freshness Kind as it creates an opportunity of an unlimited replay of Evidence against the RATS Relying Party.¶

A Freshness Handle has a lifetime, set by its originator, after which the originator no longer accepts it. Initiate-Credential-Acquisition MAY return the lifetime with the Handle. The lifetime SHOULD leave the Attester time to produce the Evidence that carries the Handle: a platform may rate-limit attestation requests, so that an Attester waits several seconds for one report. A Freshness Handle originator SHOULD NOT set a lifetime below 60 seconds.¶

A present-nonce Freshness Handle is unpredictable (Section 10.2 of [RFC9334]): its originator MUST generate it with at least 128 bits of entropy, issue it once and never reuse it. Its length is set by the protocol profile. Initiate-Credential-Acquisition takes no requested length. The Handle enters the Evidence through the digest (Section 4.5), not as the freshness input itself, so no platform needs a Handle of a particular size.¶

Under absent-timestamp, the RATS Relying Party accepts Evidence whose timestamp is no older than the maximum age its policy sets, and no later than its own clock by more than the skew it tolerates. Initiate-Credential-Acquisition MAY return that maximum age, so that the Attester knows it. Section 10.1 of [RFC9334] notes that in many TEEs a clock is only available outside the TEE and cannot be trusted by it. On such a platform the timestamp bounds the age of the Evidence by a clock set by whoever serves the Attester the current time: Evidence made with that clock set ahead is accepted once the RATS Relying Party's clock reaches the timestamp, less the skew, and for the maximum age after that. A RATS Relying Party that needs a bound on the real age of Evidence uses a present-* Freshness Kind, or requires the Attester's time to be attested.¶

4.1. Attester's Role

1. At the Attester level, all work is performed by a new Acquire-Credential call through a dedicated ENVOY-like [ENVOY] Credential Acquisition Interface (CAI) which handles all the underlying complexity; this maximally simplifies Attester development.¶

2. To acquire credentials, CAI always uses a two-phase sequence:¶

   1. It requests and obtains a Freshness Kind (Section 2.1); freshness MAY come from the Verifier, or the Relying Party, or MAY even be empty [INTERACTION-MODELS] [ATTESTATION-FRESHNESS]¶

   2. It then generates and sends out Evidence, which is how the Attester demonstrates its security, possession of cryptographic key material, and capabilities¶

3. The Attester receives either an error or a newly acquired credential¶

4.2. Required Modifications to Existing Credential Acquisition Mechanisms

It is not a goal, and, at any rate, it is not possible, to leave credential acquisition protocols and mechanisms (EST, SPIFFE/SPIRE, etc.) unmodified. These mechanisms currently do not support Remote Attestation, for the following reasons:¶

1. None of the existing broadly deployed Credential Acquisition Mechanisms support this two-phase sequence.¶

2. The credentials that these existing mechanisms return are typically visible in plaintext to the control plane (the CAS Client and the CAS Server), whereas it is a common requirement to keep the knowledge of authentication secrets to the Attesters and a small number of trusted services, such as Secret Vaults and HSMs.¶

CAS protocols that are supported must therefore be able to carry Initiate-Credential-Acquisition, and must be capable of fetching and returning sealed, rather than plaintext, secrets. All Credential Acquisition Mechanisms examined to date appear extensible to accommodate such changes without a lot of additional effort, and without risking backwards compatibility.¶

4.3. Architecture Overview

At the high level, the TACRA architecture allows an Attester to obtain credentials from either a Credential Authority or a Secret Vault, both RATS Relying Parties, by interacting with these Relying Parties and the Verifier through an untrusted Credential Acquisition System (CAS). The CAS can be any existing system, such as Enrollment over Secure Transport (EST), Secure Production Identity Framework for Everyone (SPIFFE/SPIRE), Automated Certificate Management Environment (ACMEv2), etc., extended with additional commands related to Remote Attestation. The job of the Credential Acquisition System is to carry messages between the Attester and these back-end services using the Credential Acquisition System's own protocol. This is illustrated below.¶

                                      Enroll     +------------+
                               +-----------------> Credential |
                               |  +--------------+ Authority  |
                               |  |  Credential  +----+--^----+
             Initiate/         |  |                   |  |
             Enroll/           |  |                   |  |
+----------+ Retrieve  +-------+--v----+         +----v--+----+
|          +----------->  Credential   +--------->            |
| Attester |           |  Acquisition  |         |  Verifier  |
|          <-----------+    System     <---------+            |
+----------+ Initiate- +-------+--^----+         +----+--^----+
             Response/         |  |                   |  |
             Credential        |  |                   |  |
                               |  |  Credential  +----v--+----+
                               |  +--------------+   Secret   |
                               +----------------->   Vault    |
                                     Retrieve    +------------+

A more detailed architecture is illustrated below.¶

  Attesting
  Environment      +------- Credential Acquisition System ---------+
+-[Attester]---+   | SPIRE Agent,                   SPIRE Server,  |
|   Workload   |   | EST Client,...                 EST Server,... |
|+---<CAI>----+|   |+--------------+  Credential   +--------------+|
||    CAI     ||   ||  CAS Client  |  Acquisition  |  CAS Server  ||
|| Library or ||   ||+------------+|   Protocol    |+------------+||
|| Container  ||   |||   TACRA    || (EST, SPIRE,  ||   TACRA    |||
||+-<CAAPI>--+||   ||| CAS Client ||     etc.)     || CAS Server |||
|||  CAAPI   +++---++>  Plug-in   |+---------------+>  Plug-in   |||
|||  Client  |||   ||+------------+|               |+----------+-+||
||+----------+||   |+--------------+               +-----------+--+|
||+----------+||   +-------------------------------------------+---+
||| Platform |||                    +-Retrieve Key/Credential--+--+
||| Plug-in  |||                    |        +-Remote Attestation-+
||+-----+----+||                    |        |         +-Mint New-+
|+------+-----++---+                |        |         | Credential
+-------+------+   |   +-[RATS RP]--v-+ +----v-----+ +-v-[RATS RP]-+
+-------v------+   |   | Secret Vault +->   RATS   <-+ Credential  |
+<Platform ABI>+   |   +--------------+ | Verifier | | Authority   |
| (Quote, RNG, |   |                    +----------+ +-------------+
|     etc.)    | +-v-[RATS-Unaware RP]---------------+
+--------------+ | Existing Unmodified Relying Party |
                 +-----------------------------------+

The CAS comprises a client and a server. The CAS Client is presumed to be running on the Attester's system, but outside the Attesting Environment. The CAS Server is a remote service invoked by the CAS Client over the CAS protocol. Which CAS protocol is used MUST remain opaque to the Attester.¶

The Attester (the workload) runs inside an Attesting Environment, such as a Confidential Computing Trusted Execution Environment or TEE. It obtains credentials by invoking the Credential Acquisition Interface (CAI), defined in this document. CAI insulates the Attester from all the details of platform-specific and protocol-specific aspects and services involved in Remote Attestation and credential enrollment/retrieval. The CAI MAY be a statically or dynamically linked library, an Envoy-style sidecar, or any other mechanism, but it MUST be part of the Attesting Environment.¶

CAI interacts with the outside world on behalf of the Attester via two channels:¶

1. With the underlying hardware platform to utilize its platform-specific functions, such as generating keys and obtaining evidence, via the platform-type-specific plugin, and¶

2. With the Credential Acquisition System Client, via the well-defined Credential Acquisition API (CAAPI), also outlined later in this document.¶

4.4. Architecture Meeting Design Goals

In the text that follows, numbers in the format "(Goal #)" refer to the corresponding numbered items in the list of Design Goals in the opening section of this document.¶

CAAPI and the Platform Plug-in being the only two communication mechanisms needed to interact with the outside world, no network or storage stack are needed by the Attester (Goal 8). The server side of CAAPI is part of the CAS Client. There can be as many Credential Acquisition Client implementations as there are Credential Acquisition Mechanisms (Goal 4): EST Client, SPIRE Agent, etc. There is no restriction against multiple Credential Acquisition Mechanisms collectively serving the same Attester, with different mechanisms utilized for different targets (Goal 5). Existing CAS Clients are extended to support Remote Attestation via dedicated CAS Client Plug-ins.¶

The Credential Acquisition System controls which Credential Types and which Credential Acquisition Mode (enrollment, retrieval) can be offered to the Attester for any Attester-supplied target, without the Attester's knowledge or involvement (Goal 1). If a Credential Type specified by the Attester is unavailable due to Credential Acquisition System limitations, an error will result. It is an administrative error to pair an Attester with a Credential Acquisition System that is unable to supply it with the Credential Type(s) it requires.¶

The Credential Acquisition Server implements the server side of the corresponding Credential Acquisition Mechanism and interacts with the RATS Verifier, the Identity Provider (e.g., a Credential Authority for minting new certificates) and the Secret Vault for fetching existing keys or credentials, on the Attester's behalf (Goal 7). The Credential Types supported by this Architecture are limited only by what the Credential Acquisition System can support (Goal 2). Existing Credential Acquisition Servers are extended to support Remote Attestation via dedicated CAS Server Plug-ins. The CAS Server's interactions with the Verifier are those of a conduit, not of a Relying Party. When Initiate-Credential-Acquisition returns a Verifier-originated or RATS Relying Party-originated Freshness Handle, the CAS Server obtains that Handle and forwards it; it MUST NOT generate present-nonce or present-epoch values. In the Passport model, the CAS Server forwards Evidence to the Verifier and forwards the resulting Attestation Results to the Credential Authority or Secret Vault, which take on the role of the Relying Parties that execute Appraisal Policy for Attestation Results. In the Background Check model, the Relying Party typically obtains Attestation Results from the Verifier directly; the CAS Server need not be on that path. The CAS Server MUST NOT appraise, modify, or replace Attestation Results. These Verifier exchanges are opaque to the Attester.¶

This arrangement shields the Attester developers from having to know the details of the platform on which the Attester runs (Goal 9). It restricts the unavoidable expansion of the Attesting Environment to the smallest possible amount (Goal 3). There is no difference, from the standpoint of the Attester, whether the RATS Passport or Background Check model is being used (Goal 6).¶

Under the covers and opaquely to the Attester, the Credential Acquisition Interface discovers and utilizes one of two Credential Acquisition Modes: Enrollment and Retrieval. Enrollment corresponds to minting new proof-of-possession credentials, and Retrieval is used to fetch preshared keys, bearer tokens and shared proof-of-possession credentials (e.g., for Replica workloads). In both cases, the associated secrets remain opaque to the CAS at all times (Goal 10) even if the credential, such as an X.509 certificate, is public and can be returned in plaintext.¶

• Enrollment: the Credential Acquisition Interface generates a CSK and a CSR. The CSR carries CSKpub and, being self-signed, proves possession of CSKpri. The CSR MUST be bound to the Evidence as specified in Section 4.5, so that the Credential Authority can be sure the CSR was produced on the Attester's platform that the Evidence describes. Carrying Evidence inside the CSR ([CSR-ATTEST]) does not replace this binding.¶

• Retrieval: the Credential Acquisition Interface generates an asymmetric encryption key CEK. CEKpub MUST be bound to the Evidence as specified in Section 4.5. The resulting secrets are sealed to CEKpub, so that only the Attester in possession of CEKpri can read them (Section 4.6).¶

During both Enrollment and Retrieval, the Attester MAY supply a Credential Hint. During Enrollment, a Credential Authority MAY use the Credential Hint when assigning a Subject Alternative Name or other certificate properties. During Retrieval, a Secret Vault maps the Attestation Results to a credential group: stable for replica workloads, and distinct across security domains, tenants and the credentials it releases. That mapping is performed per the RATS Relying Party's policy; this document does not specify the identifier. An example of a mapping, not a requirement: SHA-256 over the length-prefixed concatenation, as Section 4.5 prefixes, of an octet string the Secret Vault derives from the Attestation Results, the Target and an octet string that names the release policy. It is derived from the Attestation Results and not from the Evidence, so that freshness does not change the group.¶

A Secret Vault MAY use the Credential Hint to select among the credentials that mapping allows for the attested context. The hint MUST NOT enlarge that set: a CAS that rewrites it obtains nothing the policy would not release, for that Target, to the attested workload the Attestation Results describe. The RATS Relying Party MAY reject the request if it will not honor the hint.¶

A Credential Authority MAY include information from the Attestation Results in the credential, for parties that accept the credential and can act on that information. In that case, the Credential Authority is responsible for ensuring that what it adds does not break RATS-unaware Relying Parties. For example, it keeps the addition small and, in a certificate, places it in a non-critical extension, which a certificate-using system that does not recognize may ignore (Section 4.2 of [RFC5280]). Attestation Results can reveal much about the Attester's platform (Section 11 of [RFC9334]), and every party the credential is presented to can read what it carries, so the Credential Authority SHOULD limit what it adds to what those parties need.¶

4.5. Binding Credential Keys to Evidence

The Evidence of a credential-acquisition exchange MUST carry a digest of three values in its freshness input, the field of the Evidence whose content the Attester chooses:¶

1. the freshness element of the Freshness Kind (Section 2.1): the Freshness Handle for the present-* kinds, the locally held epoch marker for absent-epoch, the Attester's timestamp for absent-timestamp, and the empty string for absent-none;¶

2. the Target of the corresponding Initiate-Credential-Acquisition call;¶

3. the subject: for Enrollment, the CSR, which carries CSKpub and proves possession of CSKpri; for Retrieval, CEKpub.¶

The digest is computed over the octet string¶

binding_input = len32(freshness) || freshness
             || len32(target)    || target
             || len32(subject)   || subject

where:¶

• len32(x) is the length of x in octets, as a 32-bit big-endian unsigned integer;¶

• freshness is the freshness element; a timestamp is an 8-octet big-endian unsigned count of seconds since 1970-01-01T00:00:00Z;¶

• target is the Target octet string; it is not recoded or normalized when the digest is computed: the octets the Attester bound are the octets the RATS Relying Party recomputes over;¶

• subject is, for Enrollment, the DER encoding of the CSR; for Retrieval, CEKpub in the encoding the Credential Acquisition Mechanism carries it in, which the protocol profile specifies.¶

The length prefixes make the encoding unambiguous: no two different sequences of values produce the same octets. The digest is SHA-512 ([RFC6234]) where the freshness input is 64 octets, e.g., REPORT_DATA of AMD SEV-SNP and REPORTDATA of Intel TDX. For a field of another size, a protocol profile specifies a hash whose output is the size of the field.¶

A configured target name that is not already an octet string, such as a URI typed into Attester runtime configuration, is encoded once, by the rule the protocol profile sets, before it is supplied as the Target of Initiate-Credential-Acquisition, Enroll-Credential or Retrieve-Credential. The RATS Relying Party applies that same rule to the Target in its policy. Look-alike Unicode strings remain distinct Targets; a profile that uses DNS names specifies how those names are prepared.¶

The Verifier MUST report in the Attestation Results the value of the freshness input of the Evidence it appraised. Where the expected freshness value is submitted with the Evidence, as in challenge-response appraisal, it is that value, after the Verifier has checked that the Evidence carries it. The Credential Authority (Enrollment) or Secret Vault (Retrieval) MUST recompute the digest from the freshness element and the Target of the request and the CSR or CEKpub it received. It MUST reject the request unless the result equals the value reported in the Attestation Results. This is the same in the Passport and the Background Check model: either way, the Relying Party compares against a value the Verifier took from, or checked against, the appraised Evidence, never one it has from the CAS alone.¶

The Freshness Kind reaches the Attester through the CAS, so the Relying Party MUST take the Freshness Kind for a Target from its own policy, not from the request. The freshness element MUST be checked under that kind before a credential is issued or released. For the absent-* kinds, which return no Freshness Handle, the Relying Party makes that check. For the present-* kinds, the Freshness Handle is either Verifier-originated or RATS Relying Party-originated. The party that issues a Freshness Handle checks it. A party, the Verifier included, MUST NOT issue a Freshness Handle that it cannot check:¶

• Verifier-originated: the Verifier issues the Handle and checks it, and the Relying Party relies on the Verifier's check, never on the request alone. The Evidence carries the digest, not the Handle. The Verifier therefore either recomputes the digest from the three values or, in the Background Check model, checks at the Relying Party's request the same Handle the Relying Party used to recompute the digest.¶

• RATS Relying Party-originated: the Credential Authority (Enrollment) or Secret Vault (Retrieval) issues the Handle and checks it itself. A present-nonce Handle is one it issued and has not been used before. A present-epoch Handle is the current epoch marker.¶

Because the CAS is untrusted (Section 7.2), each value mitigates a threat:¶

• without the Target, the CAS could initiate, at the intended Relying Party, for a Target the Attester did not ask for;¶

• without the freshness element, it could replay;¶

• without the CSR or CEKpub, it could substitute a key.¶

The digest shows that the attested environment chose this CSR or CEKpub. The private keys generated inside the Attesting Environment, CSKpri and CEKpri, MUST NOT leave it. The digest does not prove it: a public key or its hash in platform Evidence does not by itself demonstrate where its private key is (Section 6.1 of [CSR-ATTEST]). For Enrollment the subject is the finished CSR, so Evidence that carries this digest cannot travel inside that CSR, as the attribute of [CSR-ATTEST] does, and [CSR-ATTEST] does not replace this binding. A CSR MAY carry further attestations about its key under [CSR-ATTEST]. A Credential Authority that relies on such further attestations ensures that their binding to the key has been validated, as Section 6.1 of [CSR-ATTEST] requires.¶

The binding carries no Relying Party identifier. Which RATS Relying Party serves the Attester, and what a deployment does about it, is described in Section 7.2.¶

Producing the binding is the responsibility of the Platform Plug-in, because where the freshness input lives is platform-specific. It takes one of three forms:¶

• Direct: the Attesting Environment writes the digest into a guest-chosen field of the hardware Evidence. Examples are REPORT_DATA of an AMD SEV-SNP attestation report, REPORTDATA of an Intel TDX quote, and the user data of an AWS Nitro attestation document.¶

• Nested: a lower layer owns that field (for example, a paravisor that sets it at boot), and the digest travels in a nested attestation whose report data the guest controls, such as a vTPM quote.¶

• Provider-scoped: the Evidence is signed by a key shared across a provider's fleet and identifies the provider's key domain rather than a device. The binding holds, but a Relying Party whose policy requires a per-device identity rejects such Evidence.¶

A Relying Party MUST NOT assume the Direct form; it learns the form from the Attestation Results or from its appraisal policy.¶

This binding ties the CSR or CEKpub to the Attester's platform, to the intended Relying Party and Target, and to freshness. It does not by itself tie the exchange to the channel over which the credential is acquired. It does not cover the Credential Type or the Credential Hint, which the CAS can change. A RATS Relying Party MUST NOT issue or release a credential beyond what its policy allows for the attested context.¶

4.6. Sealing the Released Credential

In Retrieval, the Secret Vault releases a credential bundle inside a container sealed to CEKpub (Section 4.5). The CAS carries CEKpub and the container, and it is not trusted (Section 7.2). Sealing keeps the bundle from the CAS. It does not tell the Attester who sealed it: anyone who saw CEKpub can seal a container to it. This architecture accepts that. What the Attester then holds is stated in Section 7.2.¶

The container is an agreement between the Secret Vault that seals it and the Attester that opens it. The Credential Acquisition Mechanism carries it and does not read it, so this document specifies it, and a protocol profile names only the suites a Secret Vault accepts. The construction is as follows.¶

1. The Secret Vault seals the bundle to CEKpub with HPKE in base mode (Section 5.1.1 of [RFC9180]), with the info and the associated data below.¶

2. info is the length-prefixed concatenation, as in Section 4.5, of the label tacra hpke-base v1, the Target and the freshness element of the request. The label is ASCII, without a terminating NUL.¶

3. The associated data names the credential group, the Target, the freshness element and the Credential Hint of the request, in the encoding below. The AEAD authenticates it, and the Attester checks that it names what its Evidence bound.¶

4. The container carries the encapsulated key, the ciphertext and the associated data, and names its suite.¶

The mandatory HPKE suite is KEM DHKEM(P-256, HKDF-SHA256) (identifier 0x0010), KDF HKDF-SHA256 (0x0001) and AEAD AES-256-GCM (0x0002), all of [RFC9180]. Implementations MUST support it. A Secret Vault and an Attester MAY use another suite of the HPKE registries ([RFC9180]), named as those registries name its KEM, KDF and AEAD, the hybrid KEM MLKEM768-P256 of [HPKE-PQ] for instance. Which suites a Secret Vault accepts, the Credential Acquisition Mechanism tells the Attester at Initiate-Credential-Acquisition.¶

The container is a JSON object ([RFC8259]), the encrypted-credential-bundle below, in CDDL ([RFC8610]). A byte string is carried as a text string holding its unpadded base64url encoding (Section 5 of [RFC4648]), as the control operator .b64u defines it (Section 2.1 of [RFC9741]). The associated data is the JSON Canonicalization Scheme serialization ([RFC8785]) of the aad object, and the plaintext is the JCS serialization of a credential-bundle object. In aad, target is the Target octet string of the request. handle is the freshness element and is present when the request carried one, and credential_hint is present when the request carried one. The Attester compares the decoded target octets to the Target of the request; they are the same Target only when those octets are identical.¶

encrypted-credential-bundle = {
  container: "hpke-base",
  suite: {
    kem: text,
    kdf: text,
    aead: text,
  },
  enc: text .b64u bytes,
  ciphertext: text .b64u bytes,
  aad: {
    group_id: text,
    target: text .b64u bytes,
    ? handle: text .b64u bytes,
    ? credential_hint: text,
  },
}

credential-bundle = {
  credential_items: [+ credential-item],
  ? metadata: { * text => any },
}

credential-item = {
  type: text,
  value: text .b64u bytes,
  ? format: text,
  ? kid: text,
  ? purpose: [+ text],
  ? algorithm: text,
  ? exportable: bool,
  ? shared: bool,
}

Each credential item carries a Credential Type token as its type and the credential as its value, the unpadded base64url of the credential's octets. Those octets are a DER certificate for x509 and wic, a DER PrivateKeyInfo ([RFC5958]) for private-key, the key octets for psk, and the UTF-8 encoding of the token for wit, jwt and api-key. format, when present, names another encoding of those octets, which the Secret Vault and the Attesters it serves agree on out of band. kid, purpose, algorithm, exportable and shared are the key-block attributes the Secret Vault's policy sets. metadata MAY carry validity_seconds (integer) and secret_version (string).¶

The Attester, through its Credential Acquisition Interface, MUST refuse a container whose associated data does not name its Target, its freshness element and its Credential Hint, or whose suite it does not support. These checks come before it opens anything. After these checks pass, the Attester unseals the ciphertext using CEKpri. The Secret Vault's container for another request does not open, since it is not encrypted to the same CEKpub. The CAS can see CEKpub and therefore can seal a container of its own choosing to it instead of the one returned by the Secret Vault. That container passes these checks and opens, and what the Attester then holds is stated in Section 7.2.¶

CEKpub travels in the encoding its KEM defines, and those octets are the subject of the binding (Section 4.5). For a Diffie-Hellman KEM that is the DER encoding of a SubjectPublicKeyInfo ([RFC5280]). For DHKEM(P-256, HKDF-SHA256) it is one for id-ecPublicKey on prime256v1 ([RFC5480]), whose subjectPublicKey holds the uncompressed point (Section 2.2 of [RFC5480]). Those 65 octets are the recipient public key that HPKE deserializes (Section 7.1.1 of [RFC9180]). For the KEMs of [HPKE-PQ], which have no SubjectPublicKeyInfo form, it is the encapsulation key itself. The Attesting Environment MUST generate a brand new CEK for each Retrieve-Credential request.¶

4.7. Summary of RATS Roles

5.1. Initiate-Credential-Acquisition

Initiates the credential acquisition process by obtaining Freshness and validating that the indicated Target name, Credential Type, and Credential Hint, if any, are supported by the CAS.¶

Parameters:¶

• Target name: the octet string of the Target definition, for example a profile-encoded URI of the RUP¶

• Credential Type the Attester plans to use with this Target¶

• Credential Hint (optional) the Attester wishes to communicate when obtaining the credential¶

Returns:¶

• On success:¶

  • Credential acquisition mechanism: "enroll" or "retrieve"¶

  • Freshness Kind (Section 2.1): one of absent-timestamp, absent-none, absent-epoch, present-nonce, or present-epoch¶

  • Freshness Handle, when the Freshness Kind is present-nonce or present-epoch¶

  • Lifetime of the Freshness Handle, when one is returned (optional, Section 2.1)¶

  • Maximum Evidence age, when the Freshness Kind is absent-timestamp (optional, Section 2.1)¶

  • The signature algorithms the Credential Authority accepts for the CSK, when the Credential Acquisition Mode is Enrollment¶

  • The HPKE suites of the container (Section 4.6) the Secret Vault accepts, when the Credential Acquisition Mode is Retrieval¶

• On failure: enumerated reason for failure, such as:¶

  • Invalid Target¶

  • Unsupported Target¶

  • Unsupported Credential Type¶

  • Invalid Credential Hint¶

  • Server error: permission failure¶

  • Server error: server too busy; try again later¶

  • Server error: server unreachable¶

5.2. Enroll-Credential

Enrolls (mints) a new proof-of-possession credential.¶

Parameters:¶

• Target name matching that of the corresponding Initiate-Credential-Acquisition call¶

• Credential Type matching that of the corresponding Initiate-Credential-Acquisition call¶

• Freshness element of Section 4.5: the Freshness Handle returned by the corresponding Initiate-Credential-Acquisition call, the locally held epoch marker, or the Attester's timestamp; absent for absent-none¶

• Evidence carrying the binding of Section 4.5¶

• CSR bound to the Evidence as specified in Section 4.5; the CSR carries CSKpub and proves possession of CSKpri¶

• Credential Hint (optional) matching that of the corresponding Initiate-Credential-Acquisition call¶

Returns:¶

• On success: plaintext newly enrolled (minted) credential of the requested type¶

• On failure: enumerated reason for failure, such as:¶

  • Invalid Target¶

  • Unsupported Target¶

  • Unsupported Credential Type¶

  • Rejected or unsupported Credential Hint¶

  • Server error: Remote Attestation failure¶

  • Server error: permission failure¶

  • Server error: server too busy; try again later¶

  • Server error: server unreachable¶

5.3. Retrieve-Credential

Retrieves (fetches pre-existing) credential.¶

Parameters:¶

• Target name matching that of the corresponding Initiate-Credential-Acquisition call¶

• Credential Type matching that of the corresponding Initiate-Credential-Acquisition call¶

• Freshness element of Section 4.5: the Freshness Handle returned by the corresponding Initiate-Credential-Acquisition call, the locally held epoch marker, or the Attester's timestamp; absent for absent-none¶

• Evidence carrying the binding of Section 4.5¶

• CEKpub bound to the Evidence as specified in Section 4.5¶

• Credential Hint (optional)¶

Returns:¶

• On success: wrapped (encrypted to CEKpub) credential of the requested type¶

• On failure: enumerated reason for failure, such as:¶

  • Invalid Target¶

  • Unsupported Target¶

  • Unsupported Credential Type¶

  • Rejected or unsupported Credential Hint¶

  • Server error: permission failure¶

  • Server error: Remote Attestation failure¶

  • Server error: server too busy; try again later¶

  • Server error: server unreachable¶

5.4. CAAPI Invocation Sequence

The caller (normally the Credential Acquisition Interface) first decides which Target it wishes to authenticate to, using which Credential Type. CAAPI offers no facilities for discovering these; they are decided out of band, for example from Attester runtime configuration.¶

The typical invocation flow is:¶

1. CAAPI: Initiate-Credential-Acquisition(Target, Credential Type, Credential Hint)¶

   • Returns Freshness kind and the Credential Acquisition Mode for this Target and Credential Type¶

2. Platform Plug-in: Generate keys and Evidence for the Credential Acquisition Mode and Freshness kind returned in step 1, with the binding of Section 4.5, whose freshness element is:¶

   • Freshness kind of present-nonce or present-epoch: the Freshness Handle¶

   • Freshness kind of absent-timestamp: a timestamp from a trusted clock ([RFC9334], Section 10.1)¶

   • Freshness kind of absent-epoch: the locally held epoch marker¶

   • Freshness kind of absent-none: empty (no freshness claim)¶

   • In all cases, the binding covers the CSR (enrollment) or CEKpub (retrieval)¶

3. CAAPI: Depending on which Credential Acquisition Mode is returned, either¶

   • Enroll-Credential(Target, Credential Type, Credential Hint, freshness element, CSR, Evidence)¶

   • Retrieve-Credential(Target, Credential Type, Credential Hint, freshness element, CEKpub, Evidence)¶

4. CAI examining Enroll-Credential or Retrieve-Credential results:¶

   • If Enroll-Credential or Retrieve-Credential fails because a present-epoch marker has moved (or a present-nonce is no longer valid), it retries from Initiate-Credential-Acquisition.¶

   • These retries are not visible to the Attester.¶

6.1. Acquire-Credential

Orchestrates an opaque-to-Attester process by which the Attester acquires a credential that it would need to authenticate to a given Target utilizing the given Credential Type.¶

Parameters:¶

• Target name: the octet string of the Target definition, for example a profile-encoded URI of the RUP¶

• Credential Type the Attester plans to use with this Target¶

• Credential Hint (optional)¶

All of these parameters the Attester MAY learn from runtime configuration.¶

Returns:¶

• On success: newly acquired credential of the requested type¶

• On failure: enumerated reason for failure, such as:¶

  • Invalid Target¶

  • Unsupported Target¶

  • Unsupported Credential Type¶

  • Rejected or unsupported Credential Hint¶

  • Server error: Remote Attestation failure¶

  • Server error: permission failure¶

  • Server error: server too busy; try again later¶

  • Server error: server unreachable¶

7.1. Undesirability and Inevitability of Bearer Tokens

This specification supports but discourages the use of bearer token credentials. They are supported in the interest of maximizing compatibility. While the specification takes care to deliver bearer token credentials to the Attester securely, subsequent usage, such as using them in authentication against the RUP, still risks leaking them.¶

7.2. Trust Model: the Credential Acquisition System as an Untrusted Conduit

This section exists because in this architecture the Attester never communicates with the Verifier or the RATS Relying Party directly. Instead, all messages between the Attester and these services flow through the Credential Acquisition System, and the Attester need not know what those entities are. Transport security is therefore not end to end. There is a secure channel between the CAS Client and the CAS Server, and another between the CAS Server and the Verifier or the RATS Relying Party. The CAAPI between the Attester and the CAS Client is local to the Attester's system. This architecture seeks to protect credentials acquired by the Attester from disclosure to the Credential Acquisition System. For that reason, the Attester does not treat the Credential Acquisition System as anything other than a conduit between itself and the services needed for Remote Attestation and credential issuance. The CAS Client and the CAS Server hold no RATS role and no credential, and they are not assumed to be benevolent. What a malicious CAS that delays, replays, rewrites or redirects messages can do is restricted as follows.¶

What each party holds, and what bounds it:¶

• The Attester, with its Credential Acquisition Interface, holds CSKpri or CEKpri inside the environment its Evidence attests. It can produce Evidence over any value it chooses as the freshness input, and ask for any Target. The Verifier appraises its platform and the software it runs, and the Credential Authority or Secret Vault decides by its policy, not by what the Attester asks.¶

• The CAS Client and the CAS Server see every message in transit: the Freshness Handle, the Evidence, the CSR or CEKpub, the Credential Type and the Credential Hint, and the credential or the sealed container. In the Passport model, the CAS Server also sees the Attestation Results. The CAS Client and CAS Server can delay, replay and reorder messages. They can obtain a Freshness Handle from any RATS Relying Party for any Target, carry a request to another RATS Relying Party, and change what the binding (Section 4.5) does not cover. In the Passport model, they can also choose the Verifier. What bounds them:¶

  • the binding, recomputed by the RATS Relying Party;¶

  • the freshness element;¶

  • the RATS Relying Party's policy;¶

  • the Verifier(s) the RATS Relying Party trusts;¶

  • the container sealed to CEKpub (Section 4.6).¶

• The Verifier holds Reference Values, the hardware vendors' roots and, when it originates them, Freshness Handles. It appraises Evidence and reports the freshness input it read. It decides nothing about credential issuance or retrieval.¶

• The Credential Authority and the Secret Vault hold the issuance policy, the signing key or the secrets, and the Verifiers they trust. Each recomputes the binding from the request and from what it holds (Section 4.5), and checks the freshness element under the Freshness Kind of its policy. The Secret Vault seals what it releases to CEKpub (Section 4.6).¶

The various attacks the CAS is capable of and their mitigations are listed below:¶

• Substitution of a value. If the CAS changes a request by modifying its Target, CSR, CEKpub, or freshness element, that request would be refused by the RATS Relying Party: the digest the RATS Relying Party recomputes no longer equals the one the Verifier read from the Evidence (Section 4.5).¶

• Substitution of the Attester. The CAS can replace the Evidence the Attester supplied with Evidence from a platform of its choosing. It obtains nothing for the Attester's keys:¶

  • a platform that is not genuine: its Evidence does not chain to the vendor's root;¶

  • a genuine platform running other software: it fails the Reference Values the policy sets for that Target;¶

  • a genuine platform running the same software: it is another instance of the attested workload, with its own keys, and what it obtains is a credential for those keys.¶

• Replay at the same RATS Relying Party. The RATS Relying Party keeps no record of a CSR or CEKpub it served. Only the freshness element can refuse a second offer of the same request:¶

  • present-nonce: one Evidence serves once, as the Handle is consumed on first use;¶

  • present-epoch and absent-epoch: the same request is served again until the epoch moves;¶

  • absent-timestamp: the same request is served again within the window the RATS Relying Party accepts;¶

  • absent-none: the same request is served again without limit.¶

  What the CAS obtains is a second credential, or a second release, for the Attester's key. A deployment that counts or audits credentials uses present-nonce.¶

• Redirection to another RATS Relying Party. The CAS can offer Evidence made for one Credential Authority or Secret Vault to another that trusts the same Verifier and serves a Target of the same name. Whatever that RATS Relying Party issues or releases is bound to the Attester's keys, so the CAS obtains nothing it can use. What is at stake is which RATS Relying Party serves the Attester, and who chooses it:¶

  • This document binds no Relying Party identifier (Section 4.5). Binding one would make the second RATS Relying Party refuse every Freshness Kind, including a Freshness Handle it originated itself.¶

  • As it is, the CAS Server chooses among the RATS Relying Parties that trust the same Verifier and serve that Target name. present-nonce keeps one Evidence from serving a second RATS Relying Party, but not the one the CAS Server started the exchange at.¶

  • The binding does not bind the channel. A channel binding, such as a TLS exporter ([RFC9266]), would have to reach the Attesting Environment from the CAS Client, which this architecture does not assume (Design Goal 8). The binding names the Target, not the RATS Relying Party, and Evidence can reach any RATS Relying Party.¶

  • The CAS Server picks which Credential Authority or Secret Vault to use as the RATS Relying Party. A Credential Acquisition Mechanism MAY name that choice, the optional path segment of EST for instance (Section 3.2.2 of [RFC7030]), and such a name is not the Target.¶

• Substitution of the response. In Retrieval, the CAS can return a container of its own making, sealed to CEKpub, which it saw in the request, or the Secret Vault's container for another request. The second was sealed to another CEK and cannot be unsealed. The first unseals, and the Attester then holds a credential of the CAS's choosing, not the one the Secret Vault released, which the CAS cannot read. What follows depends on the Credential Type: with an API key, the Attester's calls then run under the account the CAS chose. This architecture accepts that risk.¶

• The choice of Verifier in the Passport model. The CAS Server chooses the Verifier it sends Evidence to, and relays the Attestation Results. A RATS Relying Party MUST accept Attestation Results only from a Verifier it trusts, and MUST check that the freshness input they report equals its own recomputation of the binding (Section 4.5). Any other Verifier chosen by the CAS is therefore of no use to it.¶

• What the binding does not cover. The Credential Type and the Credential Hint travel unbound, and a CAS can change them. Two things limit the impact of such substitution:¶

  1. The RATS Relying Party's policy issues or releases nothing beyond what it allows for the attested context, whatever the request says.¶

  2. The Attester sees whether the credential it receives is the one it asked for (Section 4.5, Section 7.3, Section 7.4).¶

  The Freshness Kind is set by the RATS Relying Party's policy for the Target, not by the request (Section 4.5). The Freshness Handle, for the present-* kinds, is originated by the Verifier or by the RATS Relying Party (Section 4.5).¶

• Denial of service. The CAS can delay or drop any message, and obtain Freshness Handles it never uses. This is mitigated by the CAS Client authenticating to the CAS Server, and the CAS Server authenticating to the Verifier and to the RATS Relying Party. Whichever of them originates Freshness Handles can then bound what it originates per client (Section 7.5).¶

What the CAS reads. Evidence is signed, not encrypted, and the CAS Client and the CAS Server read it in transit. In the Passport model, the CAS Server can also inspect the Attestation Results. Evidence identifies the platform, its firmware level and the launched software, and may identify the device (Section 7.2 and Section 11 of [RFC9334]). The RATS architecture expects any entity that relays Evidence, other than the Attester or the intended Verifier, to not have access to it (Section 12.2 of [RFC9334]). This architecture accepts that the CAS reads Evidence and Attestation Results. What the CAS cannot read is CSKpri, CEKpri and the secret the Secret Vault seals to CEKpub.¶

The CAS Client SHOULD be outside the Attester's trust boundary. Outside it, the CAS Client is not attested as part of the Attester, and this architecture relies on it for nothing beyond carrying messages. Inside it, as when the CAS Client runs in the same Confidential VM, it shares the Attester's environment and can inspect the secrets the Attester generates and the secrets the CAS Server returns. While it is possible for the Secret Vault to release the secrets to the CAS Server in plaintext and have the CAS Server seal them using CEKpub, this architecture does not allow it, as doing so would violate Design Goal 10.¶

A compromised platform attestation key breaks every guarantee above. The Verifier's defences are the vendor's root, which the platform attestation key must chain to, and the TCB level the Evidence reports, which the Verifier's policy can require to be current. Under absent-timestamp, Evidence carries the current value of the Attester's clock, and its freshness is only as good as that clock (Section 2.1). Where a credential is honoured once issued or released is set by the Credential Authority's or Secret Vault's policy, as for any credential, and not by the binding, which only keeps Evidence for one Target from obtaining a credential for another (Section 7.4).¶

7.3. Credential Hint

The Credential Hint is a request, not an authorization. A Credential Authority or Secret Vault MAY use it when selecting issued credential properties, or locating a stored credential, and MAY ignore or reject it. The hint MUST NOT cause issuance or release of a credential that Appraisal Policy for Attestation Results or local issuance policy would otherwise deny.¶

7.4. Credential Scope

The binding (Section 4.5) ensures that Evidence produced for one Target does not obtain a credential for another. It does not limit where the credential is honored once issued or released: that is the credential's scope, set, as for any credential, by the policy of the Credential Authority or Secret Vault and by the RATS-unaware Relying Parties that accept the credential. A certificate, for example, is bound to the identities in its subject alternative names (Section 4.2.1.6 of [RFC5280]), and a JSON Web Token can name its intended recipients in its audience claim, which a recipient not named there rejects (Section 4.1.3 of [RFC7519]). The scope comes from that policy and not from the request: the Credential Type and the Credential Hint, which the binding does not cover, cannot widen it (Section 4.5, Section 7.3). A deployment that needs a credential usable only at the requested Target issues or releases it with that scope.¶

7.5. CAS Client Authentication to CAS Server

In this architecture, Remote Attestation is used to authenticate the Attester to the services (Secret Vault or Credential Authority) involved in Credential Issuance. In any given implementation, the CAS Client MAY still authenticate to the CAS Server.¶

Whether CAS Client authentication must be bound to Attester authentication is left to protocol profiles.¶

9.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC5480]

Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, <https://www.rfc-editor.org/rfc/rfc5480>.

[RFC5958]

Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, <https://www.rfc-editor.org/rfc/rfc5958>.

[RFC6234]

Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/rfc/rfc6234>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9180]

Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9741]

Bormann, C., "Concise Data Definition Language (CDDL): Additional Control Operators for the Conversion and Processing of Text", RFC 9741, DOI 10.17487/RFC9741, March 2025, <https://www.rfc-editor.org/rfc/rfc9741>.

9.2. Informative References

[ATTESTATION-FRESHNESS]

Tschofenig, H., Brockhaus, H., Mandel, J., and S. Turner, "Requesting a Freshness Nonce for Attestation Evidence in Certificate Signing Requests", Work in Progress, Internet-Draft, draft-ietf-lamps-attestation-freshness-09, 17 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-attestation-freshness-09>.

[CSR-ATTEST]

Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M., and N. Smith, "Use of Remote Attestation with Certification Signing Requests", Work in Progress, Internet-Draft, draft-ietf-lamps-csr-attestation-32, 22 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-csr-attestation-32>.

[ENVOY]

Envoy, "The Envoy Proxy", n.d., <https://envoyproxy.io>.

[HPKE-PQ]

Barnes, R. and D. Connolly, "Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE", Work in Progress, Internet-Draft, draft-ietf-hpke-pq-05, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-hpke-pq-05>.

[INTERACTION-MODELS]

Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference Interaction Models for Remote Attestation Procedures", Work in Progress, Internet-Draft, draft-ietf-rats-reference-interaction-models-20, 28 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-reference-interaction-models-20>.

[RFC5198]

Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/rfc/rfc5198>.

[RFC7030]

Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/rfc/rfc7030>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC8555]

Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/rfc/rfc8555>.

[RFC9266]

Whited, S., "Channel Bindings for TLS 1.3", RFC 9266, DOI 10.17487/RFC9266, July 2022, <https://www.rfc-editor.org/rfc/rfc9266>.

[SPIFFE]

spiffe.io, "Secure Production Identity Framework for Everyone", n.d., <https://github.com/spiffe/>.

[SPIRE]

spiffe.io, "SPIRE Concepts", n.d., <https://spiffe.io/docs/latest/spire-about/spire-concepts/>.

[TWISIGCharter]

Confidential Computing Consortium Trustworthy Workload Identity SIG, "Trustworthy Workload Identity (TWI) Special Interest Group - Charter", n.d., <https://github.com/confidential-computing/governance/blob/main/SIGs/TWI/TWI_Charter.md>.

[TWISIGDef]

Confidential Computing Consortium Trustworthy Workload Identity SIG, "Trustworthy Workload Identity (TWI) Special Interest Group - Definitions", n.d., <https://github.com/confidential-computing/twi/blob/main/TWI_Definitions.md>.

[TWISIGReq]

Confidential Computing Consortium Trustworthy Workload Identity SIG, "Trustworthy Workload Identity (TWI) Special Interest Group - Requirements", n.d., <https://github.com/confidential-computing/twi/blob/main/TWI_Requirements.md>.

[WIMSE]

Campbell, B., Salowey, J. A., Schwenkschuster, A., Sheffer, Y., and Y. Rosomakho, "WIMSE Workload Credentials", Work in Progress, Internet-Draft, draft-ietf-wimse-workload-creds-03, 30 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-03>.