RATS Working Group M. Novak Internet-Draft J.P. Morgan Chase Intended status: Informational Y. Deshpande Expires: 23 April 2026 Arm H. Birkholz Franhaufer Inst. 20 October 2025 Remote Attestation for Trustworthy Workload Identity draft-novak-twi-attestation-00 Abstract Trustworthy Workloads are workloads that operate in environments that provide isolation of data in use. This document describes how Trustworthy workloads can acquire credentials containing stable identifiers, upon proving the trust in the environments in which they operate via Remote Attestation. About This Document 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-novak-twi-attestation/. 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/. Status of This Memo 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 23 April 2026. Novak, et al. Expires 23 April 2026 [Page 1] Internet-Draft RATS for TWI October 2025 Copyright Notice Copyright (c) 2025 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Available Options . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Mechanism A . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Mechanism B . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Mechanism C . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Mechanisms D . . . . . . . . . . . . . . . . . . . . . . 11 3.4.1. Credential Provisioning Phase . . . . . . . . . . . . 11 3.4.2. Credential Acquisition Phase . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Pivacy Considerations . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction As organisations move more workloads into untrusted or shared environments, protection of data in use becomes increasingly important. One way of isolating data in use is Confidential Computing: executing a workload (for example an AI model, database process or financial service) inside a hardware-based, remotely attested Trusted Execution Environment (TEE). Workloads operating in such environments need stable and trustworthy identifiers to communicate over the network to the external world. Often such identifiers are provided to them via Credential Authorities upon ascertaining trust in the environments in which these workloads operate. The standard practice to establish trust in the operating environment is through Remote Attestation. Novak, et al. Expires 23 April 2026 [Page 2] Internet-Draft RATS for TWI October 2025 This draft specifies how a Workload operating in Confidential Computing Environment can obtain trustworthy, stable, and workload- bound credentials using Remote Attestation. 2. 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 [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.draft-ietf-wimse-arch] & [TWISIGDef]. The definitions of terms like Trustworthy Workload Identity and Workload Credential match those specified by the TWI SIG Definitions [TWISIGDef]. Workload: [I-D.draft-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. Workload Identifier: a stable construct around which Relying Parties can form long-lived Workload authorization policies. Workload Identity: the definition of Workload Identity is identical to the definition of the same term by [I-D.draft-ietf-wimse-arch]: "a combination of three basic building blocks: trust domain, Workload Identifier and identity credentials. Workload Credential: an ephemeral identity document containing the Workload Identifier and a number of additional claims, that can be short-lived or long-lived, and that is used to represent and prove Workload Identity to a Relying Party. Stable Workload Identity, Stable Authorization Policy: a Workload Identity or Authorization Policy is considered Stable if it remains constant in the face of software and hardware changes (updates and rollbacks), so long as those updates and rollbacks are authorized, i.e., comply with the policy of what consitutes the allowed version(s) of the software and hardware in question. Credential Authority: an entity trusted to issue Workload Novak, et al. Expires 23 April 2026 [Page 3] Internet-Draft RATS for TWI October 2025 Credentials Bound Workload Credential: a Workload Credential is considered Bound if it can only be used in conjunction with a secret Credential Key that only a Workload authorized for the use of that Key can obtain, either by generating and certifying it, or by retrieving it from a secure Key Store. Workload Owner: an entity tasked with specifying policies concerning what Workload composition is considered valid for the purposes of issuing Workload Credentials Verifier: an entity performing the role of Attestation Verification, as documented in Section 4 of [RFC9334] 3. Available Options When dealing with a client Workload that is running inside a remotely attested Trusted Execution Environment, the goal of having a Relying Party having a stable authorization policy and utilizing industry- standard mechanisms for authorization can be achieved by issuing Credentials in a relying party-friendly format, such as those specified by [I-D.draft-ietf-wimse-arch]. Such Credentials may take the form of x.509 certificates or Workload Identity Tokens (WITs) defined in Section 3.1 of [WIMSES2S]. A Workload can start using the Credential for authentication and authorization once it has two items in its possession: the public portion – the Workload Credential itself, and the secret Credential Key necessary to utilize this Credential. A Stable authorization policy can only be achieved if Workloads can have Stable identities. The decision about what constitutes a trustworthy Workload and a trustworthy configuration is a composition verification, with multiple entities providing Reference Values for the components they vouch for. For the issued Workload Identity to be Stable in addition to Trustworthy, a mapping must be performed between these Reference Values and the issued Identities. In a typical enterprise, Stable authorization policies are expressed in terms of business- rather than technology-oriented concepts, e.g., "Payroll Application", "Located in Germany", "Cleared for handling Personally Identifiable Information", etc. This contrasts with what RATS has historically thought of as Attestation Results, which may relate to the hardware manufacturer, firmware and software versions, etc. Novak, et al. Expires 23 April 2026 [Page 4] Internet-Draft RATS for TWI October 2025 In some implementations, a Credential is precomputed, and the Credential Key is obtained from a Key Store following successful Remote Attestation. In other implementations, the Workload generates its own Credential Key and uses Remote Attestation to certify it. Within the RATS Architecture, either of these options can be accomplished in one of two ways: 1. The Attestation Results convey to the attesting Workload both the public Credential and the secret Credential Key. 2. The Attestation Results are encoded in an Entity Attestation Token or EAT [RFC9711], or a bespoke Verifier-specific format, and can be used by the attesting Workload to obtain a Bound Credential and an associated Credential Key, e.g., by contacting a Credential Authority and/or a Key Store, but without further involving the Verifier. In either case, the detailed information about the Workload’s composition conveyed to the Verifier using RATS “Evidence” is mapped to Stable, technology-agnostic, business-oriented claims about the Workload. These two options can be visualised at a high level as: // Tracked at: https://github.com/confidential-computing/twi-rats/ issues/5 From the Workload's perspective, Variant 2 carries with it an extra network roundtrip (the first roundtrip being the workload exchanging “Evidence” for “Attestation Results”). It is the only option available to the Workload for using existing Verifier implementations that make no changes associated with this proposal. This option does however introduce additional latency and reliability costs inherent in an extra roundtrip. Variant 1 does not carry with it the extra roundtrip, and thus does not carry the additional performance costs or reliability risks. Several distinct options are possible. In all cases, the Credential is generated and signed by a Credential Authority. The difference is in how the Workload obtains these Credentials. The main pivots are: 1. Where the Credential Key is generated (Key Source): 1. Inside the Workload Instance 2. Inside a secure Key Store such as a Hardware Security Module (HSM), by the Workload Owner Novak, et al. Expires 23 April 2026 [Page 5] Internet-Draft RATS for TWI October 2025 2. Where the Workload gets its Credential from (Credential Source): 1. The Verifier 2. The Credential Authority (e.g., a Certificate Authority, a Security Token Service, or similar) 3. The Workload Owner (via the Control Plane) Note that it is safe to receive the Credential from an untrusted source such as the Control Plane, because it is public. The only requirement is that the obtained Credential matches the Credential Key, which MUST always be obtained securely and only by an authorized Workload instance. Further, under pivot 2.i, the order of interactions involved in Credential generation might differ: 1. A Workload invokes the Verifier which collaborates with the Credential Authority to compute and return Credentials, returning these Credentials inside the Attestation Results, or 2. A Workload invokes the Verifier, obtains from it the Attestation Results, and forwards these Attestation Results to the Credential Authority inside a Credential Request to get the Credential. This set of variants results in several distinct Credential Acquisition Mechanisms (CAMs), some of which are listed in the table below: +=====+==========+============+==================================+ | CAM | Key | Credential | Description | | | Source | Source | | +=====+==========+============+==================================+ | A | Workload | Verifier | A Proof-of-Possession of the | | | | | Credential Key is included in | | | | | the Evidence submitted by the | | | | | Workload Instance to the | | | | | Verifier. The Verifier checks | | | | | the Evidence, then contacts the | | | | | Credential Authority to compute | | | | | a Credential based on this | | | | | Credential Key and returns it to | | | | | the Workload Instance as part of | | | | | Attestation Results. | +-----+----------+------------+----------------------------------+ | B | Workload | Credential | A Proof-of-Possession of the | | | | Authority | Credential Key is included in | Novak, et al. Expires 23 April 2026 [Page 6] Internet-Draft RATS for TWI October 2025 | | | | the Evidence submitted by the | | | | | Workload Instance to the | | | | | Verifier, and also in the | | | | | Attestation Results returned by | | | | | the Verifier. The Workload | | | | | Instance sends the Attestation | | | | | Results obtained from the | | | | | Verifier to the Credential | | | | | Authority, which computes and | | | | | returns to the Workload Instance | | | | | a Credential based on these | | | | | Attestation Results. | +-----+----------+------------+----------------------------------+ | C | Workload | Credential | A Proof-of-Possession of the | | | | Authority | Credential Key is included in a | | | | | Credential Request submitted by | | | | | the Workload to the Credential | | | | | Authority alongside Evidence | | | | | destined for the Verifier. | | | | | Credential Authority handles the | | | | | Credential Request by contacting | | | | | the Verifier on the Workload's | | | | | behalf, supplying the Evidence | | | | | from the Credential Request. | | | | | The Verifier responds with | | | | | Attestation Results which the | | | | | Credential Authority uses to | | | | | compute a Credential, which it | | | | | then returns to the Workload. | +-----+----------+------------+----------------------------------+ | N/A | Workload | Workload | This is not a viable option | | | | Owner | since a Workload that generates | | | | | its own Credential Key MUST | | | | | contact either the Verifier or | | | | | the Credential Authority to | | | | | build a Credential for this Key. | +-----+----------+------------+----------------------------------+ | D | Key | Workload | The Credential is generated and | | | Store | Owner | handed to the Workload by the | | | | | Workload Owner. The Workload | | | | | Owner stores the Credential Key | | | | | in the Key Store. The Workload | | | | | obtains the Credential Key from | | | | | the Key Store after completing | | | | | Remote Attestation. | +-----+----------+------------+----------------------------------+ Table 1 Novak, et al. Expires 23 April 2026 [Page 7] Internet-Draft RATS for TWI October 2025 These options are illustrated below with sequence diagrams. 3.1. Mechanism A +--------------+ +--------------+ +------------------------+ | Workload | | Verifier | | Credential Authority | +------+-------+ +-------+------+ +------------+-----------+ | | | .------+------------------------+----------------------------+-----------. | Credential Acquisition Phase | +------+------------------------+----------------------------+-----------+ | Generate Credential | | +-----------+ Key | | +<----------+ | | | Create Credential Req | | |(incl. Credential Key | | +------------+ Pop) | | +<-----------+ | | | Create Evidence | | | (incl. Credential Req) | | +------------+ | | +<-----------+ | | | Request Attestation | | +----------------------->| | | (Evidence) | Appraise Evidence | | +-----------+ | | |<----------+ | | | Compute Credential | | +-----------+ Attributes | | +<----------+ | │ | Request Credential | │ | (Credential Req+ Attrib) | │ +--------------------------->+ │ | Create & Sign Credential | | | +-------------+ | | +------------>+ │ | | │ | Return Credential | │ Return Credential +<---------------------------+ | in Attestation Results | | +<-----------------------+ | +------+-------+ +-------+------+ +------------+-----------+ | Workload | | Verifier | | Credential Authority | +--------------+ +--------------+ +------------------------+ 3.2. Mechanism B Novak, et al. Expires 23 April 2026 [Page 8] Internet-Draft RATS for TWI October 2025 +--------------+ +--------------+ +------------------------+ | Workload | | Verifier | | Credential Authority | +------+-------+ +-------+------+ +------------+-----------+ | | | .------+------------------------+----------------------------+-----------. | Credential Acquisition Phase | +------+------------------------+----------------------------+-----------+ │ Generate Credential Key | +------------+ | | +<-----------+ | | │ Create Evidence | | | (incl. Credential Key | | +------------+ PoP) | | +<-----------+ | | │ Request Attestation | | +----------------------->+ | │ (Evidence) Appraise Evidence | | +------------+ | | +<-----------+ | │ | Compute Attestation | | | Results | | +------------+ | | +<-----------+ | | Return | | │ Attestation Results | | +<-----------------------+ | │ Create Credential Req. | | | (incl. Credential Key | | +------------+ Pop & AR) | | +<-----------+ | | │ Request Credential (Cre|dential Request) | | +------------------------+--------------------------->+ │ |Convert Attestation Results | │ | to Credential Attributes | | | +-------------+ | | +------------>| │ | Create & Sign Credential | | | +-------------+ | | +------------>| | | Return Credential | │<-----------------------+----------------------------+ +------+-------+ +-------+------+ +------------+-----------+ | Workload | | Verifier | | Credential Authority | +------+-------+ +--------------+ +------------------------+ 3.3. Mechanism C Novak, et al. Expires 23 April 2026 [Page 9] Internet-Draft RATS for TWI October 2025 +--------------+ +------------------------+ +--------------+ | Workload | | Credential Authority | | Verifier | +------+-------+ +------------+-----------+ +-------+------+ | | | .------+-----------------------------+----------------------------+-----------. | Credential Acquisition Phase | +------+-----------------------------+----------------------------+-----------+ │ Generate Credential Key | | +------------+ | | +<-----------+ | | │ Create Evidence | | | (incl. Credential Key | | +------------+ PoP) | | +<-----------+ | | │ Create Credential Request | | +------------+(Evidence, | | | |Credential | | +<-----------+Key PoP) | | | | | │ Request Credential | | +---------------------------->+ │ │ (Credential Request) | Request Attestation | | | (Evidence from | | | Credential Request) | │ +--------------------------->+ │ | Appraise Evidence | | | +-------------+ | | +------------>+ │ | Compute Attestation Results| | | +-------------+ | | +------------>+ │ | Return Attestation Results | │ +<---------------------------+ | | | | |Compute Credential Attrib | | +------------+ (from AR) | | +<-----------+ | │ | Create & Sign Credential | | +------------+ | | +<-----------+ | │ Return Credential | | +<----------------------------+ | +------+-------+ +------------+-----------+ +-------+------+ | Workload | | Credential Authority | | Verifier | +------+-------+ +------------+-----------+ +-------+------+ Novak, et al. Expires 23 April 2026 [Page 10] Internet-Draft RATS for TWI October 2025 3.4. Mechanisms D Mechanism D consists of a "Credential Provisioning" phase followed by the "Credential Acquisition" phase. 3.4.1. Credential Provisioning Phase Novak, et al. Expires 23 April 2026 [Page 11] Internet-Draft RATS for TWI October 2025 +------------------+ +-------------+ +-------------+ +------------------------+ | Workload Owner | | Workload | | Key Store | | Credential Authority | +---------+--------+ +------+------+ +------+------+ +-----------+------------+ | | | | +--------+----------------------+--------------------+-------------------------+-----------+ | Credential Provisioning Phase | +--------+----------------------+--------------------+-------------------------+-----------+ │ Create Workload Identifier | | | and Associated Credential Attributes │ | +------------+ | | | +<-----------+ | | | │ Create Credential Key Release Policy | | | based on Workload Reference Values │ | +------------+ | | | +<-----------+ | | | │ Create Credential Key | | | and Set Key Release Policy | │ +------------------------------------------>+ │ │ │ │ Generate and Store Credential Key | | | and Key Release Policy | | | +------------+ | | | +<-----------+ | │ Return Public Portion of Credential Key | | | or Credential Key Identifier | | +<------------------------------------------+ │ │ Create Credential Request │ │ +----------------------+------------------->+ │ │ | │ Create Credential Request and │ | │ Sign with Private Credential Key | | +------------+ | | | +<-----------+ | │ Return Credential Request | │ +<---------------------+--------------------+ │ │ Request Credential (Credential Request, Workload Identity, Credential Attributes) +----------------------+--------------------------------------------->+ │ │ Create and Sign Credential | | │ | +-------------+ | │ | +------------>+ │ │ | Return Credential | +<---------------------+--------------------+-------------------------+ | Provide Workload with Credential | │ +--------------------->+ | | +---------+--------+ +------+------+ +------+------+ +-----------+------------+ | Workload Owner | | Workload │ | Key Store | | Credential Authority | +------------------+ +-------------+ +-------------+ +------------------------+ 3.4.2. Credential Acquisition Phase Novak, et al. Expires 23 April 2026 [Page 12] Internet-Draft RATS for TWI October 2025 +--------------+ +--------------+ +-------------------+ | Workload | | Verifier | | Key Store | +------+-------+ +-------+------+ +-------+-----------+ | | | .------+------------------------+-----------------------+-----------. | Credential Acquisition Phase | +------+------------------------+-----------------------+-----------+ │ Generate Asymmetric Encryption Key │ +------------+ | | +<-----------+ | | │ Generate Evidence (incl+. Public Encryption | +------------+ | Key) | |<-----------+ | | │ Request Attestation | | +----------------------->+ │ │ (Evidence) | Appraise Evidence | | +------------+ | | +<-----------+ | │ │ Compute Attestation | | +------------+ Results | | +<-----------+ | │ Return | | | Attestation Results | | | (incl. Encryption Key) | | +<-----------------------+ │ │ Request Credential Key (Attestation Results) | +----------------------------------------------->+ │ Validate Attestation Results | │ against Credential Key Release Policy | | | +-------------+ | | +------------>+ │ Encrypt Credential Key to Encryption Key | | | +-------------+ | | +------------>+ │ Return Encrypted Credential Key │ +<-----------------------+-----------------------+ │ Decrypt Credential Key | | +------------+ | | +<-----------+ | | +------+-------+ +-------+------+ +-------+-----------+ | Workload | | Verifier | | Key Store | +------+-------+ +-------+------+ +-------+-----------+ Novak, et al. Expires 23 April 2026 [Page 13] Internet-Draft RATS for TWI October 2025 4. Security Considerations 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 within the workload. 5. Pivacy Considerations 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. 6. IANA Considerations This document has no IANA actions. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References Novak, et al. Expires 23 April 2026 [Page 14] Internet-Draft RATS for TWI October 2025 [I-D.draft-ietf-wimse-arch] Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-06, 30 September 2025, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . [TWISIGCharter] Confidential Computing Consortium Trustworthy Workload Identity SIG, "Trustworthy Workload Identity (TWI) Special Interest Group — Charter", n.d., . [TWISIGDef] Confidential Computing Consortium Trustworthy Workload Identity SIG, "Trustworthy Workload Identity (TWI) Special Interest Group — Definitions", n.d., . [TWISIGReq] Confidential Computing Consortium Trustworthy Workload Identity SIG, "Trustworthy Workload Identity (TWI) Special Interest Group — Requirements", n.d., . [WIMSES2S] IETF, "WIMSE Service-to-Service Protocol", n.d., . Acknowledgments The following persons, in no specific order, contributed to the work directly, participated in design team meetings, or provided valuable comments during the review of this document. Novak, et al. Expires 23 April 2026 [Page 15] Internet-Draft RATS for TWI October 2025 Pieter Kasselman (SPIRL), Arieal Feldman (Google), Mateusz Bronk (Intel), Manu Fontaine (Hushmesh Inc.), Benedict Lau (EQTY Lab), Zvonko Kaiser (NVIDIA), David Quigley (Intel), Sal Kimmich (GadflyAI), Alex Dalton (Shielded Technologies), Eric Wolfe (Mainsail Industries), Nicolae Paladi(Canary Bit), Mark Gentry (JPMorgan Chase), Jag Raman (Oracle), Brian Hugenbruch (IBM), Jens Alberts (Fr0ntierX), Mira Spina (MITRE) and John Suykerbuyk. Authors' Addresses Mark Novak J.P. Morgan Chase Email: mark.f.novak@jpmchase.com Yogesh Deshpande Arm Email: Yogesh.Deshpande@arm.com Henk Birkholz Franhaufer Inst. Email: Henk.Birkholz@ietf.contact Novak, et al. Expires 23 April 2026 [Page 16]