]> J.P. Morgan Chase & Co.

mark.f.novak@jpmchase.com

Sandelman Software Works

mcr+ietf@sandelman.ca

Fraunhofer SIT

Henk.Birkholz@ietf.contact

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 similar to how Envoy does it. 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. About This Document 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 ATestation 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. However, it is common for authentication and authorization policies on Relying Parties to remain static for long periods of time. This is achieved by limiting which entities get to receive the credentials used for authentication and authorization, rather than have the Relying Party make complex decisions based on the credential's changing content. One key requirement for successful deployment of Remote Attestation-capable workloads is minimal blast radius. 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
• Or it may be implemented in a language not easily changed or upgraded with new capabilities
• Further, such a system may require extensive and significant review by an authority before changes to the core algorithm can be made
• Or, finally, 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 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 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
  1. Credential Enrollment (minting new proof-of-possession credential), or
  2. 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: the RATS-unaware Relying Party for which the Attester seeks credentials
• 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 embeds that Handle in Evidence. absent-* kinds return no Handle; the Attester uses a trusted clock, an epoch identifier already held locally, or no freshness claim. The Freshness Kind is one of:

• absent-timestamp: no Freshness Handle is returned; the Attester stamps Evidence from a trusted clock (, Section 10.1)
• absent-none: no Freshness Handle is returned; Evidence carries no freshness claim
• absent-epoch: no Freshness Handle is returned; the Attester embeds an epoch identifier already held locally (, Section 10.3)
• present-nonce: Initiate-Credential-Acquisition returns a single-use nonce as the Freshness Handle; the Attester embeds that Handle in Evidence (, Section 10.2)
• present-epoch: Initiate-Credential-Acquisition returns the current epoch marker as the Freshness Handle; the Attester embeds that Handle in Evidence and retries Initiate-Credential-Acquisition if the epoch has moved (, Section 10.3)

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 fully align with the TWI SIG requirements, while focusing on a portable and extensible implementation.

1. 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.
2. MUST support most current and future credential formats:
   • X.509 Certificates
   • WIMSE Workload Identity Certificates (WICs)
   • WIMSE Workload Identity Tokens (WITs)
   • Bearer tokens (JWTs, API Keys)
   • TPM 2.0 DAA Group Certificates (for Replica workloads)
   • Pre-shared keys
   • Future formats through architectural extensibility
3. SHOULD limit the trust boundary expansion of the Attesting Environment to the minimum
4. MUST support, transparently to the Attester, most current and future Credential Acquisition Mechanisms:
   • EST (RFC 7030)
   • SPIFFE/SPIRE
   • ACMEv2 (RFC 8555)
   • TPM 2.0 DAA Join protocol (based on TPM 2.0 AK Cert)
   • Future mechanisms through architectural extensibility
5. MUST support Workloads utilizing different Credential Acquisition Mechanisms per-target
6. MUST support both Background Check and Passport RATS modes, indistinguishably from the PoV of the Attester
7. MUST support most current and future RATS Verifiers, Credential Authorities, and Secret Vaults, transparently to the Attester
8. MUST NOT assume that the Attester has network access
9. MUST be compatible with all existing and future Confidential Computing platforms meeting minimum requirements around secure cryptography and evidence generation
10. SHOULD restrict visibility of fetched secrets to the Attester, specifically excluding visibility by the CAS Client and CAS Server

Architecture

Attester's Role

1. 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.
2. To acquire credentials, CAI always uses a two-phase sequence:
   1. It requests and obtains a Freshness Kind (); freshness MAY come from the Verifier, or the Relying Party, or MAY even be empty
   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

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, but all appear extensible to accommodate such changes without a lot of additional effort, and without risking backwards compatibility. CAS protocols MUST be able to carry Initiate-Credential-Acquisition; they need not be nonce-based.
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.

Architecture Overview

TACRA architecture ────┐│ │┌──────────────┐ 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]──▼─┐ ┌────▼─────┐ ┌─▼─[RATS RP]─┐ ┌───────▼──────┐ │ │ Secret Vault ├─► RATS ◄─┤ Credential │ ├┤ │ └──────────────┘ │ Verifier │ │ Authority │ │ (Quote, RNG, │ │ └──────────┘ └─────────────┘ │ etc.) │ ┌─▼─[RATS-Unaware RP]───────────────┐ └──────────────┘ │ Existing Unmodified Relying Party │ └───────────────────────────────────┘ ]]>

