]> J.P. Morgan Chase & Co.

mark.f.novak@jpmchase.com

Sandelman Software Works

mcr+ietf@sandelman.ca

Fraunhofer SIT

Henk.Birkholz@ietf.contact

The Capital Index LLC

nikolaichuk.s.f@gmail.com

Security Remote ATtestation ProcedureS trustworthy workload identity remote attestation credential enrollment credential retrieval There is a large class of "RATS-Unaware" Relying Parties (RUPs) that Attesters nevertheless need to interoperate with. Existing deployed services, which precede the introduction of Remote Attestation, are often difficult to change/update in significant ways due to, among other reasons, organizational friction, technological inertia, and regulatory policies. There are significant advantages if workloads can be incrementally updated in the trustworthiness of the platform, without disrupting their clients and servers. This document describes an architecture by which Remote Attestation is utilized for providing Attesters with Identity Documents (keys or credentials) to authenticate to RUPs. This architecture is intended to work with common credential acquisition protocols and mechanisms such as EST, SPIFFE/SPIRE, ACMEv2, and many others. Another important but separate goal is to encapsulate the Attester-side complexity of Remote Attestation and credential acquisition. This allows Attesters to be implemented in a way that abstracts away the details of credential acquisition: both the protocols used and the Credential Acquisition Mechanisms employed, whether minting new (Enrollment), or requesting existing (Retrieval) credentials. Likewise, the choice between RATS Passport and Background Check models is made opaque to the Attester, further simplifying its development. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Success of a technology is ultimately measured by its adoption. The Remote ATtestation procedureS (RATS) Architecture requires that RATS Relying Parties understand Attestation Results, execute Appraisal Policy for Attestation Results, and have trust in Verifiers. A change in Evidence may lead to a change in either the Attestation Results or Appraisal Policy for Attestation Results. One key requirement for successful deployment of Remote Attestation-capable workloads is minimal blast radius: so long as a change in the workload is authorized, the clients and servers it interacts with should not notice any difference. The minimum blast radius requirement comes from real-world deployments: it is common for authentication and authorization policies on Relying Parties to remain static for long periods of time. It is therefore impractical to have the Relying Party make complex decisions based on the credential's changing content. When a workload is moved from a legacy to a remotely attestable Trusted Execution Environment, that workload can use Remote Attestation to obtain a stable and trustworthy Identity Document, while its clients and servers do not notice anything different. For that, a mechanism is required by means of which a Secret Vault or a Credential Authority takes on the role of RATS Relying Party. This provides an intermediation between Attestation Results and the RATS-Unaware Relying Parties whose authentication and authorization policies may precede the introduction of Remotely Attestable Workloads and remain static for long periods of time. For the RATS-Unaware Relying Parties, these adoption barriers are eliminated, as these RUPs are capable of authenticating their clients utilizing Identity Document types they are already familiar with. In summary, rather than using Remote Attestation directly against the RUP, the Attester uses it to obtain from the RATS Relying Party a key, bearer token or proof-of-possession credential that is compatible with the RUP. This document details an Architecture by which legacy Identity Document issuance mechanisms are replaced or modified such that functionally identical Identity Documents are issued, but with the additional prerequisite of successful Remote Attestation of the workloads in question.

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.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Proof-of-Possession Credential: a credential that requires a private asymmetric signing key to sign statements using this credential PKIX certificate WIMSE Workload Identity Certificate (WIC) and Workload Identity Token (WIT) etc. Bearer Token Credential: a credential that does not require proof of possession of a secret to use: Pre-shared symmetric key API key JSON Web Token JWT etc. Credential Type: a catch-all term for any concrete credential type from the two lists above Credential, a.k.a. Identity Document: an instance of a Credential Type Credential Type token: the name of a Credential Type in a Credential Acquisition Mechanism and in the container of : x509: a PKIX certificate wic: a WIMSE Workload Identity Certificate wit: a WIMSE Workload Identity Token jwt: a JSON Web Token used as a bearer token api-key: an API key psk: a pre-shared symmetric key private-key: a private key shared by the instances of a replicated service Credential Acquisition Mechanism: one of any number of existing or future mechanisms for acquiring credentials, such as , /, , etc. Credential Acquisition System (CAS): a client-server architecture comprising a CAS Client and a CAS Server which implements a Credential Acquisition Mechanism Credential Acquisition Mode: one of Credential Enrollment (minting new proof-of-possession credential), or Credential Retrieval (retrieving an existing, pre-provisioned credential of any Credential Type) Replica workloads: workloads that are functionally indistinguishable from the point of view of clients that authenticate to them or servers that they authenticate to; typical in "horizontal scale-out" scenarios where multiple identical workload instances are launched to handle the load in parallel Target: an octet string that identifies the RATS-unaware Relying Party for which the Attester seeks credentials. Two Targets are the same only when those octets are identical. This document does not assign a character encoding or a Unicode normalization. A protocol profile specifies how a configured name is encoded into that octet string. A profile that starts from Unicode text uses UTF-8 in Normalization Form C (), so the Attester and the RATS Relying Party produce the same octets from the same name. Examples of such names are a URI and a SPIFFE ID (). Credential Hint: optional, implementation-defined information supplied by the Attester about the credential it expects. The Attester MAY obtain the hint from runtime configuration. A RATS Relying Party MAY use the hint, ignore it, or reject the request. This document does not specify the hint's syntax or meaning. CSK: Credential Signing Key for proof-of-possession credentials; CSKpri and CSKpub refer to the private and public portions, respectively CEK: Credential Encryption Key for retrieved secrets; CEKpri and CEKpub refer to the private and public portions, respectively Freshness Handle: a Handle as defined in (for example an attestation nonce or an Epoch Marker), bound into Evidence to demonstrate freshness Freshness Kind: how freshness is established for one credential acquisition exchange; see Note: WITs are JWTs that require key confirmation. That makes them proof-of-possession credentials, whereas JWTs are used without key confirmation and are thus considered bearer tokens.

