| Internet-Draft | ESC | July 2026 |
| Novak, et al. | Expires 7 January 2027 | [Page] |
To be written last¶
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 regulatory and cryptographic review policies. Yet there are significant advantages if clients can be incrementally updated in the trustworthiness of the platform.¶
This document details a protocol by which the trusthworthiness of an Attesters is reviewed as part of the process of it being provided with some form of an Identity Document (a key, or a credential) 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 7 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 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.¶
While updates and upgrades to the workload and the RATS Unaware Party to add a Remote Attestation capability are not possible in this environment, some changes to the Attesting environment are required in order to do anything.¶
The assumption is that the workload may be a compiled object or container provided by a third party. Or the workload may be in a language not easily changed or upgraded with new capabilities. At 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.¶
These workloads run in a virtual machine (VM with unique kernel), or in a containerized environment (common kernel). They never run on bare hardware, and there is a hypervisor and/or orchestration environment that arranges the workload and any needed configurations.¶
However, it is assumed that some the following changes can be made:¶
network connections use mutual TLS, and the origin of the keypair used for client authentication can be changed or configured by an operator¶
the TLS code, while built-in to the application, can be configured to use a Secure Element or TPM as the source for the private key. Current TLS stacks such as OpenSSL can be configured to use engines or providers to do asymmetric operations, and providers exist that talk to a TPM for all private key operations.¶
in the case of bearer token authentication, that the token can be configured external to the code¶
that other components or configurations can be added to the execution environment by the operator¶
that the orchestration environment can be extended with new capabilities without affecting the workload itself¶
A motivating factor in this work is that there are workloads that are mandated to operate in specific geographies under inspection by a local authority. The inspection process by the regulator may include agents that must run within the secured environment, where it may examine inputs and outputs to the workload. These agents do not have the full trust of the workload owners or RATS Unaware Party.¶
The trustworthiness of the workload is not absolute (no trust ever is), however there is a need to provide assurance that only the regulator's agent is present, and no additional malware has been introduced. (For instance, the agent may have exploits known to additional parties, not yet revealed or fixed by the regulator)¶
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 credential. Constrast to a Credential Authority which mints new credentials.¶
The RATS Unaware 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 a JWT, that contains no other identity or authorization claims. It is trusted by the RUP due to local policy.¶
see RUP.¶
an entity performing the role of Attestation Verification, as documented in Section 4 of [RFC9334]¶
A newly created workload connects to the Credential Broker to obtain a set of credentials to be used to perform it's functions.¶
Within this connection, Evidence is transferred to the Credential Broker to demonstrate the workloads' trusthworthiness. The Credential Broker is acting as a RATS Relying Party, the workload is the Attester. The Credential Broker contacts (using the background check model), a Verifier that it trusts in order to evaluate the Evidence, obtaining an Attestation Result.¶
Figure Figure 1 extends the [RFC9334] architecture to show how the workload and credential broker take on the roles of Attester and Relying Party.¶
If the Attestation Result is acceptable, then the Credential Broker provides the set of credentials that the workload needs to accomplish it's 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 Credential Broker 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 to each trustworthy workload.¶
The Credential Broker is a respository for a credential issued by another Identity Provider (IdP). The Credential Broker has both the private key (encrypted) and the certificate, and it discloses these to trustworthy workloads by returning them in a unique encryption, bound to the workload identity.¶
The Credential Broker is a resposity for a bearer token issued by a Resource Owner, or a Workload Identity Tokens (WITs) defined in Section 3.1 of [I-D.ietf-wimse-identifier]. The Credential Broker discloses this to trustworthy workloads by returning them in a unique encryption, bound to the workload identity.¶
The use of a shared assymetric private key 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) (or equivalent) by which they will collect and sign Evidence to be used in the Remote Attestation process.¶
The credential that will be shared by the Credential Broker will be encrypted to a key involved in the Remote Attestation process. The most natural mechanism is to encrypt to a key that is available only to the TPM. The credential are then decrypted by the TPM, and the keypair can then be made available to the workload, while never permitting the workload to ever see the key.¶
In this way, a workload that be designed to do mutual TLS using a client-certificate, and for which the location of the private key can be configured to be in a TPM, can be adapted to the mechanism described in this document without any significant change to the workload itself.¶
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.¶
EST ([RFC7030]) describes a mechanism to enroll with a certification authority using a TLS secured HTTP based protocol.¶
EST is used by the hypervisor (or container orchestrator) to connect to the Identity Provider. The EST protocol is extended to include transmission of Evidence from the Attester to the Identity Provider. This Identity Provider acts as a RATS Relying Party, in Background-Check mode. The Evidence is passed to an appropriately trusted Verifier, and evaluated.¶
Based upon the Attestation Results, the Identity Provide then allows the hypervisor to use the EST /simpleenroll mechanism to provide a CSR, and retrieve an appropriate certificate. The private key for the certificate can be generated within a TPM, never to leave. The hypervisor then inserts the certificate into an appropriate place for inline transmission by mutual TLS.¶
There are three ways to handle 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¶
EST is used by the hypervisor (or container orchestrator) to connect to the Secure Repository The EST protocol is extended to include transmission of Evidence from the Attester to the Secure Repository.¶
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 using one of the mechanisms described in RFC7030. (TBD: This needs more detail, particularly for the mTLS used in the EST)¶
As before, there are three possible ways to transmit the Evidence:¶
via a new, Remote Attestation extension to EST¶
using [I-D.ietf-lamps-csr-attestation] extensions to the CSR itself. The serverkeygen mechanism still sends a CSR, with a fake public key.¶
within TLS itself, using for instance, [I-D.fossati-seat-expat], or whichever protocol the SEAT WG standardizes¶
EST is not appropriate for this use case. Another protocol 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).¶