This Architecture assumes the existence of a Credential Acquisition System (CAS), such as Enrollment over Secure Transport (EST), Secure Production Identity Framework for Everyone (SPIFFE/SPIRE), Automated Certificate Management Environment (ACMEv2), etc., that 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.

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 Mechanisms (enrollment, retrieval) can be provisioned 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 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 remain 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 CSR and includes alongside Evidence CSKpub and the CSR. There MUST exist a binding between the CSR/CSKpub and Evidence. It is possible to include Evidence in the CSR, or vice versa: include the CSR in Evidence. The details of how this is decided at runtime are TBD (TODO: discuss, with reference to ). A Credential Authority MAY use a Credential Hint when assigning a Subject Alternative Name or other certificate properties.
• Retrieval: the Credential Acquisition Interface generates an asymmetric encryption key CEK and includes CEKpub in Evidence. The resulting secrets are encrypted to CEKpub, ensuring that only the Attester in possession of CEKpri can decrypt them. A Secret Vault MAY use a Credential Hint to locate the credential to return.

During both Enrollment and Retrieval, the Attester MAY supply a Credential Hint. The RATS Relying Party MAY reject the request if it will not honor the hint.

Summary of RATS Roles RATS roles in TACRA

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
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; SHOULD encrypt retrieved results to CEKpub in order to keep it from leaking to the 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, e.g., the server URI to which the Attester wishes to authenticate
• Credential Type the Attester plans to use with this Target

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
  • Other TBD pertinent information, such as supported ciphers, etc. (TODO: define)
• On failure: enumerated reason for failure, such as:
  • Invalid Target
  • Unsupported Target
  • Unsupported Credential Type
  • Server error: permission failure
  • Server error: server too busy; try again later
  • Server error: server unreachable
  • etc. (TBD)

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
• Evidence, bound to the previously returned Freshness Handle, if any
• CSR matching, and bound to, the Evidence (TODO: discuss CSR-to-Evidence binding/relationship)
• Credential Hint (optional)

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
  • etc. (TBD)

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
• Evidence, bound to the previously returned Freshness Handle, if any
• CEKpub matching the Evidence (TODO: discuss CEK-to-Evidence binding/relationship)
• 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
  • Invalid Credential Type
  • Rejected or unsupported Credential Hint
  • Server error: failed remote attestation
  • Server error: permission failure
  • Server error: remote attestation failure
  • Server error: server too busy; try again later
  • Server error: server unreachable
  • etc. (TBD)

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)
   • 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:
   • Freshness kind of present-nonce or present-epoch: embed the Freshness Handle in Evidence
   • Freshness kind of absent-timestamp: stamp Evidence from a trusted clock (, Section 10.1)
   • Freshness kind of absent-epoch: embed the locally held epoch marker
   • Freshness kind of absent-none: no freshness claim
   • In all cases, include in Evidence CSKpub plus CSR (enrollment) or CEKpub (retrieval)
3. CAAPI: Depending on which Credential Acquisition Mode is returned, either
   • Enroll-Credential(Target, Credential Type, Credential Hint, CSR, Evidence)
   • Retrieve-Credential(Target, Credential Type, Credential Hint, 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.

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, e.g., the server URI to which the Attester wishes to authenticate
• 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
  • etc. (TBD)

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.

Credential Acquisition System Considered Untrustworthy This architecture seeks to protect credentials acquired by the Attester from disclosure to the Credential Acquisition System. For that reason, it does not treat the Credential Acquisition System as anything other than a conduit between the Attester and the services needed for Remote Attestation and credential issuance. It leaves open the possibility that the CAS Server would retrieve credentials from Secret Vault in plaintext and itself encrypt them with CEKpub so that only the Attester can read them. Likewise, it leaves open the possibility that there is no trust boundary between the Attester and CAS Client, and the CAS Client is therefore capable of inspecting the secrets the Attester generates and the secrets the CAS Server returns. Both of these options are discouraged. The CAS is expected to remain benevolent and not tamper with or leak the traffic between the Attester, the Verifier, and the RATS Relying Parties. However, the CAS is still untrusted, and the burden on protection from such attacks rests with these trusted endpoints.

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.

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. TODO: Define what that binding looks like.

IANA Considerations This document has no IANA actions.

References Normative References 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. 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. Informative References 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 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. Ping Identity CyberArk Defakto Security Intuit 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. Fraunhofer SIT University of Surrey University of Surrey Ubitech Microsoft This document maps the concept of Direct Anonymous Attestation (DAA) to the Remote Attestation Procedures (RATS) Architecture. The protocol entity DAA Issuer is introduced and its mapping with existing RATS roles in DAA protocol steps is specified. Confidential Computing Consortium Trustworthy Workload Identity SIG n.d. Confidential Computing Consortium Trustworthy Workload Identity SIG n.d. Confidential Computing Consortium Trustworthy Workload Identity SIG n.d. spiffe.io n.d. spiffe.io n.d. Envoy n.d.

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.