Freshness Kind This document classifies Evidence freshness for a credential-acquisition exchange by combining the methods in Section 10 of with whether Initiate-Credential-Acquisition () returns a Freshness Handle. present-* kinds return a Freshness Handle. The Attester binds that Handle into Evidence (). 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 (, 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 (, Section 10.3) present-nonce: Initiate-Credential-Acquisition returns a single-use nonce as the Freshness Handle; the Attester binds that Handle into Evidence (, 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 (, 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 ): 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 (), 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 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.

Design Goals This architecture is a result of work by the Confidential Computing Consortium's Trustworthy Workload Identity (TWI) SIG which has published a set of Definitions and Requirements . The requirements published by the TWI SIG are deliberately high-level. The design goals specified here are motivated by the TWI SIG requirements, while focusing on a portable and extensible implementation. Must support mechanisms for enrolling (minting new) as well as retrieving (pre-existing) credentials; the workload knows what Credential Type it will need when it launches, but discovers whether it will have to retrieve an existing or enroll a new credential at runtime Must support current and future credential formats: X.509 Certificates WIMSE Workload Identity Certificates (WICs) WIMSE Workload Identity Tokens (WITs) Bearer tokens (JWTs, API Keys) Pre-shared keys Future formats through architectural extensibility Should limit the trust boundary expansion of the Attesting Environment to the minimum Must support, transparently to the Attester, most current and future Credential Acquisition Mechanisms: EST (RFC 7030) SPIFFE/SPIRE ACMEv2 (RFC 8555) Future mechanisms through architectural extensibility Must support Workloads utilizing different Credential Acquisition Mechanisms per-target Must support both Background Check and Passport RATS modes, indistinguishably from the point of view of the Attester Must support most current and future RATS Verifiers, Credential Authorities, and Secret Vaults, transparently to the Attester Must not assume that the Attester has network access Must be compatible with all existing and future Confidential Computing platforms meeting minimum requirements around secure cryptography and evidence generation Should restrict visibility of fetched secrets to the Attester, specifically excluding visibility by the CAS Client and CAS Server

Architecture

Attester's Role At the Attester level, all work is performed by a new Acquire-Credential call through a dedicated ENVOY-like Credential Acquisition Interface (CAI) which handles all the underlying complexity; this maximally simplifies Attester development. To acquire credentials, CAI always uses a two-phase sequence: It requests and obtains a Freshness Kind (); freshness MAY come from the Verifier, or the Relying Party, or MAY even be empty It then generates and sends out Evidence, which is how the Attester demonstrates its security, possession of cryptographic key material, and capabilities The Attester receives either an error or a newly acquired credential

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: None of the existing broadly deployed Credential Acquisition Mechanisms support this two-phase sequence. 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.

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.

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.

----+| |+--------------+ Credential +--------------+| || CAI || || CAS Client | Acquisition | CAS Server || || Library or || ||+------------+| Protocol |+------------+|| || Container || ||| TACRA || (EST, SPIRE, || TACRA ||| ||+---+|| ||| 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 | ++ | +--------------+ | 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: 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 With the Credential Acquisition System Client, via the well-defined Credential Acquisition API (CAAPI), also outlined later in this document.

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 , 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 () 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 . The resulting secrets are sealed to CEKpub, so that only the Attester in possession of CEKpri can read them (). 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 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 ). Attestation Results can reveal much about the Attester's platform (Section 11 of ), 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.

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: the freshness element of the Freshness Kind (): 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; the Target of the corresponding Initiate-Credential-Acquisition call; 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

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 () 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 (), 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 ). For Enrollment the subject is the finished CSR, so Evidence that carries this digest cannot travel inside that CSR, as the attribute of does, and does not replace this binding. A CSR MAY carry further attestations about its key under . A Credential Authority that relies on such further attestations ensures that their binding to the key has been validated, as Section 6.1 of 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 . 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.

Sealing the Released Credential In Retrieval, the Secret Vault releases a credential bundle inside a container sealed to CEKpub (). The CAS carries CEKpub and the container, and it is not trusted (). 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 . 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. The Secret Vault seals the bundle to CEKpub with HPKE in base mode (Section 5.1.1 of ), with the info and the associated data below. info is the length-prefixed concatenation, as in , of the label tacra hpke-base v1, the Target and the freshness element of the request. The label is ASCII, without a terminating NUL. 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. 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 . Implementations MUST support it. A Secret Vault and an Attester MAY use another suite of the HPKE registries (), named as those registries name its KEM, KDF and AEAD, the hybrid KEM MLKEM768-P256 of 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 (), the encrypted-credential-bundle below, in CDDL (). A byte string is carried as a text string holding its unpadded base64url encoding (Section 5 of ), as the control operator .b64u defines it (Section 2.1 of ). The associated data is the JSON Canonicalization Scheme serialization () 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.

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 () 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 . CEKpub travels in the encoding its KEM defines, and those octets are the subject of the binding (). For a Diffie-Hellman KEM that is the DER encoding of a SubjectPublicKeyInfo (). For DHKEM(P-256, HKDF-SHA256) it is one for id-ecPublicKey on prime256v1 (), whose subjectPublicKey holds the uncompressed point (Section 2.2 of ). Those 65 octets are the recipient public key that HPKE deserializes (Section 7.1.1 of ). For the KEMs of , 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.

Summary of RATS Roles TACRA Component RATS Role Remarks Attester Attester Attesting Environment extended and complemented by CAI, CAAPI, Platform Plug-in CAI Part of Attester Library or Sidecar assisting Attester in obtaining credentials Platform Plug-in Part of Attester Invoked by CAI to perform platform-specific Remote Attestation and key generation operations CAAPI Client Part of Attester Invoked by CAI to communicate with CAS Client CAS Client None: Conduit only CAS Client extended by Remote Attestation Plug-in; SHOULD be outside the Attester's trust boundary and, wherever it runs, is trusted for nothing beyond carrying messages () CAS Server None: Conduit only CAS Server extended by Remote Attestation Plug-in; forwards Freshness Handles, Evidence, and Attestation Results; does not appraise Secret Vault RATS Relying Party Invoked in the Retrieval variant of this architecture; seals what it releases to CEKpub, opaquely to CAS Client and CAS Server () Credential Authority RATS Relying Party Invoked in the Enrollment variant of this architecture Verifier Verifier No changes in RATS Verifier role or implementation RATS-Unaware Relying Party None No changes in RUP role or implementation

Credential Acquisition API (CAAPI) The Credential Acquisition API allows the Attester to communicate with the Credential Acquisition System. These APIs are invoked by the Credential Acquisition Interface, covered in the next section. CAAPI can be implemented using any mechanism suitable for interprocess communication, including but not limited to Protobuf/gRPC. Here only the high-level description is provided.

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 (): 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, ) Maximum Evidence age, when the Freshness Kind is absent-timestamp (optional, ) The signature algorithms the Credential Authority accepts for the CSK, when the Credential Acquisition Mode is Enrollment The HPKE suites of the container () 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

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 : 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 CSR bound to the Evidence as specified in ; 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

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 : 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 CEKpub bound to the Evidence as specified in 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

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: CAAPI: Initiate-Credential-Acquisition(Target, Credential Type, Credential Hint) Returns Freshness kind and the Credential Acquisition Mode for this Target and Credential Type Platform Plug-in: Generate keys and Evidence for the Credential Acquisition Mode and Freshness kind returned in step 1, with the binding of , 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 (, 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) 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) 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.

