anima Working Group M. Richardson Internet-Draft Sandelman Software Works Intended status: Standards Track 25 July 2025 Expires: 26 January 2026 Taxonomy of Composite Attesters draft-richardson-rats-composite-attesters-00 Abstract This document further refines different kinds of RFC 9334 Composite Attesters. 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-richardson-rats-composite- attesters/. 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/richardson/rats-composite-attesters. 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 26 January 2026. Richardson Expires 26 January 2026 [Page 1] Internet-Draft composites July 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 1.1. Caveats of Current Definition . . . . . . . . . . . . . . 2 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Level 0 Composite Attester . . . . . . . . . . . . . . . 3 1.4. Level 1 Composite Attester . . . . . . . . . . . . . . . 4 1.5. Level 2 Composite/Hybrid Attester . . . . . . . . . . . . 5 1.6. Level 3B Composite Background-Check Attester . . . . . . 5 1.7. Level 3P Composite Passport-Model Attester . . . . . . . 5 2. Attestation Results as Evidence . . . . . . . . . . . . . . . 6 3. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This document clarifies and extends the meaning of Composite Attester from [RFC9334], Section 3.3. 1.1. Caveats of Current Definition [RFC9334], Section 3.3 says: ``` A composite device is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by the appraisal of all these sub-entities. Richardson Expires 26 January 2026 [Page 2] Internet-Draft composites July 2025 Each sub-entity has at least one Attesting Environment collecting the Claims from at least one Target Environment. Then, this sub-entity generates Evidence about its trustworthiness; therefore, each sub- entity can be called an "Attester". Among all the Attesters, there may be only some that have the ability to communicate with the Verifier while others do not. ``` In this description, it was left vague as to whether or not each Attesting Environment signs the Evidence that it generates, and whether or not the Evidence is evaluated by a Verifier operated by the Lead Attester, or if it's passed by the Lead Attester along with the Evidence from the Lead Target Environment. 1.2. Terminology Lead Attester: This term is from RFC9334, and includes the (Lead) Attesting Environment, and the (Lead) Target Environment. Target Environment: This term is from RFC9334, this refers to the environment for which evidence is gathered. Attesting Environment: This term is from RFC9334, this refers to the thing which gathers the evidence. Component: This is the pieces which are attached to the Lead Attester. There are one to many of these, typically each with their own application specific processor. Component Attesting Environment: This term is new, and refers to an Attesting Environment residing inside a component of the whole. Component Target Environment: This term is new, and refers to an environment for which evidence is collected. 1.3. Level 0 Composite Attester In this first, somewhat degernerate scenario, the Lead Attester has access to the entire memory/environment of all of the components. Examples of situations like this include classic PCI-buses, ISA- buses, VME, S100/IEEE 696-1983. In these situations, secondary components might not boot on their own. (It might even be that the lead environment (the chassis) will place code into RAM for these systems, with no ROM at all) In this case, it is possible for the Lead Attesting Environment to collect Evidence about each of the components without the components having to have their own Attesting Environment. Richardson Expires 26 January 2026 [Page 3] Internet-Draft composites July 2025 At some level, all of these components can be considered part of the same system. In the classic PCI or ISA environment, the components are hard drive interfaces, video interfaces, and network interfaces. For many such systems considering the system to be a composite is unncessary additional complexity. The benefit of applying the composite mechanism in this case is that it is no longer necessary to consider the exhaustive combinatorics of all possible components being attached to the lead attester: it is already the case the reference values for a target environment may change depending upon how much memory is installed. In this Level 0 Composite Attester, the evidence gathered about the components would be included in the Lead Attester's signed Evidence (such as an EAT), as sub-components in UCCS form [RFC9781]. The signature from the Lead Attester applies to all the Evidence, but the Verifier can evaluate each component separately. More modern buses like PCIe, InfiniBand, Thunderbolt, DisplayPort, USB, Firewire and others do not provided direct electrical access to target component system memory. They are serialized versions of the old I/O buses, using a protocol akin to a network. They require non- trivial deserialization at eacn end, requiring configuration via firmware that itself might not be trustworthy. A system with such an interface would be a level 1. 1.4. Level 1 Composite Attester RFC 9334 gives the following example: For example, a carrier-grade router consists of a chassis and multiple slots. The trustworthiness of the router depends on all its slots' trustworthiness. Each slot has an Attesting Environment, such as a TEE, collecting the Claims of its boot process, after which it generates Evidence from the Claims. As described in this case, each component or slot produces it's own signed Evidence. The Lead Attester simply relays the Evidence along with its own: Among these slots, only a "main" slot can communicate with the Verifier while other slots cannot. However, other slots can communicate with the main slot by the links between them inside the router. The main slot collects the Evidence of other slots, produces the final Evidence of the whole router, and conveys the final Evidence to the Verifier. Therefore, the router is a composite device, each slot is an Attester, and the main slot is the lead Attester. Richardson Expires 26 January 2026 [Page 4] Internet-Draft composites July 2025 Note that the Lead Attester does _not_ evaluate the evidence, and does not run its own Verifier. 1.5. Level 2 Composite/Hybrid Attester In this scenario, the Components relay their Evidence to the Lead Attester. The Lead Attester operates a Verifier itself. It evaluates the Components' Evidence against Reference Values, Endorsements, etc. producing _Attestation Results_ These Attestation Results (or their selectively disclosed version: SD-CWT/SD-JWT) are then included as part of the Lead Attester's Evidence to it's Verifier. The Verifier's signing credentials may be part of the same Attesting Environment as the Evidence signing credential used by the Lead Attesting environment. Or they could be in a different environment, such as in a different TEE. 1.6. Level 3B Composite Background-Check Attester In this scenario, the Components relay their Evidence to the Lead Attester. The Lead Attester does _not_ operates a Verifier itself. Instead, the Lead Attester, conveys the Evidence to the Lead Verifier along with it's own Evidence. The Component Evidence is not placed within the Lead Attester's Evidence (DEBATE). The Lead Attester needs to communicate how each component is attached, and that would be within its Evidence. The Lead Verifier, acting a Relying Party, connects to Verifiers capable of evaluating the Component Evidence, retrieving Attestation Results from those Verifiers as part of evaluating the Lead Attester. This case is similar to Level 1, however the integration of the component attestation results in level 1 is not included in the Evidence, while in this case, it is. 1.7. Level 3P Composite Passport-Model Attester In this scenario, the Components relay their Evidence to the Lead Attester. The Lead Attester does _not_ operates a Verifier itself. Instead, the Lead Attester, acting as a Presenter (term To-Be- Defined), connects to an appropriate Verifier, in passport mode. It retrieves an Attestation Result from the Verifier, which it then includes within the Evidence that the Lead Attester produces. Richardson Expires 26 January 2026 [Page 5] Internet-Draft composites July 2025 The Lead Attester's Verifier considers that the Component during it's assessment. It needs to consider if the component has been assessed by a Verifier it trusts, if the component is appropriately connected to the Lead Attester, and if there are an appropriate number of such components. For instance, when accessing a vehicle such as a car, where each tire is it's own component, then a car with three wheels is not trusthworthy. Most cars should have four wheels. A car with five wheels might be acceptable, if at least one wheel is installed into the "spare" holder. (And, it may be of concern if the spare is flat, but the car can still be operated) A more typical digital use case would involve a main CPU with a number of attached specialized intelligent components that contain their own firmware, such as Graphical Processors (GPU), Network Processors (NPU). 2. Attestation Results as Evidence In cases 2, 3B and 3P Attestation Results are included as Evidence. This results in a Verifier that must evaluate these results. It must be able to validate the signatures on the Evidence. This creates _stacked_ Remote Attestation. This is very much different and _distinct_ from [RFC9334], Section 3.2 Layered Attestation. Layered Attestion produces a _single_ set of Evidence, with claims about different layers. 3. Privacy Considerations YYY 4. Security Considerations ZZZ 5. IANA Considerations 6. Acknowledgements Hello. Richardson Expires 26 January 2026 [Page 6] Internet-Draft composites July 2025 7. Changelog 8. References 8.1. Normative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . 8.2. Informative References [RFC9781] Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. Bormann, "A Concise Binary Object Representation (CBOR) Tag for Unprotected CBOR Web Token Claims Sets (UCCS)", RFC 9781, DOI 10.17487/RFC9781, May 2025, . Author's Address Michael Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca Richardson Expires 26 January 2026 [Page 7]