| Internet-Draft | ESC | July 2026 |
| Novak, et al. | Expires 22 January 2027 | [Page] |
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. Yet there are significant advantages if workloads can be incrementally updated in the trustworthiness of the platform, without disrupting their clients and servers.¶
This document details a protocol by which Remote Attestattion of Attesters is incorporated into the process of them being provided with Identity Documents (keys or credentials) to authenticate to RUPs.¶
This specification illustrates how the RATS Architecture can be applied to interoperate with RUPs by providing Attesters with such Identity Documents.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-bdnr-rats-trustworthy-credentials/.¶
Discussion of this document takes place on the RATS Working Group mailing list (mailto:rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Subscribe at https://www.ietf.org/mailman/listinfo/rats/.¶
Source for this draft and an issue tracker can be found at https://github.com/mcr/twi-rats.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Success of a technology is ultimately measured by its adoption. The RATS Architecture requires that RATS Relying Parties understand Attestation Results expressed using standards such as EAT and AR4SI, execute Appraisal Policy for Attestation Results, and have trust in Verifiers. Additionally, there is an unstated assumption present in the RATS Architecture that a change in Evidence may lead to a change in either the Attestation Results or Appraisal Policy for Attestation Results. This requirement may pose a significant adoption blocker.¶
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 (e.g. Trusted Execution) environment, including Intel SGX, AMD SEV-SNP, ARM TrustZone, 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 Credential Broker, a Key Broker, or a Credential Authority takes on the role of RATS Relying Party. This provides an intermediation between Attestation Results, expressed using formats such as EAT and AR4SI, 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 appropriate Identity Documents. This includes shared symmetric keys, bearer tokens, credentials including PKIX certificates [RFC5280], JWTs [RFC7515], or WIMSE WITs [I-D.ietf-wimse-workload-creds]. In this world, the Attester uses Remote Attestation to obtain from the RATS Relying Party a key, token or credential that is compatible with the RUP.¶
This document details an architecture by which legacy Identity Document issuance mechanisms are replaced with identical Identity Documents issued, but with the additional prerequisite of successful Remote Attestation of the workloads in question.¶
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.¶
Or, as an extreme example, it could be an ancient COBOL program compiled into a WASM object, perhaps connected to the network via virtual paper-tape and virtual printer interfaces.¶
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 key, token, or credential obtained by the workload following Remote Attestation matches that expected by the RUP.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses terms and concepts defined by the WIMSE and RATS architectures, as well as the terms defined by the Trustworthy Workload Identity Special Interest Group at the Confidential Computing Consortium. For a complete glossary, see Section 4 of [RFC9334], [I-D.ietf-wimse-arch] & [TWISIGDef].¶
The definitions of terms like Trustworthy Workload Identity and Workload Credential match those specified by the TWI SIG Definitions [TWISIGDef].¶
an entity that deals out pre-existing keys or credentials. Constrast to a Credential Authority which mints new credentials.¶
a catch-all term for any type of key, token, or credential that is used by the attesting workload to authenticate to the RATS Unaware Relying party.¶
a catch-all term for a service that acts as a Key/Token Broker, Credential Broker, or Credential Authority, that the attesting workload uses to obtain its identity documents following successful remote attestation.¶
The RATS Unaware Relying Party (RUP). A target service that interacts with many clients based upon credentials provided. This is sometimes called the Collaborating Party.¶
[I-D.ietf-wimse-arch] defines 'Workload' as "an instance of software executing for a specific purpose". Here we restrict that definition to the portions of the deployed software and its configuration that are subject to Remote Attestation.¶
the lifespan of the workload. While some workloads can be very long lived, but many workloads are created for a brief period of time, often added on demand to support rising demand, and persisting for only minutes to a small fraction of a day.¶
the entity that manages a workload, arranging to provision it with appropriate Workload Credentials before Workload is launched¶
an ephemeral identity document containing an identity and a number of additional claims, that can be short-lived or long-lived, and that is used to access a service¶
this is a credential, such as an x.509 certificate or a WIMSE WIT, that requires proof of possession (typically an asymmetric signing key) to us. It is considered public information -- the secrecy is in the associated signing key.¶
see RUP.¶
an entity performing the role of Attestation Verification, as documented in Section 4 of [RFC9334]¶
A newly created workload connects to the Identity Document Service (IDS) to obtain a set of Identity Documents to be used to perform its functions.¶
The proposed mechanism works equally well with Background Check and Passport models of RATS. The IDS is acting as a RATS Relying Party, the workload is the Attester.¶
Figure Figure 1 extends the [RFC9334] architecture to show how the workload and IDS take on the roles of Attester and Relying Party. Note in particular that no changes are made to the RATS Architecture; the only change is that the RATS Relying Party is now acting as the IDS, and not the ultimate destination for workload's authentication.¶
If the Attestation Result is acceptable, then the IDS returns the Identity Document that the workload needs to accomplish its task.¶
There are three kinds of credentials that can be involved. Some workloads might use a few of each, possibly with each one being used with a different RATS Unaware Party.¶
The IDS is also an Identity Provider (IdP), and acts as an Registration Authority (possibly including the Certification Authority). It issues new credentials in the form of PKIX certificates or WIMSE WITs to each trustworthy workload, based on attested workload-held private keys.¶
The IDS is a respository for Identity Documents issued by another Identity Provider (IdP). The IDS has both the private key (encrypted) and the proof-of-possession credential, and it discloses these to trustworthy workloads by returning them in a manner that ensures that only authorized workloads can decrypt the private key, typically by encrypting them to an attested, attester-held asymmetric encryption key.¶
The use of a shared assymetric private keys as identity documents is unorthodox. This architecture is justified by the need to rapidly scale the number of workers and to recover from hardware or network failures. The alternatives is that external Identity Providers would need to be willing to respond to spikes of hundreds of credential requests within a small period of time. This would look like a denial of service attack, and it may also require additional human authorization for each.¶
The patterns of communication shown in figure Figure 1 are designed specifically such that as few modifications are required to the workload, and no changes to the Collaborating Party are required.¶
Workloads are expected to include a (virtual) Trusted Platform Module (TPM), a Trusted Execution Environment, or equivalent, by which they will generate collect and sign Evidence to be used in the Remote Attestation process. Workloads are also assumed capable of generating and attesting (including in Evidence) asymmetric encryption or signing keys, the private portions of which never leave the workload, and thus guarantee that no other workload can make make use of these secrets.¶
As there are three major types of credentials that may be used, it is not unreasonable that they may get provisioned in different ways, using different protocols.¶
However, when time comes for the workload to request the Identity Documents, one of three possibilities arise:¶
(Key Broker mode) A cryptographic key encrypted to an attested, Attester-held asymmetric Key Encryption Key¶
(Credential Broker mode) A proof-of-possession credential and a corresponding Credential Signing Key encrypted to an attested, Attester-held asymmetric Key Encryption Key¶
(Identity Provider mode) A freshly minted proof-of-possession credential matching an attested, Attester-held asymmetric Credential Signing Key, or a newly minted short-lived bearer token encrypted to an attested, Attester-held asymmetric Token Encryption Key¶
| Variant | Workload Generates and Attests | IDS Returns |
|---|---|---|
| 1a: Key Broker for proof-of-possession Keys (PPC) | Asymmetric Key Encryption Key (KEK) | Credential Signing Key (CSK) matching PPC, encyprted with the KEK |
| 1b: Key Broker for shared keys | Asymmetric Key Encryption Key (KEK) | Secret Preshared Key (SPK), encrypted with the KEK |
| 2: Credential Broker for proof-of-possession credentials | Asymmetric Key Encryption Key (KEK) | Proof-of-Possession Credential (PPC) and Credential Signing Key (CSK) for PPC, Encrypted with the KEK |
| 3a: Credential Authority for proof-of-possession credentials | Asymmetric Credential Signing Key (CSK) | Newly minted proof-of-possession credential matching the CSK |
| 3b: Credential Authority for short-lived bearer tokens | Asymmetric Token Encryption Key (TEK) | Newly minted short-lived bearer token encrypted with the TEK |
These are explained in more detail below:¶
The Attester generates an asymmetric Key Encryption Key (KEK), and includes its public portion in Evidence during Remote Attestation. The Attester receives from the RATS Relying Party a Secret Key encrypted to the KEK. That Secret Key could be an asymmetric Credential Signing Key for a proof-of-possession credential, such as an x.509 certificate, that is pre-provisioned to the Attester (Variant 1a), or a symmetric key for preshared key scenarios (Variant 1b).¶
The Attester generates an asymmetric Key Encryption Key (KEK), and includes its public portion in Evidence during Remote Attestation. The Attester receives from the RATS Relying Party a pre-provisioned Credential (a WIT or an x.509 certificate) together with its corresponding Credential Signing Key encrypted to the KEK.¶
EST ([RFC7030]) describes a mechanism to obtain a credential and/or a corresponding credential signing key using TLS over HTTP. A few changes are needed to make EST suitable for handling workloads capable of Remote Attestation. In all cases below the EST client hosts the workload, but is not assumed to be inside the workload's TCB. This EST client might be the workload's hypervisor, a container orchestrator, or some other workload hosting environment. Use of authentication by this EST client is OPTIONAL. Even if used, client authentication MUST NOT be used to establish the identity of the workload for purposes of deciding which key, token or credential to return to it. The EST server acts as a RATS Relying Party in Background Check mode. The Evidence is submitted by the workload to the EST server by the EST client acting on its behalf. There are three ways to submit the Evidence:¶
Via a new, Remote Attestation extension to EST¶
Using [I-D.ietf-lamps-csr-attestation] extensions to the CSR itself¶
Within TLS itself, using for instance, [I-D.fossati-seat-expat], or whichever protocol the SEAT WG standardizes (in this case, the workload becomes the EST client)¶
This Evidence is passed by the EST server to a Verifier, and Attestation Results returned by the Verifier are used to establish the identity of the workload.¶
The EST /simpleenroll mechanism is used.¶
The EST /serverkeygen mechanism is used. The server does not generate a fresh key, but rather retrieves the keypair (private key and certificate) from the store. This is encrypted back to the client, however, mechanisms described in RFC7030 need to be modified as any secrets (keys, bearer tokens) must be returned to an attested, attester (workload)-held asymmetric encryption key, not to the EST client directly. (TBD: This needs more detail, particularly for the mTLS used in the EST)¶
EST is not appropriate for this use case. Another protocol or an extension to EST will be required.¶
TBD.¶
All communications between entities (Workload to Credential Authority, Workload to Verifier etc) MUST be secured using mutually authenticated, confidential, and integrity-protected channels (e.g., TLS).¶
In addition to the considerations herein, Verifier, which is a central point of anchor for Trustworthy Workload Identifer MUST follow the security guidance detailed in the "Security and Privacy considerations" as detailed in the RATS Architecture Section 11 and Section 12 of [RFC9334].¶
The credential key MUST always be stored securely at all time, for example in a secure element of the underlying platform running the Workload.¶
There is a risk that a live Workload Migration may render some of the claims about the Workload invalid (e.g., live-migrating a Workload between Germany and France may incorrectly preserve the "Country=Germany" claim, but correctly preserve the "Region=Europe" claim).¶
Remote Attestation of a Workload requires exchange of attestation related messages, for example, Evidence and Attestation Results. This can potentially leak sensitive information about the Workload.¶
Confidentiality: Encryption could be used to prevent unauthorised parties from accessing sensitive information from Evidence or Attestation Results. This is crucial in multi-tenant environments. The Credential Key to be released to a Workload MUST always be encrypted to avoid potential leakage to unauthorised actors.¶
This document has no IANA actions (yet).¶