Credential Acquisition Interface (CAI) The Credential Acquisition Interface can be implemented using any mechanism suitable for local communication, including but not limited to statically linked calls and Protobuf/gRPC. Here only the high-level description is provided. The CAI consists of a single Acquire-Credential API, outlined below. The Acquire-Credential implementation follows the recommended CAAPI invocation sequence.

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

Security Considerations

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.

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 () 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 (). 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 (), and checks the freshness element under the Freshness Kind of its policy. The Secret Vault seals what it releases to CEKpub (). 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 (). 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 (). 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 (), 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 ), 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 (). 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: The RATS Relying Party's policy issues or releases nothing beyond what it allows for the attested context, whatever the request says. The Attester sees whether the credential it receives is the one it asked for (, , ). The Freshness Kind is set by the RATS Relying Party's policy for the Target, not by the request (). The Freshness Handle, for the present-* kinds, is originated by the Verifier or by the RATS Relying Party (). 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 (). 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 ). 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 ). 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 (). 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 ().

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.

Credential Scope The binding () 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 ), 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 ). 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 (, ). A deployment that needs a credential usable only at the requested Target issues or releases it with that scope.

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.

IANA Considerations This document has no IANA actions.

This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK] This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK] Federal Information Processing Standard, FIPS JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. RFCs have added to this extension point in both an application-specific and a more general way. The present document defines a number of additional generally applicable control operators for text conversion (bytes, integers, printf-style formatting, and JSON) and for an operation on text. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK] This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. This document defines a channel binding type, tls-exporter, that is compatible with TLS 1.3 in accordance with RFC 5056, "On the Use of Channel Bindings to Secure Channels". Furthermore, it updates the default channel binding to the new binding for versions of TLS greater than 1.2. This document updates RFCs 5801, 5802, 5929, and 7677. Ping Identity Palo Alto Networks Defakto Security Independent Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. Cryptic Forest Software Siemens Fraunhofer SIT Independent Certification Authorities (CAs) issuing certificates to Public Key Infrastructure (PKI) end entities may require a certificate signing request (CSR) to include additional verifiable information to confirm policy compliance. For example, a CA may require an end entity to demonstrate that the private key corresponding to a CSR's public key is secured by a hardware security module (HSM), is not exportable, etc. The process of generating, transmitting, and verifying additional information required by the CA is called remote attestation. While work is currently underway to standardize various aspects of remote attestation, a variety of proprietary mechanisms have been in use for years, particularly regarding protection of private keys. This specification defines ASN.1 structures which may carry attestation data for PKCS#10 and Certificate Request Message Format (CRMF) messages. Both standardized and proprietary attestation formats are supported by this specification. Fraunhofer SIT Fraunhofer SIT Huawei Technologies Cisco Systems This document describes interaction models for remote attestation procedures (RATS) [RFC9334]. Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. Siemens Siemens AKAYLA, Inc. sn3rd When an end entity includes attestation statements in a Certificate Signing Request (CSR), the freshness of the conveyed Evidence often needs to be established. A common mechanism is a nonce that is obtained from a Relying Party or Verifier and included by the Attester in the Evidence. This document specifies how an end entity requests such an attestation freshness nonce from an RA/CA when using certificate lifecycle management protocols. It defines message formats and protocol bindings for the conveyance of nonce request and response messages in the Certificate Management Protocol (CMP), Enrollment over Secure Transport (EST), and Certificate Management over CMS (CMC), including optional type-specific information needed to produce fresh Evidence for inclusion in a CSR. Cisco Selkie Cryptography Updating key exchange and public-key encryption protocols to resist attack by quantum computers is a high priority given the possibility of "harvest now, decrypt later" attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme. In this document, we define KEM algorithms for HPKE based on both post-quantum KEMs and hybrid constructions of post- quantum KEMs with traditional KEMs, as well as a KDF based on SHA-3 that is suitable for use with these KEMs. When used with these algorithms, HPKE is resilient with respect to attacks by a quantum computer. Confidential Computing Consortium Trustworthy Workload Identity SIG Confidential Computing Consortium Trustworthy Workload Identity SIG Confidential Computing Consortium Trustworthy Workload Identity SIG spiffe.io spiffe.io Envoy

Acknowledgments The authors thank the Confidential Computing Consortium's Trustworthy Workload Identity (TWI) Special Interest Group for the definitions and requirements that motivated this work.