Remote ATtestation ProcedureS H. Birkholz Internet-Draft Fraunhofer SIT Intended status: Standards Track T. Fossati Expires: 5 May 2027 NVIDIA Y. Deshpande arm N. Smith Independent W. Pan Huawei Technologies 1 November 2026 Concise Reference Integrity Manifest draft-ietf-rats-corim-12 Abstract Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-rats-wg/draft-ietf-rats-corim. 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/. Birkholz, et al. Expires 5 May 2027 [Page 1] Internet-Draft CoRIM November 2026 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 5 May 2027. Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology and Requirements Language . . . . . . . . . . 5 1.1.1. Glossary . . . . . . . . . . . . . . . . . . . . . . 6 2. Use of CoRIM in a Verifier . . . . . . . . . . . . . . . . . 9 2.1. Interactions with ACS . . . . . . . . . . . . . . . . . . 10 2.2. Consistency of ACS . . . . . . . . . . . . . . . . . . . 11 3. Typographical Conventions for CDDL . . . . . . . . . . . . . 11 4. Concise Reference Integrity Manifest (CoRIM) . . . . . . . . 12 4.1. CoRIM Map . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.1. CoRIM Identifier . . . . . . . . . . . . . . . . . . 14 4.1.2. Tags . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.3. Locator Map . . . . . . . . . . . . . . . . . . . . . 15 4.1.4. Profile Types . . . . . . . . . . . . . . . . . . . . 15 4.1.5. Entities . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Signed CoRIM . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Signing with Single signature . . . . . . . . . . . . 17 4.2.2. Header Parameters . . . . . . . . . . . . . . . . . . 18 4.2.3. Signing with Multiple Signatures . . . . . . . . . . 21 4.3. Signer authority of securely conveyed unsigned CoRIM . . 23 4.3.1. CoRIM collections . . . . . . . . . . . . . . . . . . 24 5. Concise Module Identifier (CoMID) . . . . . . . . . . . . . . 26 5.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 28 5.1.1. Tag Identity . . . . . . . . . . . . . . . . . . . . 29 5.1.2. Entities . . . . . . . . . . . . . . . . . . . . . . 30 5.1.3. Linked Tag . . . . . . . . . . . . . . . . . . . . . 31 Birkholz, et al. Expires 5 May 2027 [Page 2] Internet-Draft CoRIM November 2026 5.1.4. Triples . . . . . . . . . . . . . . . . . . . . . . . 31 5.1.5. Reference Values Triple . . . . . . . . . . . . . . . 47 5.1.6. Endorsed Values Triple . . . . . . . . . . . . . . . 49 5.1.7. Conditional Endorsement Triple . . . . . . . . . . . 50 5.1.8. Conditional Endorsement Series Triple . . . . . . . . 51 5.1.9. Device Identity Triple . . . . . . . . . . . . . . . 52 5.1.10. Attest Key Triple . . . . . . . . . . . . . . . . . . 53 5.1.11. Triples for domain definition . . . . . . . . . . . . 54 5.1.12. CoMID-CoSWID Linking Triple . . . . . . . . . . . . . 57 5.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 57 5.2.1. Map Extensions . . . . . . . . . . . . . . . . . . . 58 5.2.2. Data Type Extensions . . . . . . . . . . . . . . . . 58 6. CoTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 6.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 59 7. Common Types . . . . . . . . . . . . . . . . . . . . . . . . 59 7.1. Non-Empty . . . . . . . . . . . . . . . . . . . . . . . . 59 7.2. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.3. Validity . . . . . . . . . . . . . . . . . . . . . . . . 60 7.4. UUID . . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.5. UEID . . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.6. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.7. Digest . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.8. Tagged Bytes Type . . . . . . . . . . . . . . . . . . . . 62 8. Reference Verifier . . . . . . . . . . . . . . . . . . . . . 62 8.1. Pseudocode Notation . . . . . . . . . . . . . . . . . . . 62 8.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 62 8.1.2. Types . . . . . . . . . . . . . . . . . . . . . . . . 63 8.1.3. Variables . . . . . . . . . . . . . . . . . . . . . . 63 8.1.4. Functions . . . . . . . . . . . . . . . . . . . . . . 63 8.1.5. Expressions . . . . . . . . . . . . . . . . . . . . . 64 8.1.6. Conditionals . . . . . . . . . . . . . . . . . . . . 64 8.1.7. Iteration . . . . . . . . . . . . . . . . . . . . . . 64 8.1.8. Primitive Operations . . . . . . . . . . . . . . . . 65 8.2. Appraisal Logical Phases . . . . . . . . . . . . . . . . 66 8.3. The CoRIM Processor . . . . . . . . . . . . . . . . . . . 67 8.3.1. High-Level View . . . . . . . . . . . . . . . . . . . 67 8.3.2. Data Structures . . . . . . . . . . . . . . . . . . . 69 8.3.3. Input Validation and Transformation (Phase 1) . . . . 82 8.3.4. ACS Augmentation (Phases 2, 3 and 4) . . . . . . . . 93 8.3.5. Handoff . . . . . . . . . . . . . . . . . . . . . . . 110 8.3.6. Example Appraisal . . . . . . . . . . . . . . . . . . 111 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 126 9.1. Veraison . . . . . . . . . . . . . . . . . . . . . . . . 126 10. Security and Privacy Considerations . . . . . . . . . . . . . 127 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 128 11.1. New COSE Header Parameters . . . . . . . . . . . . . . . 128 11.2. New CBOR Tags . . . . . . . . . . . . . . . . . . . . . 128 11.3. CoRIM Map Registry . . . . . . . . . . . . . . . . . . . 130 Birkholz, et al. Expires 5 May 2027 [Page 3] Internet-Draft CoRIM November 2026 11.4. CoRIM Entity Map Registry . . . . . . . . . . . . . . . 131 11.5. CoRIM Signer Map Registry . . . . . . . . . . . . . . . 133 11.6. CoMID Map Registry . . . . . . . . . . . . . . . . . . . 133 11.7. CoMID Entity Map Registry . . . . . . . . . . . . . . . 134 11.8. CoMID Triples Map Registry . . . . . . . . . . . . . . . 136 11.9. CoMID Measurement Values Map Registry . . . . . . . . . 137 11.10. CoMID Flags Map Registry . . . . . . . . . . . . . . . . 139 11.11. CoTL Map Registry . . . . . . . . . . . . . . . . . . . 140 11.12. New Media Types . . . . . . . . . . . . . . . . . . . . 141 11.12.1. rim+cbor . . . . . . . . . . . . . . . . . . . . . 142 11.12.2. rim+cose . . . . . . . . . . . . . . . . . . . . . 142 11.13. CoAP Content-Formats Registration . . . . . . . . . . . 143 11.14. New Software ID Version Scheme Value . . . . . . . . . . 143 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 143 12.1. Normative References . . . . . . . . . . . . . . . . . . 143 12.2. Informative References . . . . . . . . . . . . . . . . . 146 Appendix A. Base CoRIM CDDL . . . . . . . . . . . . . . . . . . 148 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 161 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 162 1. Introduction The RATS Architecture Section 4 of [RFC9334] specifies several roles, including Endorsers and Reference Value Providers. These two roles are typically fulfilled by supply chain actors, such as manufacturers, distributors, or device owners. Endorsers and Reference Value Providers supply Endorsements (e.g., test results or certification data) and Reference Values (e.g., digests) relating to an Attester. This information is used by a Verifier to appraise Evidence received from an Attester which describes Attester operational state. In a complex supply chain, multiple actors will likely produce these values over several points in time. As such, one supply chain actor might only supply a portion of the Reference Values or Endorsements that otherwise fully characterizes an Attester. Ideally, only the supply chain actor who is the most knowledgeable entity regarding a particular component will supply Reference Values or Endorsements for that component. Attesters vary across vendors and even across products from a single vendor. Not only can Attesters evolve, requiring new measurement types to be expressed, but an Endorser may also want to provide new security relevant attributes about an Attester at a future point in time. Birkholz, et al. Expires 5 May 2027 [Page 4] Internet-Draft CoRIM November 2026 In order to promote interoperability, consistency and accuracy in the representation of Endorsements and Reference Values this document specifies a data model for Endorsements and Reference Values known as Concise Reference Integrity Manifests (CoRIM). The CoRIM data model is expressed in CDDL which is used to realize a CBOR [STD94] encoding suitable for cryptographic operations (e.g., hashing, signing, encryption) and transmission over computer networks. Additionally, this document describes multiple phases of a Verifier Appraisal and provides an example of a possible use of CoRIM messages from multiple supply chain actors to represent a homogeneous representation of Attester state. CoRIM is extensible to accommodate supply chain diversity while supporting a common representation for Endorsement and Reference Value inputs to Verifiers. In essence, the goal of a CoRIM is to describe expected Attester state to Verifiers. This document is divided into two parts. The core data model is described in Section 4, Section 5 and Section 6. These sections describe the primary CoRIM structures, the Concise Module Identifier (CoMID), which is used to express Endorsements and Reference Values, as well as the Concise Tag Lists (CoTL), which express the currently active sources of Endorsements and Reference Values. Section 8 outlines the architecture of a reference Verifier. The architecture details four phases of the appraisal process that explain how CoRIM inputs are validated, evaluated relative to Evidence, and ultimately accepted as additional expressions of Attester state data. In addition, this document also covers how CoRIMs are used within the reference Verifier. Refer to {#sec-verifier-rec} 1.1. Terminology and Requirements Language 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 RATS architecture. Specifically the terms Attester, Reference Value Provider, Endorser, Verifier Owner, and Relying Party are taken from Section 4 of [RFC9334]. For a complete glossary, see Section 4 of [RFC9334]. This document uses the terms _"actual state"_ and _"reference state"_ as defined in Section 2 of [I-D.ietf-rats-endorsements]. Birkholz, et al. Expires 5 May 2027 [Page 5] Internet-Draft CoRIM November 2026 In this document, the term CoRIM message and CoRIM documents are used as synonyms. A CoRIM data structure can be at rest (e.g., residing in a file system as a document) or can be in flight (e.g., conveyed as a message in a protocol exchange). The bytes composing the CoRIM data structure are the same either way. The terminology from CBOR [STD94], CDDL [RFC8610] and COSE [STD96] applies; in particular, CBOR diagnostic notation is defined in Section 8 of [STD94] and Appendix G of [RFC8610]. Terms and concepts are always referenced as proper nouns, i.e., with Capital Letters. 1.1.1. Glossary This document uses the following terms: Appraisal Claims Set (ACS): A structure that holds Environment-Claim Tuples that have been appraised. The ACS contains Attester state that has been authorized by Verifier processing and Appraisal Policy. Appraisal Policy: A description of the conditions that, if met, allow appraisal of Claims. Typically, the entity asserting a Claim should have knowledge, expertise, or context that gives credibility to the assertion. Appraisal Policy resolves which entities are credible and under what conditions. See also "Appraisal Policy for Evidence" in [RFC9334]. Attribute Path: A sequence of one or more attribute identifiers that denotes a value within a structured data object by successive selection from a root value. Each identifier in the sequence names the next attribute to select; the final identifier in the sequence names the value reached by the path. An Attribute Path is said to be *defined* in a given value if every prefix of the path exists in that value; otherwise, the path is *undefined* in that value. In this document, structured data objects are typically CBOR maps whose attributes are identified by CDDL member names (for example, instance, class, class-id). Attribute Paths are used when comparing nested data structures during appraisal (see Section 8.3.4.4). Attribute Path Containment: A comparison relation between two structured data objects, conventionally named the *condition* (C) and the *entry* (A), in which C is said to be *contained in* A when: 1. for every Attribute Path defined in C, the same Attribute Path is defined in A; and 2. for each such path, the value in A *satisfies* the value Birkholz, et al. Expires 5 May 2027 [Page 6] Internet-Draft CoRIM November 2026 in C. Attributes present in A but not in C are ignored. Unless otherwise specified for a given attribute type, *satisfies* means that the two values are equal. Type-specific satisfaction rules - including range membership and minimum bound checks - are defined in Section 8.3.4.4.5.1 and in profile extensions (see Section 8.3.4.4.6). See Section 8.3.4.4.1 and Section 8.3.4.4.5 for examples. Authority: The entity that asserts a Claim. Typically, a Claim is asserted using a cryptographic key to digitally sign the Claim. A cryptographic key can be a proxy for a human or organizational entity. Claim: A piece of information, in the form of a key-value pair. See also Section 4.2 of [RFC9334] and Section 2 of [RFC7519]. Within this document, Claims appear in Evidence, a Reference Value or an Endorsement. Class ID: An identifier for an Environment that is shared among similar Environment instances, such as those with the same hardware assembly. See also Section 4.2.4 of [RFC9711]. Collision-Resistant Name: As defined in Section 2 of [RFC7519]: _"A name in a namespace that enables names to be allocated in a manner such that they are highly unlikely to collide with other names. Examples of collision-resistant namespaces include: Domain Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and X.670 Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an administratively delegated namespace, the definer of a name needs to take reasonable precautions to ensure they are in control of the portion of the namespace they use to define the name."_ CoRIM identifiers that function as global keys, such as Tag IDs and Environment identifiers, are Collision-Resistant Names. Composite Attester: A Composite Attester is either a Composite Device (Section 3.3 of [RFC9334]) or a Layered Attester (Section 3.2 of [RFC9334]) or any composition involving a combination of one or more Composite Devices or Layered Attesters. Domain: Birkholz, et al. Expires 5 May 2027 [Page 7] Internet-Draft CoRIM November 2026 A Domain is the hierarchical container used to describe a Composite Attester in terms of its constituent Environments and the compositional relationships among them. Every Environment implicitly defines a Domain; therefore, any triple that creates an Environment also creates a corresponding Domain. Domains exist to organize the structural composition of the Attester, not to introduce additional semantic entities. Endorsed values: A set of characteristics of an Attester that do not appear in Evidence. For example, Endorsed Values may include testing or certification data related to a hardware or firmware module. Endorsed Values are said to be "conditional" when they apply if Attester's actual state matches certain conditions. See also Section 3 of [I-D.ietf-rats-endorsements]. Environment: A logical partition within an Attester. The term "Target Environment" refers to the group of system security metrics that are reported through Evidence. The term "Attesting Environment" refers to the entity that collects and cryptographically signs such security metrics. See also Section 3.1 of [RFC9334]. Environment-Claim Tuple (ECT): A structure containing a set of values that describe a Target Environment plus a set of Measurement / Claim values that describe properties of the Target Environment. The ECT also contains Authority which identifies the entity that authored the ECT. Instance ID: An identifier of an Environment instance, such as the serial number of a hardware module. See also Section 4.2.1 of [RFC9711]. Measurement: A value associated with specific security characteristics of an Attester that influences the trustworthiness of that Attester. The object of a Measurement could be the invariant part of a firmware component loaded into memory during startup, a run-time integrity check (RTIC), a file system object, or a CPU register. A measured object is part of the Attester's Target Environment. Expected, or "golden," Measurements are compiled as Reference Values, which are used by the Verifier to assess the trust state of the Attester. See also [TNC.Arch], and Section 9.5.5 of [TPM2.Part1]. Range Satisfaction: Birkholz, et al. Expires 5 May 2027 [Page 8] Internet-Draft CoRIM November 2026 A value satisfaction relation in which an entry value is said to satisfy a condition value when the entry lies within the bounds expressed by the condition. For example, an int entry satisfies an int-range condition when the entry is within the condition's inclusive bounds (see Section 5.1.4.8), and an svn entry satisfies a tagged-min-svn condition when the entry is greater than or equal to the condition's minimum (see Section 5.1.4.5.4). Reference Values: A set of values that represent the desired or undesired state of an Attester. Reference Values are compared against Evidence to determine whether Attester state is corroborated by a Reference Value Provider. Reference Values with matching Evidence produce "acceptable Claims." See also Section 4.2 of [RFC9334], Section 8.3 of [RFC9334], and Section 2 of [I-D.ietf-rats-endorsements]. Triple: A term derived from the Resource Description Framework (RDF) to mean a statement expressing a relationship between a subject and an object resource. The nature of the relationship between subject and object is expressed via a predicate. In CoRIM, unlike RDF, the predicate of the triple is implicit and is encoded in the triple's name/codepoint. CoRIM triples typically represent assertions made by the CoRIM author regarding Attesting or Target Environments and their security features, such as Measurements and cryptographic key material. See also Section 3.1 of [W3C.rdf11-primer]. 2. Use of CoRIM in a Verifier The Evidence appraisal process can be thought of as a conversation about an Attester, mediated and recorded by the Verifier. The Verifier keeps a strict record of exactly what is being claimed in the various Conceptual Message inputs and, crucially, who is making the claims (known as the "authority"). Authority determines which entity asserts which Claims about an Attester. To achieve this, the Verifier creates an internal scratchpad of Attester state called the Appraisal Claims Set (ACS). The motivation for describing a reference CoRIM Processor is for consistent Verifier operation across the ecosystem. Birkholz, et al. Expires 5 May 2027 [Page 9] Internet-Draft CoRIM November 2026 2.1. Interactions with ACS Multiple parties contribute to the "conversation" about a device's trustworthiness: the device itself (the Attester), the manufacturer (the CoRIM issuer), and potentially the organization relying on the device (the Verifier Owner). The Verifier uses the ACS to determine the actual state of the Attester, as defined by the various entities providing inputs. Different RATS conceptual messages contribute to the construction of an ACS following the requirements in Table 1. +================+========+=========================================+ | Input Type | Source | How the Verifier Updates the ACS | +================+========+=========================================+ | *Evidence* | The | If the device proves its | | | Device | identity, its claims are added to | | | | the ACS and tagged with the | | | | device's authority. | +----------------+--------+-----------------------------------------+ | *Reference | CoRIM | The Verifier checks the Reference | | Values* | | Values in the CoRIM against the | | | | ACS. If a value matches a claim | | | | the device just made, that claim | | | | gets an extra tag noting the | | | | manufacturer agrees with it. | +----------------+--------+-----------------------------------------+ | *Endorsements* | CoRIM | If the device's claims meet | | | | certain expectations in the ACS, | | | | the Verifier adds new, broader | | | | claims (Endorsed Values) to the | | | | ACS, tagged with the | | | | manufacturer's authority. | +----------------+--------+-----------------------------------------+ Table 1: Conceptual Message Representation Requirements _Note: If the Attester's Evidence is not matched and corroborated by the manufacturer's Reference Values, the manufacturer's claims do not get added to the ACS._ Birkholz, et al. Expires 5 May 2027 [Page 10] Internet-Draft CoRIM November 2026 2.2. Consistency of ACS To ensure everyone builds these systems consistently, the specification uses CDDL to define both the exact structure of the CoRIM and a theoretical data model for the ACS. However, the exact way a Verifier's software is implemented to realize the internal representation is up to the implementor. Section 8.3 describes these reconciliation principles in detail. Once the ACS is built and the conversation is consistent, the ACS is available for processing of subsequent phases. 3. Typographical Conventions for CDDL The CDDL definitions in this document follow the naming conventions illustrated in Table 2. +========================+===============+==========================+ | Type trait | Example | Typographical convention | +========================+===============+==========================+ | extensible | int / text / | $NAME-type-choice | | type choice | ... | | +------------------------+---------------+--------------------------+ | closed type | int / text | NAME-type-choice | | choice | | | +------------------------+---------------+--------------------------+ | group | ( 1 => int // | $$NAME-group-choice | | choice | 2 => text ) | | +------------------------+---------------+--------------------------+ | group | ( 1 => int, 2 | NAME-group | | | => text ) | | +------------------------+---------------+--------------------------+ | type | int | NAME-type | +------------------------+---------------+--------------------------+ | tagged type | #6.123(int) | tagged-NAME-type | +------------------------+---------------+--------------------------+ | map | { 1 => int, 2 | NAME-map | | | => text } | | +------------------------+---------------+--------------------------+ | flags | &( a: 1, b: 2 | NAME-flags | | | ) | | +------------------------+---------------+--------------------------+ Table 2: Type Traits and Typographical Conventions Birkholz, et al. Expires 5 May 2027 [Page 11] Internet-Draft CoRIM November 2026 4. Concise Reference Integrity Manifest (CoRIM) A CoRIM is a collection of tags and related metadata in a concise CBOR [STD94] encoding. A CoRIM can be digitally signed with a COSE [STD96] signature. A tag is a structured, machine-readable data format used to identify, describe, and manage modules or components of a system. Tags can be of different types: * Concise Module ID (CoMID) tags (Section 5) contain metadata and claims about the hardware and firmware modules. * Concise Software ID (CoSWID) tags ([RFC9393]) are used to identify, describe and manage software components. * Concise Tag List (CoTL) tags (Section 6) contain the list of CoMID and CoSWID tags that the Verifier should consider as "active" at a certain point in time. CoRIM allows for new types of tags to be added in future specifications. For example, Concise Trust Anchor Stores (CoTS) ([I-D.ietf-rats-concise-ta-stores]) is currently being defined as a standard CoRIM extension. Each CoRIM contains an identifier to distinguish a CoRIM from other CoRIMs. CoRIM can also carry the following optional metadata: * A locator, which allows discovery of possibly related RIMs. * A profile identifier, which is used to interpret the information contained in the enclosed tags. A profile allows the base CoRIM CDDL definition to be customized to fit a specific Attester by augmenting the base CDDL data definition via the specified extension points or by constraining types defined. A profile MUST NOT change the base CoRIM CDDL definition's semantics, which includes not changing or overloading names and numbers registered at IANA registries used by this document. For more detail, see Section 4.1.4. * A validity period, which indicates the time period for which the CoRIM contents are valid. * Information about the supply chain entities responsible for the contents of the CoRIM and their associated roles. Birkholz, et al. Expires 5 May 2027 [Page 12] Internet-Draft CoRIM November 2026 A CoRIM can be signed (Section 4.2) using COSE Sign1 to provide end- to-end security to the CoRIM contents. When CoRIM is signed, the protected header carries further identifying information about the CoRIM signer. Alternatively, CoRIM can be encoded as a #6.501 CBOR- tagged payload (Section 4.1) and transported over a secure channel. The following CDDL describes the top-level CoRIM. corim = concise-rim-type-choice concise-rim-type-choice /= tagged-unsigned-corim-map concise-rim-type-choice /= signed-corim See Sections 4 and 5 of [DICE.endorsement] for diagrams and additional information on CoRIM structure. 4.1. CoRIM Map The CDDL specification for the corim-map is as follows and this rule and its constraints MUST be followed when creating or validating a CoRIM map. corim-map = { &(id: 0) => $corim-id-type-choice &(tags: 1) => [ + $concise-tag-type-choice ] ? &(dependent-rims: 2) => [ + corim-locator-map ] ? &(profile: 3) => $profile-type-choice ? &(rim-validity: 4) => validity-map ? &(entities: 5) => [ + corim-entity-map ] * $$corim-map-extension } unsigned-corim-map = corim-map The following describes each child item of this map. * id (index 0): An identifier for a CoRIM. Described in Section 4.1.1. * tags (index 1): An array of one or more CoMID, CoSWID or CoTL tags. Described in Section 4.1.2. * dependent-rims (index 2): One or more services supplying additional, possibly dependent, manifests or related files. Described in Section 4.1.3. Birkholz, et al. Expires 5 May 2027 [Page 13] Internet-Draft CoRIM November 2026 * profile (index 3): An optional profile identifier for the tags contained in this CoRIM. The profile MUST be understood by the CoRIM processor. Failure to recognize the profile identifier MUST result in the rejection of the entire CoRIM. See Section 4.1.4 * rim-validity (index 4): Specifies the validity period of the CoRIM. Described in Section 7.3. * entities (index 5): A list of entities involved in a CoRIM life- cycle. Described in Section 4.1.5. * $$corim-map-extension: This CDDL socket is used to add new information structures to the corim-map. Described in Section 11.3. A corim-map is unsigned, and its tagged form is an entrypoint for parsing a CoRIM, so it is named tagged-unsigned-corim-map. tagged-unsigned-corim-map = #6.501(unsigned-corim-map) 4.1.1. CoRIM Identifier A CoRIM Identifier uniquely identifies a CoRIM instance within the context of a CoRIM issuer. In other words the CoRIM identifier can be used to distinguish CoRIMs that come from the same issuer. The base CDDL definition allows UUID and text identifiers. Other types of identifiers could be defined as needed. $corim-id-type-choice /= tstr $corim-id-type-choice /= uuid-type 4.1.2. Tags A $concise-tag-type-choice is a tagged CBOR payload that carries either a CoMID (Section 5), a CoSWID ([RFC9393]), or a CoTL (Section 6). $concise-tag-type-choice /= tagged-concise-swid-tag $concise-tag-type-choice /= tagged-concise-mid-tag $concise-tag-type-choice /= tagged-concise-tl-tag Birkholz, et al. Expires 5 May 2027 [Page 14] Internet-Draft CoRIM November 2026 4.1.3. Locator Map The locator map contains pointers to repositories where dependent manifests, certificates, or other relevant information can be retrieved by the Verifier. The contents of the locator map are purely advisory. Verifiers are not required to follow these URLs or use the information retrieved from the corresponding resources. ;# import measured-component as eatmc corim-locator-map = { &(href: 0) => uri / [ + uri ] ? &(thumbprint: 1) => eatmc.digest / [ + eatmc.digest ] } The following describes each child element of this type. * href (index 0): a URI or array of alternative URIs identifying locations where the additional resource can be fetched. Every URI in the array identifies the same resource. * thumbprint (index 1): expected digest or an array of digests of the resource identified by href. See Section 7.7. Every digest in the array is computed over the same resource, and each uses a different hash algorithm. 4.1.4. Profile Types Profiling is the mechanism that allows the base CoRIM CDDL definition to be customized to fit a specific Attester. A profile defines which of the optional parts of a CoRIM are required, which are prohibited and which extension points are exercised and how. A profile MUST NOT alter the syntax or semantics of CoRIM types defined in this document. A profile MAY constrain the values of a given CoRIM type to a subset of the values. A profile MAY extend the set of a given CoRIM type using the defined extension points (Section 5.2). Exercised extension points SHOULD preserve the intent of the original semantics. CoRIM profiles SHOULD be specified in a publicly available document. A CoRIM profile can use one of the base CoRIM media types defined in Section 11.12.1 and Section 11.12.2 with the profile parameter set to the appropriate value. Alternatively, it MAY define and register its own media type. Birkholz, et al. Expires 5 May 2027 [Page 15] Internet-Draft CoRIM November 2026 A profile identifier is either an OID [RFC9090] or a URL [STD66]. The profile identifier identifies a documented profile. Any changes to the profile, even the slightest deviation, is considered a different profile that MUST have a different identifier. The CoRIM profile must describe at a minimum the following: (a) how cryptographic verification key material is represented (e.g., using Attestation Keys triples, or CoTS tags), and (b) how key material is associated with the Attesting Environment. The CoRIM profile should also specify whether CBOR deterministic encoding is required. $profile-type-choice /= uri $profile-type-choice /= tagged-oid-type For an example profile definition, see [I-D.fdb-rats-psa-endorsements]. 4.1.5. Entities The CoRIM Entity is an instantiation of the Entity generic (Section 7.2) using a $corim-role-type-choice. The only role defined in this specification for a CoRIM Entity is manifest-creator. The $$corim-entity-map-extension extension socket is empty in this specification. corim-entity-map = entity-map<$corim-role-type-choice, $$corim-entity-map-extension> $corim-role-type-choice /= &(manifest-creator: 1) $corim-role-type-choice /= &(manifest-signer: 2) The corim-entity-map MUST NOT contain two entities with the manifest- signer role. 4.2. Signed CoRIM signed-corim = #6.18(COSE-Sign1-corim) / #6.98(COSE-Sign-corim) Signing a CoRIM follows the procedures defined in CBOR Object Signing and Encryption [STD96]. A CoRIM tag MUST be wrapped either in a COSE_Sign1 structure or a COSE_Sign structure. The COSE_Sign structure may be used when: Birkholz, et al. Expires 5 May 2027 [Page 16] Internet-Draft CoRIM November 2026 1. Multiple authorities need to sign the same unsigned CoRIM payload; or 2. A single authority needs to sign the same unsigned CoRIM payload using different signing algorithms. The CoRIM MUST be signed by the CoRIM creator. Other authorities MAY sign the CoRIM. (See Section 4.2.3 for details on multi-signature CoRIM.) 4.2.1. Signing with Single signature COSE_Sign1 is used when a single signer need to produce a signature over an unsigned CoRIM (tagged-unsigned-corim-map). When using COSE_Sign1 the following CDDL specification defines a restrictive subset of COSE header parameters that MUST be used in the protected header alongside additional information about the CoRIM encoded in a corim-meta-map (Section 4.2.2.3) or alternatively in a CWT-Claims ([RFC9597]). COSE-Sign1-corim = [ protected: bstr .cbor protected-corim-header-map unprotected: unprotected-corim-header-map payload: bstr .cbor tagged-unsigned-corim-map / hash-envelope-digest / nil signature: bstr ] hash-envelope-digest = bstr The following describes each child element of this type. * protected: A CBOR Encoded protected header which is protected by the COSE signature. Contains information as given by Protected Header Map below. * unprotected: A COSE header that is not protected by COSE signature. * payload: When the payload is signed directly, either a CBOR- encoded tagged CoRIM, or nil if it is detached. When the payload is signed indirectly, the digest of a CBOR-encoded tagged CoRIM. * signature: A COSE signature block, as defined in Section 4 of [STD96]. Birkholz, et al. Expires 5 May 2027 [Page 17] Internet-Draft CoRIM November 2026 4.2.2. Header Parameters This section describes the header parameters, that need to be set when a. A single signer need to produce a signature using (COSE_Sign1) object. OR b. When multiple signers, each with different authority, need to sign the same unsigned CoRIM, using COSE_Sign object. In this case each array entry of signature_structure has the header parameters that carry the details of the signature algorithm and signer information as detailed in Section 4.2.3 4.2.2.1. Protected Header Map ; protected corim header map needs to contain at least one of ; corim-meta (8) or CWT-Claims (15) protected-corim-header-map = protected-corim-header-map-inline / protected-corim-header-map-hash-envelope protected-corim-header-map-inline = { &(alg: 1) => int &(content-type: 3) => "application/rim+cbor" meta-group * cose-label => cose-value } protected-corim-header-map-hash-envelope = { &(alg: 1) => int, &(payload_hash_alg: 258) => int &(payload_preimage_content_type: 259) => "application/rim+cbor" ? &(payload_location: 260) => tstr meta-group * cose-label => cose-value } meta-group = (( corim-meta-identity, ? cwt-claims-identity, ) // cwt-claims-identity) corim-meta-identity = (&(corim-meta: 8) => bstr .cbor corim-meta-map) cwt-claims-identity = (&(CWT-Claims: 15) => cwt-claims) Birkholz, et al. Expires 5 May 2027 [Page 18] Internet-Draft CoRIM November 2026 The CoRIM protected header map uses some common COSE header parameters plus additional metadata. Additional metadata can either be carried in a CWT_Claims (index: 15) parameter as defined by [RFC9597], or in a corim-meta map as a legacy alternative, described in Section 4.2.2.3. The following describes each child item of this map. * alg (index 1): An integer that identifies a signature algorithm. Either, when the payload is signed directly: * content-type (index 3): A string that represents the "MIME Content type" carried in the CoRIM payload. Or, when the payload is signed indirectly using a Hash Envelope ([RFC9995]): * payload_hash_alg (index 258): The hash algorithm used to produce the payload. * payload_preimage_content_type (index 259): A string that represents the "MIME Content type" of the CoRIM document used as the pre-image of the payload. * payload_location (index 260): An optional identifier enabling retrieval of the original resource (preimage) identified by the payload. The value of content-type or payload_preimage_content_type is exactly application/rim+cbor, without media type parameters. In particular, the profile parameter is not used in the COSE header, because the profile is carried in the profile field of the corim-map (Section 4.1). At least one of: * CWT-Claims (index 15): A map that contains metadata associated with a signed CoRIM. Described in [RFC9597]. * corim-meta (index 8): A map that contains metadata associated with a signed CoRIM. Described in Section 4.2.2.3. Documents MAY include both CWT-Claims and corim-meta, in which case the signer MUST ensure that their contents are semantically identical: the CWT-Claims issuer (iss) MUST have the same value as signer-name in corim-meta, and the nbf and exp values in the CWT- Claims MUST match the signature-validity in corim-meta. Birkholz, et al. Expires 5 May 2027 [Page 19] Internet-Draft CoRIM November 2026 Additional data can be included in the COSE header map as per (Section 3 of [STD96]). 4.2.2.2. CWT Claims The CWT Claims ([RFC9597]) map identifies the entity that created and signed the CoRIM. This ensures the consumer is able to identify credentials used to authenticate its signer. To avoid any possible ambiguity with the contents of the CoRIM tags, the CWT Claims map MUST NOT contain claims that have semantic overlap with the information contained in CoRIM tags. The following describes each child item of this group. * iss (index 1): Issuer or signer for the CoRIM, formerly signer- name or signer-uri in Section 4.2.2.4. * sub (index 2): Optional - identifies the CoRIM document, equivalent to a string representation of $corim-id-type-choice Additional data can be included in the CWT Claims, as per [RFC8392], such as: * exp (index 4): Expiration time, formerly signature-validity in Section 7.3. * nbf (index 5): Not before time, formerly signature-validity in Section 7.3. 4.2.2.3. Meta Map The CoRIM meta map identifies the entity or entities that create and sign the CoRIM. This ensures the consumer is able to identify credentials used to authenticate its signer. corim-meta-map = { &(signer: 0) => corim-signer-map ? &(signature-validity: 1) => validity-map } The following describes each child item of this group. * signer (index 0): Information about the entity that signs the CoRIM. Described in Section 4.2.2.4. * signature-validity (index 1): Validity period for the CoRIM. Described in Section 7.3. Birkholz, et al. Expires 5 May 2027 [Page 20] Internet-Draft CoRIM November 2026 4.2.2.4. Signer Map corim-signer-map = { &(signer-name: 0) => $entity-name-type-choice ? &(signer-uri: 1) => uri * $$corim-signer-map-extension } * signer-name (index 0): Name of the organization that performs the signer role * signer-uri (index 1): A URI identifying the same organization * $$corim-signer-map-extension: Extension point for future expansion of the Signer map. 4.2.2.5. Unprotected CoRIM Header Map unprotected-corim-header-map = { * cose-label => cose-value } 4.2.3. Signing with Multiple Signatures When using COSE_Sign the following CDDL specification defines the overall structure. COSE-Sign-corim = [ protected: bstr .cbor protected-corim-header-map unprotected: unprotected-corim-header-map payload: bstr .cbor tagged-unsigned-corim-map / hash-envelope-digest / nil signature: [+ signature-structure] ] The following describes each child element of this type. * protected: The top level protected header parameter. Contains the information pertaining to the signature algorithm and signer details of the authority producing the signature. Refer to Section 4.2.3.2 for details. * unprotected: The top level unprotected header parameter. Refer to Section 4.2.3.2 for details. Birkholz, et al. Expires 5 May 2027 [Page 21] Internet-Draft CoRIM November 2026 * payload: When the payload is signed directly, this element contains either a CBOR-encoded tagged CoRIM, or nil if it is detached. When the payload is signed indirectly, the digest of a CBOR-encoded tagged CoRIM. * signature: This element contains an array of signature structures, as defined in Section 4.2.3.1. 4.2.3.1. Signature Parameters of Multi Sign CoRIM The signature parameter of a COSE_Sign object contains an array of signature structures that has Header parameters along with signature bytes. These header parameters contain information relating to the content, as well as details about the signer performing the signature. signature-structure = [ protected: bstr .cbor protected-corim-header-map unprotected: unprotected-corim-header-map signature: bstr ] The following describes each element of signature_structure. * protected: A CBOR Encoded protected header which is protected by the COSE signature. * unprotected: A COSE header that is not protected by the COSE signatur. * signature: A COSE signature block, as defined in Section 4 of [STD96]. Refer to section Section 4.2.3.2 when setting the above parameters 4.2.3.2. Use of Header Parameters and Signatures in COSE_Sign This section provides the order in which the protected and unprotected header parameters should be set, along with an array of signature structures in a COSE_Sign object. * Single Signer, multiple signing algorithms: Birkholz, et al. Expires 5 May 2027 [Page 22] Internet-Draft CoRIM November 2026 1. The top-level protected and unprotected header parameters, as specified in Section 4.2.3, are populated first. These parameters identify the signature algorithm and the authority responsible for signing the CoRIM. The corresponding signature bytes are carried in the signature element of the first entry in the signatures array. 2. For each subsequent entry in the signatures array, the associated protected and unprotected header parameters identify the signing algorithm used to generate the corresponding signature. The signature bytes are carried in the signature element of that entry. * Multiple Signers 1. The top-level protected and unprotected header parameters, as specified in Section 4.2.3, are populated first, using the header parameter definitions provided in Section 4.2.2. These parameters identify the signing algorithm and the authority of the CoRIM creator i.e the entity responsible for signing the CoRIM. The corresponding signature bytes are carried in the signature element of the first entry in the signature-structure array. 2. Each subsequent entry in the signature-structure array contains the signature algorithm, signer identification information, and corresponding signature bytes associated with a distinct signing authority. Each authority independently signs the same unsigned CoRIM payload, with header parameters as defined in Section 4.2.2. 4.3. Signer authority of securely conveyed unsigned CoRIM An unsigned (#6.501-tagged) CoRIM may be a payload in an enveloping signed document (e.g., [RFC5280]), or it may be conveyed unsigned within the protection scope of a secure channel. The CoRIM signer authority is taken from the authenticated credential (e.g., OAUTH token) of the entity that originates the CoRIM. For example, this entity could be the sending peer in a secure channel. A CoRIM role entry expressing the origin of the unsigned CoRIM (i.e., the enveloping signed document or the origin endpoint of the secure channel) via the manifest-signer role MUST be added to corim-entity- map. If the authority cannot be expressed directly via the existing authority types, the receiver SHOULD establish a local authority in one of the supported authority formats (e.g., if an unsigned CoRIM is received over a secure channel where authentication is token- or password-based). If it is impossible to assert the authority of the origin, the Verifier's appraisal policy MAY assert the Verifier's Birkholz, et al. Expires 5 May 2027 [Page 23] Internet-Draft CoRIM November 2026 authority as the CoRIM origin. It is out of scope of this document to specify a method of delegating the signer role in the case that an unsigned CoRIM is conveyed through multiple secured links with different notions of authenticity without end-to-end integrity protection. 4.3.1. CoRIM collections Several CoRIMs may share the same signer (e.g., as collection payload in a different signed message) and use locally-resolvable references to each other, for example using a RATS Conceptual Message Wrapper (CMW) [I-D.ietf-rats-msg-wrap]. The Collection CMW type is similar to a profile in its way of restricting the shape of the CMW collection. The Collection CMW type for a CoRIM collection SHALL be tag:ietf.org,2026:corim. A COSE_Sign1-signed CoRIM Collection CMW has a similar requirement to a signed CoRIM. The signing operation MUST include either a CWT- Claims or a corim-meta and MAY contain both, in the COSE_Sign1 protected-header parameter. These metadata containers ensure that each CoRIM in the collection has an identified signer. If using other signing envelope formats, (Section 4.3) the CoRIM signing authority MUST be specified. For example, this can be accomplished by adding the manifest-signer role to every CoRIM, or by using a protected header analogous to corim-meta. corim-cbor-collection = { "__cmwc_t" => "tag:ietf.org,2026:corim", + cmw-label => [rim-cbor-content-format, bytes .cbor tagged-unsigned-corim-map] } cmw-label = text / int ; RFC Editor: replace 65000 with the CoAP Content-Format ID assigned to ; application/rim+cbor (TBD1), here and in the example, and remove this note. rim-cbor-content-format = 65000 The Collection CMW MAY use any label for its CoRIMs. If there is a hierarchical structure to the CoRIM Collection CMW, the base entry point SHOULD be labeled 0 in CBOR or "base" in JSON. It is RECOMMENDED to label a CoRIM with its tag-id in string format, where uuid-type string format is specified by [RFC9562]. CoRIMs distributed in a CoRIM Collection CMW MAY declare their interdependence dependent-rims with local resource indicators. It is RECOMMENDED that a CoRIM with a uuid-type tag-id be referenced with URI urn:uuid:_tag-id-uuid-string_. It is RECOMMENDED that a CoRIM with a tstr tag-id be referenced with Birkholz, et al. Expires 5 May 2027 [Page 24] Internet-Draft CoRIM November 2026 tag:ietf.org,2026:corim:local,_tag-id-tstr_. It is RECOMMENDED for a corim-locator-map containing local URIs to afterwards list a nonzero number of reachable URLs as remote references. The following example demonstrates these recommendations for bundling CoRIMs with a common signer but with different profiles. Birkholz, et al. Expires 5 May 2027 [Page 25] Internet-Draft CoRIM November 2026 =============== NOTE: '\' line wrapping per RFC 8792 ================ / cbor-collection / { "__cmwc_t": "tag:ietf.org,2026:corim", "adee8cd4-4e47-461f-b341-2aba3ae4cbda": / cbor-cmw / [/ rim-cbor-content-format / 65000, << / tagged-\ unsigned-corim-map / 501({ / id / 0: h'adee8cd44e47461fb3412aba3ae4cbda', / tags / 1: [/ tagged-concise-mid-tag / 506(<<{ / tag-identity / 1: { / tag-id / 0: h'315cfc0208d548ee9c89906df96e7fb8' }, / triples / 4: { / reference-triples / 0: [[ / ref-env / {/ class / 0: {/ class-id / 0: 560(h'c0de')}\ }, / ref-claims / [{ / mval / 1: { / raw-value / 4: 560(h'\ 6094685f8bb9b67daaf35707bd2c391f536a1df2ce5152c3cc') }}]]]}}>>)], / profile / 3: 32("tag:example.com,2025:example-profile"), / dependent-rims / 2: [{ / href / 0: [ 32("urn:uuid:51a5f633-71c0-45f5-855e-43e8254c1806"), 32("https://example.com/369a6688451240b9b74905b1dd5fae9f.\ corim") ]}]}) >>], "51a5f633-71c0-45f5-855e-43e8254c1806": / cbor-cmw / [/ rim-cbor-content-format / 65000, << / tagged-\ unsigned-corim-map / 501({ / id / 0: h'51a5f63371c045f5855e43e8254c1806', / tags / 1: [/ tagged-concise-swid-tag / 505(<<{ / tag-id / 0: h'369a6688451240b9b74905b1dd5fae9f', / tag-version / 12: 2, / software-name / 1: "Gadget Firmware", / entity / 2: { / entity-name / 31: "ACME Firmware", / role / 33: / software-creator / 2 }}>>)], / profile / 3: 32("tag:example.com,2025:software-profile")})>>] } 5. Concise Module Identifier (CoMID) A CoMID tag contains information about hardware, firmware, or module composition. Birkholz, et al. Expires 5 May 2027 [Page 26] Internet-Draft CoRIM November 2026 Each CoMID has an ID that is used to identify CoMID instances when cross referencing CoMID tags, for example in typed link relations, or in a CoTL tag. A CoMID defines several types of Claims, using "triples" semantics. At a high level, a triple is a statement that links a subject to an object via a predicate. CoMID triples typically encode assertions made by the CoRIM author about Attesting or Target Environments and their security features, for example measurements, cryptographic key material, etc. This specification defines two classes of triples, the Mandatory To Implement (MTI) and the Optional To Implement (OTI). The MTI triples are essential to basic appraisal processing as illustrated in [RFC9334] and [I-D.ietf-rats-endorsements]. Every CoRIM Verifier MUST implement the MTI triples. The OTI class of triples are generally useful across profiles. A CoRIM Verifier SHOULD implement OTI triples. Verifiers may be constrained in various ways that may make implementation of the OTI class infeasible or unnecessary. For example, deployment environments may have constrained resources, limited code size, or limited scope Attesters. MTI Triples: * Reference Values triples: containing Reference Values that are expected to match Evidence for a given Target Environment (Section 5.1.5). * Endorsed Values triples: containing "Endorsed Values", i.e., features about an Environment that do not appear in Evidence. Specific examples include testing or certification data pertaining to a module (Section 5.1.6). * Conditional Endorsement triples: describing one or more conditions that, once matched, result in augmenting the Attester's actual state with the supplied Endorsed Values (Section 5.1.7). OTI Triples: * Conditional Endorsement Series triples: describing conditional endorsements that are evaluated using a special matching algorithm (Section 5.1.7). * Device Identity triples: containing cryptographic credentials - for example, an IDevID - identifying a device (Section 5.1.9). Birkholz, et al. Expires 5 May 2027 [Page 27] Internet-Draft CoRIM November 2026 * Attestation Key triples: containing cryptographic keys that are used to verify the integrity protection on the Evidence received from the Attester (Section 5.1.10). * Trust dependency triples: describing trust relationships between domains, i.e., collection of related environments and their measurements (Section 5.1.11.2). * Domain membership triples: describing topological relationships between (sub-)modules. For example, in a composite Attester comprising multiple sub-Attesters (sub-modules), this triple can be used to define the topological relationship between lead- and sub- Attester environments (Section 5.1.11.1). * CoMID-CoSWID linking triples: associating a Target Environment with existing CoSWID Payload tags (Section 5.1.12). CoMID triples are extensible (Section 5.1.4). Triples added via the extensibility feature MUST be OTI class triples. This document specifies profiles (see Section 5.2). OTI triples MAY be reclassified as MTI using a profile. Conversely, profiles can choose not to _use_ certain MTI triples. Profiles MUST NOT reclassify MTI triples as OTI. 5.1. Structure The CDDL specification for the concise-mid-tag map is as follows and this rule and its constraints MUST be followed when creating or validating a CoMID tag: concise-mid-tag = { ? &(language: 0) => text &(tag-identity: 1) => tag-identity-map ? &(entities: 2) => [ + comid-entity-map ] ? &(linked-tags: 3) => [ + linked-tag-map ] &(triples: 4) => triples-map * $$concise-mid-tag-extension } The following describes each member of the concise-mid-tag map. Birkholz, et al. Expires 5 May 2027 [Page 28] Internet-Draft CoRIM November 2026 * language (index 0): A textual language tag that conforms with IANA "Language Subtag Registry" [IANA.language-subtag-registry]. The context of the specified language applies to all sibling and descendant textual values, unless a descendant object has defined a different language tag. Thus, a new context is established when a descendant object redefines a new language tag. All textual values within a given context MUST be considered expressed in the specified language. * tag-identity (index 1): A tag-identity-map containing identification information for the CoMID. Described in Section 5.1.1. * entities (index 2): Provides information about one or more organizations responsible for producing the CoMID tag. Described in Section 5.1.2. * linked-tags (index 3): A list of one or more linked-tag-map providing typed relationships between this and other CoMIDs. Described in Section 5.1.3. * triples (index 4): One or more triples providing information specific to the described module, e.g.: reference or endorsed values, cryptographic material, or structural relationship between the described module and other modules. Described in Section 5.1.4. 5.1.1. Tag Identity tag-identity-map = { &(tag-id: 0) => $tag-id-type-choice ? &(tag-version: 1) => tag-version-type } The following describes each member of the tag-identity-map. * tag-id (index 0): An identifier for the CoMID. Described in Section 5.1.1.1. * tag-version (index 1): Optional versioning information for the tag-id. Described in Section 5.1.1.2. 5.1.1.1. Tag ID $tag-id-type-choice /= tstr $tag-id-type-choice /= uuid-type Birkholz, et al. Expires 5 May 2027 [Page 29] Internet-Draft CoRIM November 2026 A Tag ID is either a 16-byte binary string, or a textual identifier referencing the CoMID. The tag identifier MUST be a Collision- Resistant Name (see Section 1.1.1). Failure to ensure collision resistance can create ambiguity in tag use since the tag-id serves as the global key for matching, lookups and linking. If represented as a 16-byte binary string, the identifier MUST be a valid universally unique identifier as defined by [RFC9562], and SHOULD follow the local uniqueness guidance of Section 6.8 of [RFC9562]. There are no strict guidelines on how the identifier is structured, but examples include a 16-byte GUID (e.g., class 4 UUID) [RFC9562], or a URI [STD66], for example urn:example:widget:firmware:1.0.0. 5.1.1.2. Tag Version tag-version-type = uint Tag Version is an integer value that indicates the specific release revision of the tag. Typically, the initial value of this field is set to 0 and the value is increased for subsequent tags produced for the same module release. This value allows a CoMID tag producer to correct an incorrect tag previously released without indicating a change to the underlying module the tag represents. For example, the tag version could be changed to add new metadata, to correct a broken link, to add a missing reference value, etc. When producing a revised tag, the new tag-version value MUST be greater than the old tag-version value. 5.1.2. Entities comid-entity-map = entity-map<$comid-role-type-choice, $$comid-entity-map-extension> The CoMID Entity is an instantiation of entity-map (Section 7.2) using a $comid-role-type-choice. The $$comid-entity-map-extension extension socket is empty in this specification. $comid-role-type-choice /= &(tag-creator: 0) $comid-role-type-choice /= &(creator: 1) $comid-role-type-choice /= &(maintainer: 2) The roles defined for a CoMID entity are: * tag-creator (value 0): creator of the CoMID tag. * creator (value 1): original maker of the module described by the CoMID tag. Birkholz, et al. Expires 5 May 2027 [Page 30] Internet-Draft CoRIM November 2026 * maintainer (value 2): an entity making changes to the module described by the CoMID tag. 5.1.3. Linked Tag The linked tag map represents a typed relationship between the embedding CoMID tag (the source) and another CoMID tag (the target). linked-tag-map = { &(linked-tag-id: 0) => $tag-id-type-choice &(tag-rel: 1) => $tag-rel-type-choice } The following describes each member of the linked-tag-map. * linked-tag-id (index 0): Identifier for the target tag. See Section 5.1.1.1. * tag-rel (index 1): the kind of relation linking the source tag to the target identified by linked-tag-id. $tag-rel-type-choice /= &(supplements: 0) $tag-rel-type-choice /= &(replaces: 1) The relations defined in this specification are: * supplements (value 0): the source tag provides additional information about the module described in the target tag. * replaces (value 1): the source tag corrects erroneous information contained in the target tag. The information in the target MUST be disregarded. 5.1.4. Triples The triples-map contains all the CoMID triples broken down per category. Not all categories need to be present but at least one category MUST be present and contain at least one entry. In most cases, the supply chain entity that is responsible for providing a triple (i.e., Reference Values or Endorsed Values) is by default the CoRIM signer. The signer of a triple is said to be its _authority_. However, multiple authorities may be involved in signing triples. See [STD96]. Consequently, authority may differ for search criteria. See Section 5.1.4.5. Birkholz, et al. Expires 5 May 2027 [Page 31] Internet-Draft CoRIM November 2026 triples-map = non-empty<{ ? &(reference-triples: 0) => [ + reference-triple-record ] ? &(endorsed-triples: 1) => [ + endorsed-triple-record ] ? &(identity-triples: 2) => [ + identity-triple-record ] ? &(attest-key-triples: 3) => [ + attest-key-triple-record ] ? &(dependency-triples: 4) => [ + trust-dependency-triple-record ] ? &(membership-triples: 5) => [ + domain-membership-triple-record ] ? &(coswid-triples: 6) => [ + coswid-triple-record ] ? &(conditional-endorsement-series-triples: 8) => [ + conditional-endorsement-series-triple-record ] ? &(conditional-endorsement-triples: 10) => [ + conditional-endorsement-triple-record ] * $$triples-map-extension }> The following describes each member of the triples-map: * reference-triples (index 0): Triples containing reference values. Described in Section 5.1.5. * endorsed-triples (index 1): Triples containing endorsed values. Described in Section 5.1.6. * identity-triples (index 2): Triples containing identity credentials. Described in Section 5.1.9. * attest-key-triples (index 3): Triples containing verification keys associated with attesting environments. Described in Section 5.1.10. * dependency-triples (index 4): Triples describing trust relationships between domains. Described in Section 5.1.11.2. * membership-triples (index 5): Triples describing topological relationships between (sub-)modules. Described in Section 5.1.11.1. * coswid-triples (index 6): Triples associating modules with existing CoSWID tags. Described in Section 5.1.12. Birkholz, et al. Expires 5 May 2027 [Page 32] Internet-Draft CoRIM November 2026 * conditional-endorsement-series-triples (index 8): Triples describing a series of Endorsements that are applicable based on the acceptance of a condition. Described in Section 5.1.8. * conditional-endorsement-triples (index 10): Triples describing a series of conditional Endorsements based on the acceptance of a stateful environment. Described in Section 5.1.7. 5.1.4.1. Environments An environment-map may be used to represent a whole Attester, an Attesting Environment, or a Target Environment. The exact semantic depends on the context (triple) in which the environment is used. An environment is named after a class, instance or group identifier (or a combination thereof). An environment MUST be identified by a Collision-Resistant Name (see Section 1.1.1). The combination of values within class-map MUST combine to form a Collision-Resistant Name. environment-map = non-empty<{ ? &(class: 0) => class-map ? &(instance: 1) => $instance-id-type-choice ? &(group: 2) => $group-id-type-choice }> The following describes each member of the environment-map: * class (index 0): Contains "class" attributes associated with the module. Described in Section 5.1.4.2. * instance (index 1): Contains an identifier of a module's instance. Described in Section 5.1.4.3. * group (index 2): identifier for a group of instances, e.g., if an anonymization scheme is used. Described in Section 5.1.4.4. 5.1.4.2. Environment Class The Class name consists of class attributes that distinguish the class of environment from other classes. The class attributes include class-id, vendor, model, layer, and index. The CoMID author determines which attributes are needed. Birkholz, et al. Expires 5 May 2027 [Page 33] Internet-Draft CoRIM November 2026 class-map = non-empty<{ ? &(class-id: 0) => $class-id-type-choice ? &(vendor: 1) => tstr ? &(model: 2) => tstr ? &(layer: 3) => uint ? &(index: 4) => uint }> $class-id-type-choice /= tagged-oid-type $class-id-type-choice /= tagged-uuid-type $class-id-type-choice /= tagged-bytes The following describes each member of the class-map: * class-id (index 0): Identifies the environment via a well-known identifier. Typically, class-id is an object identifier (OID) variable-length opaque byte string (Section 7.8) or universally unique identifier (UUID). Use of this attribute is preferred. * vendor (index 1): Identifies the entity responsible for choosing values for the other class attributes that do not already have naming authority. * model (index 2): Describes a product, generation, and family. If populated, vendor MUST also be populated. * layer (index 3): Is used to capture where in a sequence the environment exists. For example, the order in which bootstrap code is executed may have security relevance. * index (index 4): Is used when there are clones (i.e., multiple instances) of the same class of environment. Each clone is given a different index value to disambiguate it from the other clones. For example, given a chassis with several network interface controllers (NIC), each NIC can be given a different index value. 5.1.4.3. Environment Instance An instance-id identifies a Target Environment instance. The identifier is reliably bound to the Target Environment. For example, if an X.509 certificate's subject public key is unique for each instance of a target environment, the instance-id might be created from that subject public key. See Section 4.1 of [RFC5280]. Alternatively, if the certificate's subject public key is large, the instance-id might be a key identifier that is a digest of that public key. See Section 4.2.1.2 of [RFC5280]. The key identifier is reliably bound to the subject public key because the identifier is a digest of the key. Birkholz, et al. Expires 5 May 2027 [Page 34] Internet-Draft CoRIM November 2026 The types defined for an instance identifier are CBOR tagged expressions of UEID, UUID, variable-length opaque byte string (Section 7.8), cryptographic keys, or cryptographic key identifiers. $instance-id-type-choice /= tagged-ueid-type $instance-id-type-choice /= tagged-uuid-type $instance-id-type-choice /= tagged-bytes $instance-id-type-choice /= tagged-pkix-base64-key-type $instance-id-type-choice /= tagged-pkix-base64-cert-type $instance-id-type-choice /= tagged-cose-key-type $instance-id-type-choice /= tagged-key-thumbprint-type $instance-id-type-choice /= tagged-cert-thumbprint-type $instance-id-type-choice /= tagged-pkix-asn1der-cert-type 5.1.4.4. Environment Group A group carries an identifier that is reliably bound to a group of Attesters, for example when a number of Attesters are hidden in the same anonymity set. The types defined for a group identifier are UUID and variable-length opaque byte string (Section 7.8). $group-id-type-choice /= tagged-uuid-type $group-id-type-choice /= tagged-bytes 5.1.4.5. Measurements Measurements can be of a variety of things including software, firmware, configuration files, read-only memory, fuses, IO ring configuration, partial reconfiguration regions, etc. Measurements comprise raw values, digests, or status information. An environment has one or more measurable elements. Each element can have a dedicated measurement or multiple elements could be combined into a single measurement. Measurements can have class, instance or group scope. This is typically determined by the triple's environment. Class measurements apply generally to all the Attesters in a given class. Instance measurements apply to a specific Attester instance. Environments identified by a class identifier have measurements that are common to the class. Environments identified by an instance identifier have measurements that are specific to that instance. Birkholz, et al. Expires 5 May 2027 [Page 35] Internet-Draft CoRIM November 2026 An environment may have multiple measured elements. Measured elements are distinguished from each other by measurement keys. Measurement keys may be used to disambiguate measurements of the same type originating from different elements. Triples that have search conditions may specify authority as matching criteria by populating authorized-by. measurement-map = { ? &(mkey: 0) => $measured-element-type-choice &(mval: 1) => measurement-values-map ? &(authorized-by: 2) => [ + $crypto-key-type-choice ] } The following describes each member of the measurement-map: * mkey (index 0): An optional measurement key. Described in Section 5.1.4.5.1. A measurement-map without an mkey is said to be anonymous. * mval (index 1): The measurements associated with the environment. Described in Section 5.1.4.5.2. * authorized-by (index 2): Identifies the authority, an individual or organization, under whose control an entity asserts Claims. The authority is represented using $crypto-key-type-choice (see Section 5.1.4.6), which binds the Claim to a specific cryptographic identity. The authorized-by element participates in the matching and augmentation process defined in Section 8.3.4, where it provides the conditions under which a Claim is applicable. 5.1.4.5.1. Measurement Keys A Measurement Key is an identifier for a measured element. It can be used to identify the type of measured element (see [I-D.ydb-rats-cca-endorsements]), or to index an SPDM [SPDM] measurements block originating from a specific target environment, or to identify multiple measured element instances within the same environment. The initial types defined are OID, UUID, uint, and tstr. $measured-element-type-choice /= tagged-oid-type $measured-element-type-choice /= tagged-uuid-type $measured-element-type-choice /= uint $measured-element-type-choice /= tstr Birkholz, et al. Expires 5 May 2027 [Page 36] Internet-Draft CoRIM November 2026 5.1.4.5.2. Measurement Values A measurement-values-map contains measurements associated with a certain environment. Depending on the context (triple) in which they are found, elements in a measurement-values-map can represent class or instance measurements. Note that some of the elements have instance scope only. Measurement values may support use cases beyond Verifier appraisal. Typically, a Relying Party determines if additional processing is desirable and whether the processing is applied by the Verifier or the Relying Party. measurement-values-map = non-empty<{ ? &(version: 0) => version-map ? &(svn: 1) => svn-type-choice ? &(digests: 2) => digests-type ? &(flags: 3) => flags-map ? ( &(raw-value: 4) => $raw-value-type-choice, ? &(raw-value-mask-DEPRECATED: 5) => raw-value-mask-type ) ? &(mac-addr: 6) => mac-addr-type-choice ? &(ip-addr: 7) => ip-addr-type-choice ? &(serial-number: 8) => text ? &(ueid: 9) => ueid-type ? &(uuid: 10) => uuid-type ? &(name: 11) => text ? &(cryptokeys: 13) => [ + $crypto-key-type-choice ] ? &(integrity-registers: 14) => integrity-registers ? &(int-range: 15) => int-range-type-choice ? &(bool: 16) => bool-matcher ? &(integer: 17) => integer-matcher ? &(text: 18) => text-matcher ? &(bytes: 19) => bytes-matcher ? &(float: 20) => float-matcher * $$measurement-values-map-extension }> The following describes each member of the measurement-values-map. * version (index 0): Typically changes whenever the measured environment is updated. Described in Section 5.1.4.5.3. * svn (index 1): The security version number typically changes only when a security relevant change is made to the measured environment. Described in Section 5.1.4.5.4. Birkholz, et al. Expires 5 May 2027 [Page 37] Internet-Draft CoRIM November 2026 * digests (index 2): Contains the digest(s) of the measured environment together with the respective hash algorithm used in the process. It uses the digests-type. Described in Section 7.7. * flags (index 3): Describes security relevant operational modes. For example, whether the environment is in a debug mode, recovery mode, not fully configured, not secure, not replay protected or not integrity protected. The flags field indicates which operational modes are currently associated with measured environment. Described in Section 5.1.4.5.5. * raw-value (index 4): Contains the actual (not hashed) value of the element. The vendor determines the encoding of raw-value. When used for comparison, the tagged-masked-raw-value variant includes a mask indicating which bits in the value to compare. Described in Section 5.1.4.5.6. * raw-value-mask-DEPRECATED (index 5): Is an obsolete method of indicating which bits in a raw value to compare. New CoMID files should use the tagged-masked-raw-value on index 4 instead of using index 5. * mac-addr (index 6): An EUI-48 (Extended Unique Identifier 48) or EUI-64 MAC address [IEEE-802.OandA] associated with the measured environment. Described in Section 5.1.4.5.7. * ip-addr (index 7): An IPv4 or IPv6 address associated with the measured environment. Described in Section 5.1.4.5.7. * serial-number (index 8): A text string representing the product serial number. * ueid (index 9): UEID associated with the measured environment. Described in Section 7.5. * uuid (index 10): UUID associated with the measured environment. Described in Section 7.4. * name (index 11): a name associated with the measured environment. * cryptokeys (index 13): identifies cryptographic keys that are protected by the Target Environment See Section 5.1.4.6 for the supported formats. An Attesting Environment determines that keys are protected as part of Claims collection. Appraisal verifies that, for each value in cryptokeys, there is a matching Reference Value entry. Matching is described in Section 8.3.4.4.5.7. Birkholz, et al. Expires 5 May 2027 [Page 38] Internet-Draft CoRIM November 2026 * integrity-registers (index 14): A group of one or more named measurements associated with the environment. Described in Section 5.1.4.7. * int-range (index 15): An integer value or an inclusive integer range that can be compared with linear order. Described in Section 5.1.4.8. Comparison rules are defined in Section 8.3.4.4.5.9. * bool (index 16): A boolean value, compared for exact match. Described in Section 5.1.4.9. Comparison rules are defined in Section 8.3.4.4.5.10. * integer (index 17): An integer value with configurable matching semantics, including range and set matching. Described in Section 5.1.4.9. Comparison rules are defined in Section 8.3.4.4.5.11. * text (index 18): A text string with configurable matching semantics. Described in Section 5.1.4.9. Comparison rules are defined in Section 8.3.4.4.5.13. * bytes (index 19): A byte string with configurable matching semantics. Described in Section 5.1.4.9. Comparison rules are defined in Section 8.3.4.4.5.14. * float (index 20): A floating-point value with configurable matching semantics, including range and set matching. Described in Section 5.1.4.9. Comparison rules are defined in Section 8.3.4.4.5.12. 5.1.4.5.3. Version A version-map contains details about the versioning of a measured environment. ;# import rfc9393 as coswid version-map = { &(version: 0) => text ? &(version-scheme: 1) => coswid.$version-scheme } The following describes each member of the version-map: * version (index 0): the version string Birkholz, et al. Expires 5 May 2027 [Page 39] Internet-Draft CoRIM November 2026 * version-scheme (index 1): an optional indicator of the versioning convention used in the version attribute. Defined in Section 4.1 of [RFC9393] and extended with the binary scheme described in Section 11.14. When the value of the version-scheme is binary, the value of the version field is encoded as base64url (Section 5 of [RFC4648]), without padding. The CDDL (including the new binary version scheme) is copied below for convenience. $version-scheme /= &(multipartnumeric: 1) $version-scheme /= &(multipartnumeric-suffix: 2) $version-scheme /= &(alphanumeric: 3) $version-scheme /= &(decimal: 4) $version-scheme /= &(binary: 5) $version-scheme /= &(semver: 16384) $version-scheme /= int / text 5.1.4.5.4. Security Version Number The following details the security version number (svn) and the minimum security version number (min-svn) statements. A security version number is used to track changes to an object (e.g., a secure enclave, a boot loader executable, a configuration file, etc.) that are security relevant. Rollback of a security relevant change is considered to be an attack vector; as such, security version numbers cannot be decremented. If a security relevant flaw is discovered in the Target Environment and is subsequently fixed, the svn value is typically incremented. There may be several revisions to a Target Environment that are in use at the same time. If there are multiple revisions with different svn values, the revision with a lower svn value may or may not be in a security critical condition. The Endorser may provide a minimum security version number using min-svn to specify the lowest svn value that is acceptable. svn values that are equal to or greater than min- svn do not signal a security critical condition. svn values that are below min-svn are in a security critical condition that is unsafe for normal use. The svn-type-choice measurement consists of a tagged-svn or tagged- min-svn value. The tagged-svn and tagged-min-svn tags are CBOR tags with the values #6.552 and #6.553 respectively. svn-type = uint svn = svn-type min-svn = svn-type tagged-svn = #6.552(svn) tagged-min-svn = #6.553(min-svn) svn-type-choice = svn / tagged-svn / tagged-min-svn Birkholz, et al. Expires 5 May 2027 [Page 40] Internet-Draft CoRIM November 2026 5.1.4.5.5. Flags The flags-map measurement describes a number of boolean operational modes. If a flags-map value is not specified, then the operational mode is unknown. Note that, while the fields may not be completely independent of one another, this specification imposes no restrictions on combinations of the flags-map booleans. However, a profile may restrict the possible flags-map booleans and their valid combinations. flags-map = non-empty<{ ? &(is-configured: 0) => bool ? &(is-secure: 1) => bool ? &(is-recovery: 2) => bool ? &(is-debug: 3) => bool ? &(is-replay-protected: 4) => bool ? &(is-integrity-protected: 5) => bool ? &(is-runtime-meas: 6) => bool ? &(is-immutable: 7) => bool ? &(is-tcb: 8) => bool ? &(is-confidentiality-protected: 9) => bool ? &(is-runtime-updatable: 10) => bool * $$flags-map-extension }> The following describes each member of the flags-map: * is-configured (index 0): If the flag is true, the measured environment is fully configured for normal operation. * is-secure (index 1): If the flag is true, the measured environment's configurable security settings are fully enabled. * is-recovery (index 2): If the flag is true, the measured environment is in recovery mode. * is-debug (index 3): If the flag is true, the measured environment is in a debug enabled mode. * is-replay-protected (index 4): If the flag is true, the measured environment is protected from rollback to previous software images. * is-integrity-protected (index 5): If the flag is true, the measured environment is protected from unauthorized update. * is-runtime-meas (index 6): If the flag is true, the measured environment is measured after being loaded into memory. Birkholz, et al. Expires 5 May 2027 [Page 41] Internet-Draft CoRIM November 2026 * is-immutable (index 7): If the flag is true, the measured environment is immutable. * is-tcb (index 8): If the flag is true, the measured environment is a trusted computing base. * is-confidentiality-protected (index 9): If the flag is true, the measured environment is confidentiality protected. For example, if the measured environment consists of memory, the sensitive values in memory are encrypted. * is-runtime-updatable (index 10): If the flag is true, the measured environment supports being updated at run time without requiring a system reboot for the update to take effect. This is sometimes referred to as "Live Firmware Activation" (LFA) or hitless update or impactless updates. The flag describes a capability of the measured environment; it does not by itself imply that an update has occurred or is pending. 5.1.4.5.6. Raw Values Types Raw value measurements are typically vendor defined values that are checked by Verifiers for consistency only, since the security relevance is opaque to Verifiers. A profile may choose to define more specific semantic meaning to a raw value. A raw-value measurement, or an Endorsement, is a tagged value of type bytes. This specification defines tag #6.560. The default raw value measurement is of type tagged-bytes (Section 7.8). Additional value types can be added to $raw-value-type-choice. These additional values MUST be CBOR tagged bstrs. Constraining all raw value types to be bstr lets Verifiers compare raw values without understanding their contents. A raw value intended for comparison can include a mask value, which selects the bits to compare during appraisal. The mask is applied by the Verifier as part of appraisal. Only the raw value bits with corresponding TRUE mask bits are compared during appraisal. The raw-value-mask-DEPRECATED in measurement-values-map is deprecated, but retained for backwards compatibility. This code point may be removed in a future revision of this specification. Birkholz, et al. Expires 5 May 2027 [Page 42] Internet-Draft CoRIM November 2026 $raw-value-type-choice /= tagged-bytes $raw-value-type-choice /= tagged-masked-raw-value raw-value-mask-type = bytes tagged-masked-raw-value = #6.563([ value: bytes mask : bytes ]) 5.1.4.5.7. Address Types This specification defines types for 48-bit and 64-bit MAC identifiers. For IP addresses, it reuses the "Address Format" types defined in [RFC9164] with the CBOR tag removed. All the types represent a single address. mac-addr-type-choice = eui48-addr-type / eui64-addr-type eui48-addr-type = bytes .size 6 eui64-addr-type = bytes .size 8 ;# import rfc9164 as cbor-ip ip-addr-type-choice /= cbor-ip.ipv4-address ip-addr-type-choice /= cbor-ip.ipv6-address 5.1.4.6. Crypto Keys A cryptographic key can be one of the following formats: * tagged-pkix-base64-key-type: PEM encoded SubjectPublicKeyInfo. Defined in Section 13 of [RFC7468]. * tagged-pkix-base64-cert-type: PEM encoded X.509 public key certificate. Defined in Section 5 of [RFC7468]. * tagged-pkix-base64-cert-path-type: X.509 certificate chain created by the concatenation of as many PEM encoded X.509 certificates as needed. The certificates MUST be concatenated in order so that each directly certifies the one preceding. * tagged-cose-key-type: CBOR encoded COSE_Key or COSE_KeySet. Defined in Section 7 of [STD96]. * tagged-pkix-asn1der-cert-type: a bstr of ASN.1 DER encoded X.509 public key certificate. Defined in Section 4 of [RFC5280]. A cryptographic key digest can be one of the following formats: Birkholz, et al. Expires 5 May 2027 [Page 43] Internet-Draft CoRIM November 2026 * tagged-key-thumbprint-type: a digest (e.g., the SHA-2 hash) of a raw public key. For example, the digest value can be used to locate a public key contained in a lookup table. Ultimately, the discovered keys have to be successfully byte-by-byte compared with the corresponding keys. * tagged-cert-thumbprint-type: a digest of a certificate. The digest value may be used to find the certificate if contained in a lookup table. * tagged-cert-path-thumbprint-type: a digest of a certification path. The digest value may be used to find the certificate path if contained in a lookup table. * tagged-bytes: a key identifier with no prescribed construction method. ;# import measured-component as eatmc $crypto-key-type-choice /= tagged-pkix-base64-key-type $crypto-key-type-choice /= tagged-pkix-base64-cert-type $crypto-key-type-choice /= tagged-pkix-base64-cert-path-type $crypto-key-type-choice /= tagged-cose-key-type $crypto-key-type-choice /= tagged-pkix-asn1der-cert-type $crypto-key-type-choice /= tagged-key-thumbprint-type $crypto-key-type-choice /= tagged-cert-thumbprint-type $crypto-key-type-choice /= tagged-cert-path-thumbprint-type $crypto-key-type-choice /= tagged-bytes tagged-pkix-base64-key-type = #6.554(tstr) tagged-pkix-base64-cert-type = #6.555(tstr) tagged-pkix-base64-cert-path-type = #6.556(tstr) tagged-key-thumbprint-type = #6.557(eatmc.digest) tagged-cose-key-type = #6.558(COSE_Key) tagged-cert-thumbprint-type = #6.559(eatmc.digest) tagged-cert-path-thumbprint-type = #6.561(eatmc.digest) tagged-pkix-asn1der-cert-type = #6.562(bstr) 5.1.4.7. Integrity Registers An Integrity Registers map groups together one or more measured "objects". Each measured object has an identifier and one or more associated digests. Identifiers are either unsigned integers or text strings and their type matters, e.g., unsigned integer 5 is distinct from the text string "5". The digests use digests-type semantics (Section 7.7). Birkholz, et al. Expires 5 May 2027 [Page 44] Internet-Draft CoRIM November 2026 integrity-register-id-type-choice = uint / text integrity-registers = { + integrity-register-id-type-choice => digests-type } All the measured objects in an Integrity Registers map are explicitly named and the order in which they appear in the map is irrelevant. Any digests associated with a measured object represent an acceptable state for the object. Therefore, if multiple digests are provided, the acceptable state is their cross-product. For example, given the following Integrity Registers: { 0: [ [ 0, h'00' ] ], 1: [ [ 0, h'11' ], [ 1, h'12' ] ] } then both { 0: [ 0, h'00' ], 1: [ 0, h'11' ] } and { 0: [ 0, h'00' ], 1: [ 1, h'12' ] } are acceptable states. Integrity Registers can be used to model the PCRs in a TPM or vTPM, in which case the identifier is the register index, or other kinds of vendor-specific measured objects. 5.1.4.8. Int Range An int range describes an integer value that can be compared with linear order in the target environment. An int range is represented with either major type 0 or major type 1 ints. Birkholz, et al. Expires 5 May 2027 [Page 45] Internet-Draft CoRIM November 2026 int-range-type-choice = int / tagged-int-range int-range = [min: int / negative-inf, max: int / positive-inf] tagged-int-range = #6.564(int-range) positive-inf = null negative-inf = null The signed integer range representation is an inclusive range. A min or max of null means that the range is effectively unbounded in that direction. At least one of min and max MUST be non-null; to match any value, the entry is omitted. If both min and max are integers, min MUST be less than or equal to max. An int-range that violates either requirement is malformed, and the tag that contains it MUST be discarded (see Section 8.3.3). 5.1.4.9. Type Matchers The measurement-values-map entries at indices 16-20 support generic boolean, integer, text, byte-string, and floating-point measurements. For the integer, float, text and byte-string entries, matching semantics are configurable: rather than adding a separate codepoint for each desired matching criterion, these entries use CBOR-tagged wrappers to encode the matching logic alongside the value: * Bare (untagged) value means exact match: the target value must equal the entry's value. * CBOR tag 566 (tagged-*-set, integer, float, text and byte-string types only) means set match: the target value must equal one of the values in the array; at least two alternatives MUST be provided. * CBOR tag 565 (tagged-integer-range and tagged-float-range, numeric types only) means range match: the target value must lie within the inclusive [min, max] interval; null means unbounded. If both min and max of a tagged-integer-range or tagged-float-range are non-null, min MUST be less than or equal to max. A tagged- integer-range or tagged-float-range that violates this requirement is malformed, and the tag that contains it MUST be discarded (see Section 8.3.3). The boolean entry (index 16) supports only exact match; see Section 8.3.4.4.5.10 for why this is the case. The numeric type of a value is determined by the codepoint at which it appears: integer (index 17) holds int values and float (index 20) holds float values. Values at different codepoints are never compared with each other, so an integer condition never matches a Birkholz, et al. Expires 5 May 2027 [Page 46] Internet-Draft CoRIM November 2026 float ACS-ECT value, and vice versa, even when they denote the same number. An Evidence transformation algorithm, or the CoRIM profile that defines it, MUST specify the codepoint to which each numeric value it produces is assigned. The range and set forms are meaningful only as a condition, when the measurement-values-map entry appears in a C-ECT. measurement-values- map is also used, unmodified, for ACS-ECTs (the values asserted by Evidence, Reference Values and Endorsements); the CDDL does not by itself distinguish the two uses. An ACS-ECT entry at codepoints 16-20 MUST use the bare, untagged form. The range and set forms MUST NOT be used outside a condition. The comparison rules in Section 8.3.4.4.5.10, Section 8.3.4.4.5.11, Section 8.3.4.4.5.13, Section 8.3.4.4.5.14 and Section 8.3.4.4.5.12 are accordingly defined only for C-ECT values of these codepoints, compared against a bare ACS-ECT value. ; Set match: target value must equal one of the listed alternatives (two or more) tagged-integer-set = #6.566([2* int]) tagged-float-set = #6.566([2* float]) tagged-text-set = #6.566([2* text]) tagged-bytes-set = #6.566([2* bytes]) ; Range match: target value must lie within the inclusive [min, max] interval ; null means unbounded. Defined for numeric types only. tagged-integer-range = #6.565([int / null, int / null]) tagged-float-range = #6.565([float / null, float / null]) ; Composed matchers: the bare type means exact match bool-matcher = bool integer-matcher = int / tagged-integer-range / tagged-integer-set float-matcher = float / tagged-float-range / tagged-float-set text-matcher = text / tagged-text-set bytes-matcher = bytes / tagged-bytes-set Because these entries carry no inherent meaning beyond their primitive type and matching criterion, a profile using them MUST define what measured attribute each entry represents, the unit or encoding of the value, and any constraints on acceptable values beyond what the matcher already expresses. 5.1.5. Reference Values Triple Reference Values Triples describe the possible intended states of an Attester. At any given point in time, an Attester is expected to match only one of these states. Birkholz, et al. Expires 5 May 2027 [Page 47] Internet-Draft CoRIM November 2026 A Reference Values Triple provides reference values pertaining to a Target Environment. In a Reference Value triple, the subject identifies a Target Environment, the object contains reference measurements associated with one or more measured elements of the Environment, and the predicate asserts that these represent the expected state of the Target Environment. The Reference Values Triple has the following structure: reference-triple-record = [ ref-env: environment-map ref-claims: [ + measurement-map ] ] Figure 1: Reference Values Triple Definition The reference-triple-record has the following parameters: * ref-env: Identifies the Target Environment * ref-claims: Contains one or more reference measurements for the Target Environment CoMID triples may contain multiple reference-triple-record entries. Each reference-triple-record describes a reference state for the Target Environment identified by ref-env. Different reference states for a Target Environment MUST be expressed using separate reference- triple-record entries. An exception to the above requirement is when using range types to specify the ref-claims as explained further down. Since a given reference-triple-record can describe only a single Target Environment, the reference state of a device comprising multiple different Target Environments will necessarily be spread across multiple reference-triple-records. In other words, reference- triple-record alone cannot, in the general case, describe the reference state for a complex device. The CoRIM author must therefore rely on other CoMID triples (e.g., conditional endorsements) or profile-specific conventions (e.g., using CoRIM or CoMID boundaries, possibly in conjunction with CoTL) to express the entire reference state of a complex device. Birkholz, et al. Expires 5 May 2027 [Page 48] Internet-Draft CoRIM November 2026 The ref-claims of a given reference-triple-record can contain one or more entries. Each ref-claims entry represents the reference state of a different measured element within the expected overall state of the Target Environment. As an encoding shortcut, some measurement key-value pairs, for example when using int-range, min-svn and integrity-registers, can be defined to encode multiple states simultaneously. To process a reference-triple-record, the ref-env and ref-claims criteria are compared with Evidence entries. First, ref-env is used as search criteria to locate matching Evidence environments. Then, the ref-claims from this triple are used to match against the Evidence measurements for a matched environment. If the search criteria are satisfied, the matching entry is added to the body of Attester state, except these Claims are asserted with the Reference Value Provider's authority. By re-asserting Evidence matched with Reference Values using the RVP's authority, the Verifier avoids confusing Reference Values (reference / possible state) with Evidence (actual state). See [I-D.ietf-rats-endorsements]. Evidence Claims that are re-asserted using RVP authority are said to be "corroborated Evidence" because the actual state in Evidence was found within the corpus of the RVP's possible state. 5.1.6. Endorsed Values Triple Endorsed Values Triples provide additional Endorsements - i.e., claims reflecting actual state - for an existing Target Environment. In an Endorsed Values Triple, the subject identifies a Target Environment, the object contains Endorsement Claims for the Environment, and the predicate asserts that these represent actual state associated with the subject. The Endorsed Values Triple has the following structure: endorsed-triple-record = [ condition: environment-map endorsement: [ + measurement-map ] ] Figure 2: Endorsed Values Triple Definition The endorsed-triple-record has the following parameters: * condition: Search criterion that locates an Evidence, corroborated Evidence, or Endorsements environment. * endorsement: Additional Endorsement Claims. Birkholz, et al. Expires 5 May 2027 [Page 49] Internet-Draft CoRIM November 2026 To process an endorsed-triple-record, its condition is compared with existing Evidence, corroborated Evidence, and Endorsements. If the search criterion is satisfied, the endorsement is added to the Attester's actual state under the Endorser's authority. 5.1.7. Conditional Endorsement Triple Conditional Endorsement Triples declare one or more conditions that, once matched, results in augmenting the Attester's actual state with the Endorsement Claims. The conditions are expressed via stateful- environment-records, which match Target Environments from Evidence in certain reference state. The Conditional Endorsement Triple has the following structure: conditional-endorsement-triple-record = [ conditions: [ + stateful-environment-record ] endorsements: [ + endorsed-triple-record ] ] stateful-environment-record = [ environment: environment-map, claims-list: [ + measurement-map ] ] Figure 3: Conditional Endorsement Triple Definition The conditional-endorsement-triple-record has the following parameters: * conditions: Search criteria that locates Evidence, corroborated Evidence, or Endorsements. * endorsements: Additional Endorsements. To process a conditional-endorsement-triple-record the conditions are compared with existing Evidence, corroborated Evidence, and Endorsements. If the search criteria are satisfied, the endorsements entries are asserted with the Endorser's authority as new Endorsements. Birkholz, et al. Expires 5 May 2027 [Page 50] Internet-Draft CoRIM November 2026 5.1.8. Conditional Endorsement Series Triple The Conditional Endorsement Series Triple is used when an Endorser wants to match Claims of the same type (for example version) but with differing values. If the conditions are met, new Claims are added as Endorsements. For example, if version 1.0 of a component has a Common Vulnerability and Exposure (CVE), but version 2.0 does not, a series condition might contain version = "1.0" and an addition cve = "CVE_PLACEHOLDER". Another series condition might contain version = "2.0" and an addition cve = "CVE_NONE". As soon as the condition value is matched the remaining conditions can be ignored. The Conditional Endorsement Series Triple has two forms of conditions, those that are common to all series list items and those that are specific to a particular item in the series. The common conditions are separated out of the series list for convenience. The Conditional Endorsement Series Triple has the following structure: conditional-endorsement-series-triple-record = [ common-condition: [ environment: environment-map claims-list: [ * measurement-map ] ? authorized-by: [ + $crypto-key-type-choice ] ] series: [ + conditional-series-record ] ] conditional-series-record = [ condition: [ + measurement-map] addition: [ + measurement-map ] ] Figure 4: Conditional Endorsement Series Triple Definition The conditional-endorsement-series-triple-record has the following parameters: * common-condition: Matching conditions that are common to every item in the series. Common conditions include environment-map, (optional) claims-list, and (optional) authorized-by. * series: A list of conditional-series-record items where each item's condition uses the same type of measurements, meaning same label(code point) inside measurement-values-map, but differ in value. Birkholz, et al. Expires 5 May 2027 [Page 51] Internet-Draft CoRIM November 2026 The conditional-series-record has the following elements: * condition: Match conditions where the same type of measurements appear in each series item, but with different values. Each series item is paired with an addition series item. * addition: Claims to be added when its paired condition matches. Addition Claims are added to the ACS record matching common- condition.environment. 5.1.8.1. Matching Considerations For consistent results, every series item condition MUST use the same measurement types; differing only in terms of measurement values. This requirement also extends to use of mkey in measurement-map. Series entries are ordered such that the most precise match is evaluated first and least precise match is evaluated last. The first series condition that matches terminates series matching and the endorsement values are added to the Attester's actual state. These restrictions ensure that evaluation order does not change the meaning of the triple during the appraisal process. Note: authorized-by in common-condition takes precedence over the authorized-by in condition. 5.1.9. Device Identity Triple Device Identity Triples endorse that the listed keys were securely provisioned to the named Target Environment. A single Target Environment (as identified by environment and mkey) may contain one or more cryptographic keys. The existence of these keys is asserted in Evidence, Reference Values, or Endorsements. The device identity keys may have been used to authenticate the Attester device or may be held in reserve for later use. Device Identity Triples instruct a Verifier to perform key validation checks, such as revocation, certification path construction and verification, or proof of possession. If the key is certified (i.e., a certificate is issued for the key by a certification authority), the certification path is validated according to Section 6 of [RFC5280]. The Verifier SHOULD verify keys contained in Device Identity triples. Additional details about how a key was provisioned or is protected may be asserted using Endorsements such as endorsed-triple-records. Birkholz, et al. Expires 5 May 2027 [Page 52] Internet-Draft CoRIM November 2026 Depending on key formatting, as defined by $crypto-key-type-choice, the Verifier may take different steps to locate and verify the key. If a key has usage restrictions that limit its use to device identity challenges, the Verifier SHOULD enforce key use restrictions. Each successful verification of a key in key-list SHALL produce Endorsement Claims that are added to the Attester's Claim set. Claims are asserted with the joint authority of the Endorser (CoRIM signer) and the Verifier. The Verifier MAY report key verification results as part of an error reporting function. identity-triple-record = [ environment: environment-map key-list: [ + $crypto-key-type-choice ] ? conditions: non-empty<{ ? &(mkey: 0) => $measured-element-type-choice, ? &(authorized-by: 1) => [ + $crypto-key-type-choice ] }> ] Figure 5: Device Identity Triple Definition * environment: An environment-map condition used to identify the target Evidence or Reference Value. See Section 5.1.4.1. * key-list: A list of $crypto-key-type-choice keys that identifies which keys are to be verified. See Section 5.1.4.6. * mkey: An optional $measured-element-type-choice condition used to identify the element within the target Evidence or Reference Value. See Section 5.1.4.5.1. * authorized-by: An optional list of $crypto-key-type-choice keys that identifies the authorities that asserted the key-list in the target Evidence or Reference Values. 5.1.10. Attest Key Triple Attest Key Triples endorse that the keys were securely provisioned to the named Attesting Environment. An Attesting Environment (as identified by environment and mkey) may contain one or more cryptographic keys. The existence of these keys is asserted in Evidence, Reference Values, or Endorsements. The attestation keys may have been used to sign Evidence or may be held in reserve for later use. Birkholz, et al. Expires 5 May 2027 [Page 53] Internet-Draft CoRIM November 2026 Attest Key Triples instruct a Verifier to perform key validation checks, such as revocation, certification path construction and validation, or proof of possession. If the key is certified, the certification path is validated according to Section 6 of [RFC5280]. The Verifier SHOULD verify keys contained in Attest Key triples. Additional details about how a key was provisioned or is protected may be asserted using Endorsements such as endorsed-triples. Depending on key formatting, as defined by $crypto-key-type-choice, the Verifier may take different steps to locate and verify the key. If a key has usage restrictions that limits its use to Evidence signing, the Verifier SHOULD enforce key use restrictions. For example, see Section 5.1.5.3 in [DICE.cert]. Each successful verification of a key in key-list SHALL produce Endorsement Claims that are added to the Attester's Claim set. Claims are asserted with the joint authority of the Endorser (CoRIM signer) and the Verifier. The Verifier MAY report key verification results as part of an error reporting function. attest-key-triple-record = [ environment: environment-map key-list: [ + $crypto-key-type-choice ] ? conditions: non-empty< { ? &(mkey: 0) => $measured-element-type-choice, ? &(authorized-by: 1) => [ + $crypto-key-type-choice ] }> ] Figure 6: Attest Key Triple Definition See Section 5.1.9 for additional details. 5.1.11. Triples for domain definition Domain triples assert a graphical description of Attester composition in terms of its constituent Environments and their compositional relationships. The following CDDL describes domain type. domain-type = environment-map Domain structure is defined in terms of directed acyclic graphs (DAG) describing membership and trust dependency using the following types of triples. Birkholz, et al. Expires 5 May 2027 [Page 54] Internet-Draft CoRIM November 2026 5.1.11.1. Domain Membership Triple A Domain Membership Triple (DMT) links a domain identifier to its member Environments. The triple's subject is the domain identifier while the triple's object lists all the member Environments within the domain. The Domain Membership Triple allows an Endorser (for example, an Integrator) to issue an authoritative statement about the composition of an Attester as a collection of Environments. This allows a topological description of an Attester to be expressed by linking a parent Environment (e.g., a lead Attester) to its child Environments (e.g., one or more sub-Attesters). If the Verifier Appraisal policy requires Domain Membership, the Domain Membership Triple is used to match an Attester's reference composition with the actual composition represented in Evidence. Representing members of a DMT as domains enables the recursive construction of an entity's topology, such as a Composite Device (see Section 3.3 of [RFC9334]), where multiple lower-level domains can be aggregated into a higher-level domain. The domain topology MUST be acyclic. domain-membership-triple-record = [ domain-id: domain-type members: [ + domain-type ] ] Figure 7: Domain Membership Triple Definition Domain membership triples are transformed into an internal representation (see Section 8.3.3.7.5) then processed as described in Section 8.3.4.3.4. 5.1.11.2. Trust Dependency Triple A Trust Dependency Triple (TDT) links a domain to a set of _trustee_ domains. A trust dependency triple is used by an Endorser to assert that a trust dependency exists between various components. A TDT specifies which component (identified by domain-id) depends on which other components (identified by trustees) for proper operation. A series of TDTs can be used to describe the trust dependencies of a system of components as a graph. CoRIM uses environment-map to identify components and groupings of components (i.e., domains). Birkholz, et al. Expires 5 May 2027 [Page 55] Internet-Draft CoRIM November 2026 Trust dependency means that an environment can only be fully trusted if one or more trustee environments have been appraised and found to be trustworthy. A candidate environment can only be trusted if the trustee environments it depends on exist, have been appraised and are found to be trustworthy. The first four phases of appraisal (see Section 8.3.4) might not determine whether a component is trustworthy. Subsequent Verifier stages or Relying Party processing might be needed to finalize trustworthiness. Therefore, the trustworthiness of trustee domains MUST be appraised before the trustworthiness of the subject domain can be finalized. Consequently, trust dependency semantics may need to be represented in Attestation Results if Relying Parties play a role in finalizing which components are trustworthy. There are a variety of use cases where trust dependency might exist. For example, trust in an operating system (OS) might depend on trustworthy loading of the OS loader image. Consequently, the OS loader is a trustee domain of the OS. Alternatively, trust in a peripheral device might depend on trustworthy operation of a peripheral device's bus controller. The bus controller is therefore a trustee domain of the peripheral device. TDTs cannot instantiate domains. Instead, TDT processing first verifies that a domain-id has already been accepted into the ACS before adding any trust-dependency triples. Environments that have been accepted into the ACS are automatically considered Domains. Consequently, TDTs may describe trust-dependency semantics for any Environment that has been accepted into the ACS. The trust dependency triple subject (domain-id) identifies the member domain (see Section 5.1.11.1) that has trustees. The triple object trustees lists the domains that are trustees of the subject domain. The triple predicate asserts that a trust appraisal of domain-id is not complete without appraisal of the trustees. trust-dependency-triple-record = [ domain-id: domain-type trustees: [ + domain-type ] ] Figure 8: Trust Dependency Triple Definition All of the TDT subjects (domain-id) and objects (trustees) MUST also be domain members for the TDT expression to be processed. Trust dependency graphs are acyclic, meaning a domain-id MUST NOT appear in the trustees list or within a trustee's subtree. Birkholz, et al. Expires 5 May 2027 [Page 56] Internet-Draft CoRIM November 2026 A terminus trustee can be thought of as a "root of trust" for a trust dependency graph. Terminus trustees SHOULD have a corresponding Endorsement triple. Verifiers MAY use TDTs with appraisal policies to assess the veracity of domain-to-trustee linkages. Trust dependency typically exists if any of the following are true: * A trustee performs any Attesting Environment functions relating to a Target Environment (TE), such as Claims collection, Claims signing, loading or initialization of the TE, provisioning TE secrets - including cryptographic keys or other security-relevant material. * A trustee executes security-relevant code in response to an execution thread that originates from the domain-id environment. * A trustee is a component embedded within another component identified by domain-id. Trust dependency triples are transformed into an internal representation (see Section 8.3.3.7.6) then processed as described in Section 8.3.4.3.5. 5.1.12. CoMID-CoSWID Linking Triple A CoSWID triple relates reference measurements contained in one or more CoSWIDs to a Target Environment. The subject identifies a Target Environment, the object one or more tag identifiers of existing CoSWIDs, and the predicate asserts that these contain the expected (i.e., reference) measurements for the Target Environment. ;# import rfc9393 as coswid coswid-triple-record = [ environment-map [ + coswid.tag-id ] ] Figure 9: CoMID-CoSWID Linking Triple Definition 5.2. Extensibility The base CoRIM document definition is described using CDDL [RFC8610] that can be extended only at specific allowed points known as "extension points". The following types of extensions are supported in CoRIM. Birkholz, et al. Expires 5 May 2027 [Page 57] Internet-Draft CoRIM November 2026 5.2.1. Map Extensions Map extensions provide extensibility support to CoRIM map structures. CDDL map extensibility enables a CoRIM profile to extend the base CoRIM CDDL definition. CDDL map extension points have the form ($$NAME-extension) where "NAME" is the name of the map and '$$' signifies map extensibility. Typically, map extension requires a convention for code point naming that avoids code-point reuse. Well- known code points may be in a registry, such as CoSWID [IANA.coswid]. Non-negative integers are reserved for IANA to assign meaning globally. 5.2.2. Data Type Extensions Data type extensibility has the form ($NAME-type-choice) where "NAME" is the type name and '$' signifies type extensibility. New data type extensions SHOULD be documented to facilitate interoperability. CoRIM profiles are best used to document vendor or industry defined extensions. 6. CoTL A Concise Tag List (CoTL) object represents the signal for the Verifier to activate the listed tags. Verifier policy determines whether CoTLs are required. When CoTLs are required, each tag MUST be activated by a CoTL before being processed. All the tags listed in the CoTL MUST be activated atomically. If any tag activated by a CoTL is not available to the Verifier, the entire CoTL is rejected. The number of CoTLs required in a given supply chain ecosystem is dependent on Verifier Owner's Appraisal Policy for Evidence. Corresponding policies are often driven by the complexity and nature of the use case. If a Verifier Owner has a policy that does not require CoTL, tags within a CoRIM received by a Verifier are activated immediately and treated as valid for appraisal. There may be cases when the Verifier receives CoRIMs from multiple Reference Value providers and Endorsers. In such cases, a supplier (or other authorities, such as integrators) may be designated to issue a single CoTL to activate all the tags submitted to the Verifier in these CoRIMs. Birkholz, et al. Expires 5 May 2027 [Page 58] Internet-Draft CoRIM November 2026 In a more complex case, there may be multiple authorities that issue CoTLs at different points in time. An Appraisal Policy for Evidence may dictate how multiple CoTLs are to be processed within the Verifier. 6.1. Structure The CDDL specification for the concise-tl-tag map is as follows, and this rule and the additional grammatical requirements specified in the text of this Section MUST be followed when creating or validating a CoTL tag: concise-tl-tag = { &(tag-identity: 0) => tag-identity-map &(tags-list: 1) => [ + tag-identity-map ], &(tl-validity: 2) => validity-map } The following describes each member of the concise-tl-tag map. * tag-identity (index 0): A tag-identity-map containing identification information for the CoTL. Described in Section 5.1.1. * tags-list (index 1): One or more tag-identity-maps identifying the CoMID and CoSWID tags that constitute the list, i.e., a complete set of verification-related information. The tags-list behaves like a signaling mechanism from the supply chain (e.g., a product vendor) to a Verifier that activates the tags in tags-list for use in the Evidence appraisal process, and the activation is atomic. All tags listed in tags-list MUST be activated or no tags are activated. * tl-validity (index 2): Specifies the validity period of the CoTL. Described in Section 7.3. 7. Common Types The following CDDL types may be shared by CoRIM, CoMID, and CoTL. 7.1. Non-Empty The non-empty generic type is used to express that a map with only optional members MUST at least include one of the members. non-empty = (M) .and ({ + any => any }) Birkholz, et al. Expires 5 May 2027 [Page 59] Internet-Draft CoRIM November 2026 7.2. Entity The entity-map is a generic type describing an organization responsible for the contents of a manifest. It is instantiated by supplying two parameters: * A role-type-choice, i.e., a selection of roles that entities of the instantiated type can claim * An extension-socket, i.e., a CDDL socket that can be used to extend the attributes associated with entities of the instantiated type entity-map = { &(entity-name: 0) => $entity-name-type-choice ? &(reg-id: 1) => uri &(role: 2) => [ + role-type-choice ] * extension-socket } $entity-name-type-choice /= text The following describes each member of the entity-map. * entity-name (index 0): The name of entity which is responsible for the action(s) as defined by the role. $entity-name-type-choice can only be text. Other specifications can extend the $entity-name- type-choice. See Section 11.6. * reg-id (index 1): A URI associated with the organization that owns the entity name. * role (index 2): A type choice defining the roles that the entity is claiming. The role is supplied as a parameter at the time the entity-map generic is instantiated. * extension-socket: A CDDL socket used to add new information structures to the entity-map. Examples of how the entity-map generic is instantiated can be found in (Section 4.1.5) and (Section 5.1.2). 7.3. Validity A validity-map represents the time interval during which the signer warrants that it will maintain information about the status of the signed object (e.g., a manifest). Birkholz, et al. Expires 5 May 2027 [Page 60] Internet-Draft CoRIM November 2026 In a validity-map, both ends of the interval are encoded as epoch- based date/time as per Section 3.4.2 of [STD94]. validity-map = { ? &(not-before: 0) => time &(not-after: 1) => time } * not-before (index 0): the date on which the signed manifest validity period begins * not-after (index 1): the date on which the signed manifest validity period ends 7.4. UUID Used to tag a byte string as a binary UUID. Defined in Section 4 of [RFC9562]. uuid-type = bytes .size 16 tagged-uuid-type = #6.37(uuid-type) 7.5. UEID Used to tag a byte string as Universal Entity ID Claim (UEID). Defined in Section 4.2.1 of [RFC9711]. ueid-type = bytes .size (7..33) tagged-ueid-type = #6.550(ueid-type) 7.6. OID Used to tag a byte string as the BER encoding [X.690] of an absolute object identifier [RFC9090]. oid-type = bytes tagged-oid-type = #6.111(oid-type) 7.7. Digest A digest represents the value of a hashing operation together with the hash algorithm used. This specification reuses the digest type defined in Section 4.2 of [I-D.ietf-rats-eat-measured-component]. Only the CBOR serialization is used. ;# import measured-component as eatmc digests-type = [ + eatmc.digest ] Birkholz, et al. Expires 5 May 2027 [Page 61] Internet-Draft CoRIM November 2026 A measurement can be obtained using different hash algorithms. A digests-type can be used to collect multiple digest values obtained by applying different hash algorithms on the same input. Each entry in the digests-type MUST have a unique alg value. 7.8. Tagged Bytes Type An opaque, variable-length byte string. It can be used in different contexts: as an instance, class or group identifier in an environment-map; as a raw value measurement in a measurement-values- map. Its semantics are defined by the context in which it is found, and by the overarching CoRIM profile. When used as an identifier, the value MUST be a Collision-Resistant Name (see Section 1.1.1); the responsible allocator entity is responsible for ensuring this property holds within the context in which the identifier is used. tagged-bytes = #6.560(bytes) 8. Reference Verifier This section outlines the behavior of a "CoRIM processor" within the Evidence appraisal procedure carried out by the RATS Verifier (Section 7.4 of [RFC9334]). In the remainder of this section, the terms Environment, Claim, Environment-Claim Tuple (ECT), Authority, Appraisal Claims Set (ACS), and Appraisal Policy are used with the meanings defined in Section 1.1.1. 8.1. Pseudocode Notation The algorithms in pseudocode are meant for readability and not for execution. The following pseudocode notation is used throughout this document. 8.1.1. Comments A comment begins with "//" and extends to the end of the line. // this is a comment Birkholz, et al. Expires 5 May 2027 [Page 62] Internet-Draft CoRIM November 2026 8.1.2. Types Pseudocode Type names are taken directly from the CDDL [RFC8610]. There is no separate type language; type annotations on function parameters, return values, and variable bindings reuse CDDL type expressions verbatim. A reader familiar with the CDDL schemas in this document can read the algorithms without any additional type translation. A bare name refers to a CDDL rule: measurement-map ACS StagingArea The CDDL notation "[ + T ]" denotes a non-empty array of elements of type T: [ + measurement-map ] An extensible CDDL socket type is prefixed with "$": $crypto-key-type-choice $profile-type-choice The CDDL "/" operator separates the alternatives of a union type: attest-key-triple-record / identity-triple-record 8.1.3. Variables A variable is introduced and assigned a value using the ":=" operator: item := rv-item::NEW() A previously introduced variable or a field of a structured value is updated using "=": item.addition.cmtype = reference-values 8.1.4. Functions A function is introduced by the FUNC keyword, followed by its name, a parenthesized parameter list with CDDL type annotations, and a return type: Birkholz, et al. Expires 5 May 2027 [Page 63] Internet-Draft CoRIM November 2026 FUNC name(param: type, ...) -> return-type { ... } A RETURN statement exits the enclosing function and yields the specified value to the caller: RETURN value A FAIL statement immediately aborts the enclosing top-level FUNC without yielding a value, signaling to the caller that the operation did not complete successfully: FAIL 8.1.5. Expressions The TYPEOF operator yields the CDDL type of a value at runtime. Used with "==", it dispatches on the alternatives of a CDDL union type: IF TYPEOF(T) == attest-key-triple-record: ... ELIF TYPEOF(T) == identity-triple-record: ... The "~" prefix operator unwraps a CBOR-tagged value to its untagged content, corresponding to the CDDL unwrap idiom: ELIF TYPEOF(v) == tagged-svn: RETURN ~v 8.1.6. Conditionals An IF statement tests a condition and executes its body if the condition is true. One or more ELIF clauses test additional conditions in order. An optional ELSE clause provides a fallback: IF condition: ... ELIF condition: ... ELSE: ... 8.1.7. Iteration A FOREACH statement iterates over the elements of a collection in order: Birkholz, et al. Expires 5 May 2027 [Page 64] Internet-Draft CoRIM November 2026 FOREACH item IN collection: ... A BREAK statement exits the innermost enclosing FOREACH immediately. 8.1.8. Primitive Operations The pseudocode uses a "Receiver::OPERATION(args)" calling convention to invoke well-known operations on typed values. All operation names are uppercase. +==========================+========================================+ | Operation | Meaning | +==========================+========================================+ | T::NEW() | Construct a new zero-value | | | instance of CDDL type T | +--------------------------+----------------------------------------+ | collection::APPEND(item) | Append item to a collection; when | | | item is itself a list, all its | | | elements are appended | +--------------------------+----------------------------------------+ | acs::MATCH(condition) | Test whether condition matches | | | any entry in the ACS; the | | | matching rules are relation- | | | specific and defined in | | | Section 8.3.4.4 | +--------------------------+----------------------------------------+ | acs::APPEND(addition) | Attempt to atomically append | | | addition to the ACS; returns TRUE | | | on success, or FALSE (leaving the | | | ACS unchanged) if the relation- | | | specific pre-condition on | | | addition or post-condition on the | | | resulting ACS, both defined in | | | Section 8.3.4, is not satisfied | +--------------------------+----------------------------------------+ | x::MEMBEROF(collection) | Test whether x is a member of | | | collection | +--------------------------+----------------------------------------+ | INDEXOF(x) | Return the position of x within | | | its enclosing sequence | +--------------------------+----------------------------------------+ Table 3: Primitive Operations Birkholz, et al. Expires 5 May 2027 [Page 65] Internet-Draft CoRIM November 2026 8.2. Appraisal Logical Phases For clarity, the appraisal procedure is divided into several logical phases. *Phase 1*: Input Validation and Transformation. During this phase, all available Conceptual Messages are processed for validation. This involves checking digital signatures to verify their integrity and authenticity, ensuring they are not outdated and confirming their relevance to the current appraisal. If validation fails, the input Conceptual Message is discarded. If validation succeeds, the Conceptual Message is transformed from its external representation into an internal one. These internal representations are then collected in an implementation-specific "staging area", which acts as a database for subsequent appraisal processing. *Phase 2*: Evidence Augmentation. During this phase, Evidence Claims are added to a structure describing the Attester's actual state, known as the ACS. These Claims are added to the ACS with Attester Authority. *Phase 3*: Reference Values Corroboration and Augmentation. During this phase, Reference Value Claims are compared with Evidence Claims from the ACS. Reference Value Claims describe the possible states of the Attester. If the Attester's actual state, as described in the ACS, is one of these possible states, the Attester's actual state is said to be "corroborated". These Claims are added to the ACS with the Authority of the Reference Value Provider. *Phase 4*: Endorsed Values Augmentation. During this phase, Endorsed Values inputs containing conditions that describe the expected state of the Attester are processed. If the conditions are met, additional Claims about the Attester are added to the ACS. These Claims are added with the Endorser's Authority. *Subsequent Phases*: Before producing an Attestation Result, a Verifier may undergo subsequent phases of the appraisal procedure. For example, the Verifier may perform consistency, integrity or additional validity checks. These checks may result in additional Claims about the Attester being added to the ACS. These Claims are added with the Verifier's Authority. Typically, a Verifier applies Appraisal Policy for Evidence on the ACS that describes desirable or undesirable Attester states. If these conditions are met, the policy Birkholz, et al. Expires 5 May 2027 [Page 66] Internet-Draft CoRIM November 2026 may add further Claims about the Attester to the ACS. These Claims are added with the Authority of the Verifier's Owner. Finally, the outcome of appraisal and the set of Attester Claims of interest to a Relying Party are copied from the Attester state to an output staging area. The Claims in the output staging area and other Verifier- related metadata are then transformed into an external representation suitable for consumption by a Relying Party. This external representation is the Attestation Result message (see Section 8.4 of [RFC9334]). Please note that a detailed description of subsequent phases is beyond the scope of this document. They are mentioned here to provide an overview of the appraisal procedure. The CoRIM processor described in Section 8.3 describes the handoff interface between Phase 4 and the subsequent phases in terms of the computed ACS. 8.3. The CoRIM Processor This document assumes that Verifier implementations will differ. In order to describe normative Verifier behavior, this section presents a reference Verifier and illustrates how the data is utilized within the appraisal phases detailed in Section 8.2. If the Verifier operates on CoRIM documents, it is RECOMMENDED that it follows this algorithm. 8.3.1. High-Level View The RATS Verifier takes Evidence, Reference Values, Endorsements and an Appraisal Policy for Evidence as inputs, and produces Attestation Results as output. Figure 10 illustrates how the CoRIM processor fits into the wider RATS Verifier architecture. .-----------------------. | Reference Values | | and Endorsements | '-----------+-----------' | .-------+-----------. .-+-----------------. | .-+-----------------. +-' | CoRIM file(s) +-' '---------+---------' | .--------------------------|---------------. | RATS Verifier | | | .-----------------------+------------. | | | CoRIM Processor v | | | | .--------------. | | Birkholz, et al. Expires 5 May 2027 [Page 67] Internet-Draft CoRIM November 2026 | | | Validation & | | | | | | Internal Repr. | | | | | | Transformation | | | | | '-------+------' | | .----------------. | | | | | | Evidence | | | v | | '-------+--------' | | .---------------------. | | | | | | Staging Area | | | | | | | .-----. .-----. | | | v | | | | Int | | Int | | | | .--------------. | | | | Rep | ... | Rep | | | | | Validation & | | | | '-----' '-----' | | | | Internal Repr. | | | '----------+----------' | | | Transformation | | | | | | '------+-------' | | .---------. v | | | | | | .-----. | .---------. | | '--------------->| | ECT | +---->| | | | | | | '-----' | | ACS | | | | | | ... | | Match & | | | | | | .-----. | | Augment | | | | | | | ECT | |<----+ | | | | | | '-----' | '---------' | | | | | ACS | | | | | '----+----' | | | | | | | | '------+-----------------------------' | .----------------. | v | | Appraisal | | .-----------------. .-------------. | | Policy for +---->| Subsequent Phases +--->| Attestation +-----> | Evidence | | '-----------------' | Results | | '----------------' | '-------------' | '------------------------------------------' Legend: .-------. .------. ACS = Appraisal Claims Set | Process | | Data | ECT = Environment-Claims Tuple '-------' '------' Int Rep = Internal Representation Figure 10: CoRIM Processing Flow The CoRIM processor accepts Reference Values and Endorsements in the form of CoRIM documents, as well as Evidence that has been converted into a CoRIM-compatible format using transforms such as those described in [I-D.ietf-rats-evidence-trans]. Before the appraisal can begin, all Conceptual Messages must be broken down and reshaped into a common internal representation. The internal representations of Reference Values and Endorsements are stored in a staging area prior to appraisal initiation. In contrast, the internal Birkholz, et al. Expires 5 May 2027 [Page 68] Internet-Draft CoRIM November 2026 representation of Evidence is used to initialize the ACS. A Verifier can have multiple simultaneous sessions with different Attesters. Each Attester has a different ACS. The Verifier ensures that Evidence inputs are associated with the correct ACS. All the internal representations are based on the Environment-Claim Tuple (ECT). The ECT is the core data structure used to represent both Claims and matching conditions during appraisal by the CoRIM processor. The CoRIM processor algorithm loads items from the staging area one by one and applies the required condition-matching rules against the ECTs in the ACS. If the match is successful, the ACS is "augmented" with Claims from the matched item. Once all the items in the staging area have been processed, the state of the Attester, as understood by the CoRIM processor, is reflected in the ACS. The computed ACS can then be handed over to subsequent appraisal phases, such as Appraisal Policy evaluation and Attestation Results computation, repackaging and signing. 8.3.2. Data Structures This section describes the data structures used by the CoRIM processor. 8.3.2.1. ECT The Environment-Claim Tuple is a core internal construct of the CoRIM Verifier. It is used to describe a feature (or "Claim") of the appraised environment alongside relevant metadata. All ECTs, except those containing Evidence Claims, are typically obtained from CoMID triples. Claims in ECTs have both a name and a value. The value represents the state associated with the Claim. This specification does not assign any special meaning to Claim names; it only specifies the rules for determining whether two Claim names are the same. An ECT (Figure 11) can be one of the following specializations: * E-ECT (Element ECT): used to represent Evidence, Reference Value and Endorsement Claims, as detailed in Section 8.3.2.1.1; * M-ECT (Domain Membership ECT): used to represent domain membership Claims, as detailed in Section 8.3.2.1.2; * T-ECT (Trust Dependency ECT): used to represent trust dependency Claims, as detailed in Section 8.3.2.1.2; * K-ECT (Key ECT): used to represent Identity and Attestation keys, as detailed in Section 8.3.2.1.4. Birkholz, et al. Expires 5 May 2027 [Page 69] Internet-Draft CoRIM November 2026 ECT = E-ECT / M-ECT / T-ECT / K-ECT Figure 11: ECT definition While the internal representation of each specialization varies, all ECT specializations share the attributes captured in the ECT-common group (Figure 12). ECT-common = ( ? environment: environment-map ? authority: [ + $crypto-key-type-choice ] ? profile: $profile-type-choice ) Figure 12: ECT common attributes * environment: Identifies the Environment that is the subject of the stated Claims. In an Element ECT, it is the target environment to which the elements belong. In a Domain ECT, it is the parent environment to which the child domains are related. In a Key ECT, it is the environment to which the keys belong. In all cases, Environments are identified using instance, class, or group identifiers. * authority: Identifies the entity that issued the tuple. The authority of a given ECT is typically established through a digital signature on the Claim. For instance, a signature of the authoritative supply chain entity over the CoRIM containing the triple from which the ECT was obtained, or the Attesting Environment that signed the Evidence from which the ECT is derived. It is represented as the key material by which the authority (and corresponding provenance) of the tuple can be determined. A typical example is the authority's PKIX certificate. This attribute is mandatory in an addition ECT, and therefore in every ECT held in the ACS. ECT-common (Figure 12) itself defines authority as optional because it is also the basis for condition ECTs, and not every relation uses authority as a matching criterion. * profile: The profile that defines the domain of interpretation of this tuple. This is the profile attribute of the CoRIM that contained the original triple from which this ECT was obtained. This is an optional attribute in an ECT. If no profile is used, the attribute is omitted, and the only comparison rules that apply are those specified in Section 8.3.4.4. Birkholz, et al. Expires 5 May 2027 [Page 70] Internet-Draft CoRIM November 2026 8.3.2.1.1. Element ECT An Element ECT (E-ECT) is used to represent Evidence, Reference Value and Endorsement Claims. E-ECT = { ECT-common ? element-list: [ + element-map ] ? cmtype: cm-type } element-map = { ? element-id: $measured-element-type-choice element-claims: measurement-values-map } cm-type = &( reference-values: 0 endorsements: 1 evidence: 2 ) Figure 13: Element ECT The following describes the specialized members of the E-ECT. * element-list: Identifies the set of elements contained within a Target Environment and their trustworthiness Claims, each described by an element-map. An element-map is very similar to a measurement-map, with the element-id and element-claims corresponding to the mkey and mval, respectively. The pseudocode in Figure 14 describes the transformation from measurement-map(s) to element-map(s). * cmtype: Identifies the type of Conceptual Message that originated the tuple (Reference Values, Endorsements or Evidence). Birkholz, et al. Expires 5 May 2027 [Page 71] Internet-Draft CoRIM November 2026 FUNC mm_to_em(mm: measurement-map) -> element-map { em := element-map::NEW() IF mm.mkey: em.element-id = mm.mkey em.element-claims = mm.mval RETURN em } FUNC mms_to_ems(mms: [ + measurement-map ]) -> [ + element-map ] { ems := [ + element-map ]::NEW() FOREACH mm IN mms: em := mm_to_em(mm) ems::APPEND(em) RETURN ems } Figure 14: Transform Measurement Map(s) into Element Map(s) *Claim Names.* The combination of environment, optional element-id, and map key within each element-claims encodes the name of an Element Claim. The value of the corresponding map element represents an atom of actual state. This specification does not assign special meanings to any Claim name, it only specifies rules for determining whether two Claim names are the same. *Merge Rules.* If two Element ECTs have the same environment, cmtype, authority and profile then their element-lists are merged. Any duplicates MUST be pruned. Two element-maps containing duplicate codepoints and with non- equivalent measurement values MUST NOT be merged. These are effectively two different acceptable states that need to be processed separately. 8.3.2.1.2. Domain Membership ECT A Domain Membership ECT (M-ECT) is used to represent domain membership Claims between environments. It describes the direct relationship between a specific node in the membership (i.e., the parent environment) and the members nodes that comprise the domain. Birkholz, et al. Expires 5 May 2027 [Page 72] Internet-Draft CoRIM November 2026 M-ECT = { ECT-common members: [ + environment-map ] } Figure 15: Domain Membership ECT The following describes the specialized members of the M-ECT. * members: Identifies the set of members of the domain rooted in the parent environment. A Domain Claim specifies the type of relationship that the parent domain is expected to have with its child environments. In a Domain ECT, the environment attribute encodes the name of the Claim. The value of the Claim is encoded in the members attribute. *Merge Rules.* If two Domain ECTs have the same environment, authority and profile then their members are merged. Any duplicates MUST be pruned. 8.3.2.1.3. Trust Dependency ECT A Trust Dependency ECT (T-ECT) is used to represent trust dependency Claims between environments. It describes the direct relationship between a specific node in the trust domain (i.e., the parent environment) and the trustees nodes that comprise the trust chain. T-ECT = { ECT-common trustees: [ + environment-map ] } Figure 16: Trust Dependency ECT The following describes the specialized members of the T-ECT. * trustees: Identifies the set of environments that becomes a part of a trust chain to the parent environment. A Trust Claim specifies the type of relationship that the parent domain is expected to have with its trustee environments. In a Trust ECT, the environment attribute encodes the name of the Claim. The value of the Claim is encoded in the trustees attribute. *Merge Rules.* Birkholz, et al. Expires 5 May 2027 [Page 73] Internet-Draft CoRIM November 2026 If two Trust ECTs have the same environment, authority and profile then their trustees are merged. Any duplicates MUST be pruned. 8.3.2.1.4. Key ECT A Key ECT (K-ECT) is used to represent Identity and Attestation keys. K-ECT = { ECT-common ? key-id: $measured-element-type-choice ? key-list: [ + $crypto-key-type-choice ] ? key-type: key-type } key-type = &( attest-key: 0 identity-key: 1 ) Figure 17: Key ECT The following describes the specialized members of the K-ECT. * key-id: Identifies a specific namespace within environment that the keys in key-list are associated with. * key-list: Identifies the set of keys associated with environment and (optionally) key-id. * key-type: Either attest-key or identity-key, depending on the triple that originated this K-ECT instance. *Claim Names.* A Key Claim specifies one or more keys associated with the environment, as well as the semantics of these keys. In a Key ECT, the environment, key-type and optional key-id attributes encode the name of the Claim. The value of the Claim is encoded in the key-list attribute. *Merge Rules.* No merge rules are specified for a Key ECT. Birkholz, et al. Expires 5 May 2027 [Page 74] Internet-Draft CoRIM November 2026 8.3.2.2. Internal Representation This section describes how the relevant RATS Conceptual Messages are represented within the CoRIM processor. This internal representation is based on the concept of "relations", which in turn are based on ECTs. Typically, a relation is structured as a "condition" ECT that specifies the matching criteria used to compare entries in the ACS, along with an "addition" ECT that is appended to the ACS if the specified conditions are met. While this is the common structure, some relations may differ slightly from the condition/addition pattern. This is because they either do not require a condition (e.g., Evidence) or they require more sophisticated matching criteria that cannot be expressed solely via a condition (e.g., Conditional Endorsement Series). 8.3.2.2.1. Evidence The internal representation of Evidence uses the ae relation. ae = [ + ae-item ] ae-item = { addition: Evidence-addition-ECT } Figure 18: Attestation Evidence Relation The addition is a list of ECTs with Evidence Claims (ae-items) to be appraised. Note that there is no condition in the ae relation, meaning that the addition of Evidence Claims is unconditional once Evidence has been verified. Figure 19 shows the profiled ECT for an ae item. Evidence-addition-ECT = ({ environment: environment-map element-list: [ + element-map ] authority: [ + $crypto-key-type-choice ] cmtype: 2 ? profile: $profile-type-choice }) .within E-ECT Figure 19: Profiled ECT for Evidence All E-ECT attributes are mandatory, except profile. Birkholz, et al. Expires 5 May 2027 [Page 75] Internet-Draft CoRIM November 2026 8.3.2.2.2. Reference Values The internal representation of Reference Values uses the rv relation where each rv-item corresponds to a reference-triple-record. rv = [ + rv-item ] rv-item = { condition: Reference-Value-condition-ECT addition: Reference-Value-addition-ECT } Figure 20: Reference Values Relation The rv relation is a list of condition-addition pairs, each of which is evaluated together. If the condition containing the "reference" ECTs matches the Evidence ECTs, the Evidence ECTs are re-asserted with the RVP authority carried in the addition ECT and the cmtype set to reference-values. The re-asserted ECTs are added to the ACS. Refer to Section 8.3.4.2 for how the rv entries are processed. Figure 21 shows the profiled Element ECT for a Reference Values condition. Reference-Value-condition-ECT = ({ environment: environment-map element-list: [ + element-map ] ? authority: [ + $crypto-key-type-choice ] }) .within E-ECT Figure 21: Profiled ECT for Reference Values (condition) Figure 22 shows the profiled Element ECT for a Reference Values addition. Reference-Value-addition-ECT = ({ environment: environment-map ? element-list: [ + element-map ] authority: [ + $crypto-key-type-choice ] cmtype: 0 ? profile: $profile-type-choice }) .within E-ECT Figure 22: Profiled ECT for Reference Values (addition) As this is used to corroborate an Evidence ECT, its layout is identical to that of an Evidence-addition-ECT. The only differences are the values of the element-list, authority and cmtype attributes. Birkholz, et al. Expires 5 May 2027 [Page 76] Internet-Draft CoRIM November 2026 Here, the authority value is that of the RVP rather than the Attester, and the cmtype value is reference-values rather than evidence. Furthermore, the element-list is created if a match is found during processing, rather than when the triple is transformed into the internal representation. Therefore, it may be absent. 8.3.2.2.3. Endorsed Values The internal representation of Endorsed Values uses the ev and evs relations. These are lists of ECTs that describe matching conditions and the additions that apply when these conditions are met. The ev relation (Figure 23) applies to Endorsed Values (EV) and Conditional Endorsement (CE) triples. ev = [ + ev-item ] ev-item = { condition: [ + Endorsement-condition-ECT ] addition: [ + Endorsement-addition-ECT ] } Figure 23: Endorsed Values Relation The ev relation compares the condition ECTs with those in the ACS. If all the ECTs are found in the ACS, the addition ECTs are added to it. Note that when the ev relation is for an EV triple, the optional element-list inside the condition is not used; however, it is used for CE triples. The evs relation (Figure 24) applies to Conditional Endorsement Series (CES) Triples. evs = [ + evs-item ] evs-item = { series: [ + series-item ] } series-item = [ condition: [ + Endorsement-condition-ECT ] addition: [ + Endorsement-addition-ECT ] ] Figure 24: Endorsed Values Series Relation Birkholz, et al. Expires 5 May 2027 [Page 77] Internet-Draft CoRIM November 2026 The evs relation contains a list of series items. Each series item contains a list of condition ECTs and a list of addition ECTs. The condition ECTs are compared with the ACS. If the condition criteria are satisfied, the addition ECTs are added to the ACS and the series evaluation ends. If the condition criteria are not satisfied, evaluation proceeds to the next series item. Figure 25 shows the profiled Element ECT for an Endorsed Value condition. Endorsement-condition-ECT = ({ environment: environment-map ? element-list: [ + element-map ] ? authority: [ + $crypto-key-type-choice ] }) .within E-ECT Figure 25: Profiled condition ECT for ev and evs relations Figure 26 shows the profiled Element ECT for an Endorsed Value addition. Endorsement-addition-ECT = ({ environment: environment-map element-list: [ + element-map ] authority: [ + $crypto-key-type-choice ] cmtype: 1 ? profile: $profile-type-choice }) .within E-ECT Figure 26: Profiled addition ECT for ev and evs relations 8.3.2.2.4. Keys The internal representation of Attest Key and Device Identity triples uses the keys relation (Figure 27), whereby each key-item corresponds to either an attest-key-triple-record or an identity-triple-record. keys = [ + key-item ] key-item = { ? condition: Key-condition-ECT addition: Key-addition-ECT } Figure 27: Keys Relation Birkholz, et al. Expires 5 May 2027 [Page 78] Internet-Draft CoRIM November 2026 If key-item is used to transform Evidence, key-item.condition is omitted since Evidence addition is unconditional. Nevertheless, key- item.addition is merely staged for addition pending successful key verification checks. 8.3.2.2.5. Domain Memberships The internal representation of Domain Membership uses the dm relation (Figure 28), whereby each domain-item corresponds to a domain- membership-triple-record. dm = [ + domain-item ] Figure 28: Domain Membership Relation domain-item = { condition: Domain-condition-ECT addition: Domain-addition-ECT } Figure 29: Domain Item Figure 30 shows the profiled Domain ECT for Domain Membership conditions. Domain-condition-ECT = ({ members: [ + environment-map ] authority: [ + $crypto-key-type-choice ] ? profile: $profile-type-choice }) .within M-ECT Figure 30: Profiled ECT for Domain Membership (condition) Only the members are used for matching, not the environment. Therefore, the environment attribute is excluded from the ECT condition. Figure 31 shows the profiled Domain ECT for Domain Membership additions. Domain-addition-ECT = ({ environment: environment-map authority: [ + $crypto-key-type-choice ] ? profile: $profile-type-choice members: [ + environment-map ] }) .within M-ECT Figure 31: Profiled ECT for Domain Membership (addition) Birkholz, et al. Expires 5 May 2027 [Page 79] Internet-Draft CoRIM November 2026 8.3.2.2.6. Trust Dependencies The internal representation of Trust Dependency uses the td relation (Figure 32), whereby each td-item corresponds to a trust-dependency- triple-record. td = [ + td-item ] Figure 32: Trust Dependency Relation td-item = { condition: Trust-Dependency-condition-ECT addition: Trust-Dependency-addition-ECT } Figure 33: Trust Dependency Item Figure 34 shows the profiled T-ECT for Trust Dependency conditions. Trust-Dependency-condition-ECT = ({ environment: environment-map authority: [ + $crypto-key-type-choice ] ? profile: $profile-type-choice trustees: [ + environment-map ] }) .within T-ECT Figure 34: Profiled ECT for Trust Dependency (condition) Both the trustees and environment are used for matching. Figure 35 shows the profiled T-ECT for Trust Dependency additions. Trust-Dependency-addition-ECT = ({ environment: environment-map authority: [ + $crypto-key-type-choice ] ? profile: $profile-type-choice trustees: [ + environment-map ] }) .within T-ECT Figure 35: Profiled ECT for Trust Dependency (addition) Birkholz, et al. Expires 5 May 2027 [Page 80] Internet-Draft CoRIM November 2026 Before the td relation is added to the Staging Area, the trust dependency graph it describes MUST be checked to ensure that it is a directed acyclic graph. If a cycle is detected, the td relation MUST NOT be added to the Staging Area, and this condition SHOULD be logged. This is a prerequisite for the match_and_augment algorithm described in Figure 47. Please note that a subsequent Appraisal Policy for Evidence may decide not to produce Attestation Results in this case. A trust dependency relation is added to the ACS if the environment and all trustees exist in the membership graph expressed by the dm relation (Figure 28) in the ACS. 8.3.2.3. ACS The ACS (Figure 36) is a list of ECTs that represent the Attester's actual state as determined by various authoritative sources (Reference Value Providers and Endorsers) collected by the Verifier. ACS = [ + ECT ] Figure 36: ACS The authority attribute in each ECT represents one such source, while the Claims in the ECT are statements made by that source about the Attester. The ACS is initialized with Evidence Claims and is then populated with Reference Values and Endorsement Claims via the "match and augment" algorithm (see Section 8.3.4) implemented by the CoRIM processor. Once the staging area has been drained by the CoRIM processor, processing stops and the computed ACS is handed over to subsequent phases. In this way, the ACS represents the CoRIM processor's output interface. The order of the ECTs in the ACS is not significant. Logically, as the ACS represents the conjunction of all claims, adding an ECT entry to the existing ACS at the end has the same effect as inserting it anywhere else. 8.3.2.4. Staging Area The staging area (Figure 37) is a list of the relations corresponding to the transformed triples. Birkholz, et al. Expires 5 May 2027 [Page 81] Internet-Draft CoRIM November 2026 StagingArea = [ ? rv, ? ev, ? evs, ? keys, ? dm, ? dd, ] Figure 37: Staging Area All relations are optional. Whether a given relation is present in the staging area depends on whether a triple exists and has been successfully transformed. 8.3.3. Input Validation and Transformation (Phase 1) This section provides a detailed description of Phase 1, which was outlined at a high level in Section 8.2, explaining how the relevant Conceptual Messages are ingested by the CoRIM processor. During the initialization phase, various Conceptual Message inputs are collected: CoMID tags (see Section 5); CoSWID tags (see [RFC9393]); CoTL tags (see Section 6); cryptographic validation key material (including raw public keys, root certificates and intermediate CA certificate chains); and Concise Trust Anchor Stores (CoTS) (see [I-D.ietf-rats-concise-ta-stores]) are collected. These objects will be utilized at various stages in the subsequent Evidence Appraisal phases that follow. The primary goal of this phase is to ensure that all necessary information is available for subsequent processing. Once initialization is complete, no further inputs are accepted until the appraisal processing is finished. 8.3.3.1. CoRIM Selection All available CoRIM tags are collected. CoRIM tags MUST be discarded if they have expired, or if they are not associated with an authenticated and authorized source, or if they have been revoked by an authorized source. Any CoRIM secured by a cryptographic mechanism that fails validation MUST be discarded. Birkholz, et al. Expires 5 May 2027 [Page 82] Internet-Draft CoRIM November 2026 If the Verifier fetches a resource identified by a corim-locator-map (Section 4.1.3) that includes a thumbprint, it MUST check the fetched resource against thumbprint following the rules in Section 8.3.4.4.5.4, with the digests computed over the fetched resource in place of the ACS-ECT digests. If that check fails, the Verifier MUST NOT use the fetched resource. Other selection criteria MAY be applied. For example, if the Evidence format is known in advance, CoRIMs using a profile that is not understood by a Verifier can be readily discarded. Further selection criteria may be applied to the CoRIM contents at later stages. 8.3.3.2. CoRIM Trust Anchors If CoRIM tags are signed, the signatures MUST be verified using the appropriate trust anchors available to the Verifier. The Verifier is expected to have a trust anchor store. The way in which these trust anchors are provisioned in the Verifier is beyond the scope of this specification. If the CoRIM is signed, it should include at least one certificate (e.g., as part of the x5chain in the COSE header) that corresponds to the key pair used for signing. This certificate MUST have a valid certification path to one of the Verifier's trust anchors. If the CoRIM is signed by multiple authorities, at least the signature from the CoRIM creator MUST be verified before the CoRIM can be accepted for further processing by the Verifier. A Verifier Appraisal Policy for Evidence may require more signatures to be verified before accepting the CoRIM. For each of these signers, it is expected that the corresponding trust anchors will be provisioned in the Verifier. The way in which these trust anchors are provisioned in the Verifier is beyond the scope of this specification. 8.3.3.3. Tags Extraction and Validation The Verifier extracts tags from the selected CoRIMs, including CoMID, CoSWID, CoTL, and CoTS. The Verifier MUST discard any tags that are not syntactically or semantically valid. Cross-referenced triples MUST be successfully resolved. An example of a cross-referenced triple is a CoMID-CoSWID linking triple described in Section 5.1.12. Birkholz, et al. Expires 5 May 2027 [Page 83] Internet-Draft CoRIM November 2026 8.3.3.4. CoTL Extraction (This section is not applicable if the Verifier appraisal policy does not require CoTLs.) CoTLs that are outside their validity period MUST be discarded. The Verifier processes all CoTLs that are valid at the time of Evidence appraisal and activates all referenced tags. Depending on any locally configured authorization policies, the Verifier MAY decide to discard some of the available and valid CoTLs. Such policies model the trust relationships between the Verifier Owner and the relevant suppliers, and are out of the scope of the present document. For example, a composite device (see Section 3.3 of [RFC9334]) is likely to be fully described by multiple CoRIMs, each signed by a different supplier. In such a case, the Verifier Owner may instruct the Verifier to discard any tags activated by a supplier's CoTL that has not also been activated by the trusted integrator. Once the Verifier has processed all CoTLs, it MUST discard any tags that have not been activated by a CoTL. 8.3.3.5. Evidence Collection The Verifier communicates with Attesters to gather Evidence. Discovery of Evidence sources is untrusted. Verifiers may rely on conveyance protocol-specific context to identify an Evidence source, which acts as the Evidence input oracle for appraisal. The collected Evidence is then transformed into an internal representation (see Section 8.3.2.2.1), making it suitable for appraisal processing. The exact protocol used to collect Evidence is out of scope of this specification. 8.3.3.6. Cryptographic Validation of Evidence If Evidence is cryptographically signed, it is validated before being transformed into an internal representation. If Evidence is not cryptographically signed, the conveyance protocol used to collect it MUST provide the required security. In such cases, the cryptographic validation of Evidence depends on the security offered by the conveyance protocol. Birkholz, et al. Expires 5 May 2027 [Page 84] Internet-Draft CoRIM November 2026 How cryptographic signature validation works depends on the specific Evidence collection method used. For example, in DICE, a proof of liveness is carried out on the final key in the certificate chain (i.e., the "alias" certificate). If this is successful, a suitable certification path is looked up in the Verifier trust anchor store based on the linking information obtained from the DeviceID certificate. See Section 9.2.1 of [DICE.Layer]. If a trusted root certificate is found, X.509 certificate validation is performed. As a second example, the verification public key used to verify [RFC9783] Evidence is looked up in the appraisal context using the ueid claim found in the PSA claims-set. If found, COSE Sign1 verification is performed. Regardless of the specific integrity protection method used, the Verifier MUST NOT process Evidence that is not successfully validated. 8.3.3.7. Input Transformation This section describes how the relevant RATS Conceptual Messages are transformed upon ingestion by the CoRIM processor. 8.3.3.7.1. Evidence Evidence transformation involves mapping Evidence into one or more Evidence-ECTs (see Section 8.3.2.2.1), and adding them to the addition list of an ae relation. Evidence transformation algorithms may be well-known (e.g., [I-D.ietf-rats-evidence-trans]), defined by a CoRIM profile (see Section 4.1.4), or supplied dynamically. Evidence transformation algorithms are out of scope for this document. For successful transformation, Evidence MUST contain a relevant value for all the mandatory Evidence-ECT attributes. Otherwise, the CoRIM processor MUST reject the Evidence. 8.3.3.7.2. Reference Values Reference Values transformation involves mapping Reference Value triples into an rv relation (see Section 8.3.2.2.2). Each reference- triple-record (Figure 1) is transformed into an rv-item (Figure 20) as described in Figure 38. (The code reuses the mms_to_ems function from Figure 14.) Birkholz, et al. Expires 5 May 2027 [Page 85] Internet-Draft CoRIM November 2026 FUNC transform( T: reference-triple-record, signer: [ + $crypto-key-type-choice ], profile: $profile-type-choice ) -> rv-item { item := rv-item::NEW() item.addition.cmtype = reference-values item.addition.environment = T.ref-env item.condition.environment = T.ref-env item.condition.element-list = mms_to_ems(T.ref-claims) item.addition.authority = signer IF profile: item.addition.profile = profile RETURN item } Figure 38: Reference Value Triple Transformation Note that the ref-claims are not copied to the addition ECT. Since they may contain ranges rather than individual values (see, for example, Section 5.1.4.8), we need to wait until the condition is satisfied by an Evidence ECT before we can copy the matched claims from the Evidence ECT to the addition ECT. 8.3.3.7.3. Endorsed Values Endorsed Values transformation involves mapping EV, CE and CES triples into ev or evs relations (see Section 8.3.2.2.3). An endorsed-triple-record (Figure 2) is transformed into an ev-item (Figure 23) as described in Figure 39. (The code reuses the mms_to_ems function from Figure 14.) Birkholz, et al. Expires 5 May 2027 [Page 86] Internet-Draft CoRIM November 2026 FUNC transform( T: endorsed-triple-record, signer: [ + $crypto-key-type-choice ], profile: $profile-type-choice ) -> ev-item { item := ev-item::NEW() ect-cond := Endorsement-condition-ECT::NEW() ect-cond.environment = T.condition item.condition::APPEND(ect-cond) ect-add := Endorsement-addition-ECT::NEW() ect-add.environment = T.condition ect-add.element-list = mms_to_ems(T.endorsement) ect-add.cmtype = endorsements ect-add.authority = signer IF profile: ect-add.profile = profile item.addition::APPEND(ect-add) RETURN item } Figure 39: Endorsed Value Triple Transformation A conditional-endorsement-triple-record (Figure 3) is transformed into an ev-item (Figure 23) as described in Figure 40. (The code reuses the mms_to_ems function from Figure 14.) Birkholz, et al. Expires 5 May 2027 [Page 87] Internet-Draft CoRIM November 2026 FUNC transform( T: conditional-endorsement-triple-record, signer: [ + $crypto-key-type-choice ], profile: $profile-type-choice ) -> ev-item { item := ev-item::NEW() FOREACH ser IN T.conditions: ect := Endorsement-condition-ECT::NEW() ect.environment = ser.environment ect.element-list = mms_to_ems(ser.claims-list) item.condition::APPEND(ect) FOREACH etr IN T.endorsements: ect := Endorsement-addition-ECT::NEW() ect.environment = etr.condition ect.element-list = mms_to_ems(etr.endorsement) ect.cmtype = endorsements ect.authority = signer IF profile: ect.profile = profile item.addition::APPEND(ect) RETURN item } Figure 40: Conditional Endorsement Triple Transformation Each conditional-endorsement-series-triple-record (Figure 4) is transformed into an evs-item (Figure 24) as described in Figure 41. (The pseudocode reuses the mms_to_ems function defined in Figure 14.) The conditional-endorsement-series-triple-record contains a condition that is common to all series items. Each entry in the series is a conditional-series-record with conditions that have differing values and additions that are specific to those values. The internal representation for a conditional endorsement series consists of a list of condition-addition pairs where the common condition in the series is replicated for each series item. The transformation algorithm combines the common conditions with each series item condition to simplify Verifier processing (see Section 8.3.4.3.2). Birkholz, et al. Expires 5 May 2027 [Page 88] Internet-Draft CoRIM November 2026 FUNC transform( T: conditional-endorsement-series-triple-record, signer: [ + $crypto-key-type-choice ], profile: $profile-type-choice ) -> evs-item { evsitem := evs-item::NEW() FOREACH csr in T.series: // stage the condition sitem := series-item::NEW() sitem.condition.environment = T.condition.environment ems1 = mms_to_ems(T.condition.claims-list) sitem.condition.element-list = ems1 ems2 := mms_to_ems(csr.condition) sitem.condition.element-list::APPEND(ems2) IF T.condition.authorized-by: sitem.condition.authority = T.condition.authorized-by ELIF csr.series.condition.authorized-by: sitem.condition.authority = csr.series.condition.authorized-by // stage the addition sitem.addition.environment = T.condition.environment ems3 = mms_to_ems(csr.addition) sitem.addition.element-list = ems3 sitem.addition.cmtype = `endorsements` sitem.addition.authority = signer IF profile: sitem.addition.profile = profile evsitem[INDEXOF(sitem)] = sitem RETURN evsitem } Figure 41: Conditional Endorsement Series Triple Transformation 8.3.3.7.4. Keys Keys transformation involves mapping Attest Key and Device Identity triples into into a keys relation (see Section 8.3.2.2.4). An attest-key-triple-record (Figure 6) or an identity-triple-record (Figure 5) is transformed into a key-item (Figure 27) as described in Figure 42 pseudocode. Birkholz, et al. Expires 5 May 2027 [Page 89] Internet-Draft CoRIM November 2026 FUNC transform( T: attest-key-triple-record / identity-triple-record, verifier: [ + $crypto-key-type-choice ], profile: $profile-type-choice ) -> key-item { item := key-item::NEW() IF TYPEOF(T) == attest-key-triple-record: item.addition.key-type = attest-key item.condition.key-type = attest-key ELIF TYPEOF(T) == identity-triple-record: item.addition.key-type = identity-key item.condition.key-type = identity-key item.condition.environment = T.environment item.addition.environment = T.environment item.condition.key-list = T.key-list IF T.conditions.mkey: item.condition.key-id = T.conditions.mkey item.addition.key-id = T.conditions.mkey IF T.conditions.authorized-by: item.condition.authority = T.conditions.authorized-by item.addition.authority = verifier IF profile: item.addition.profile = profile RETURN item } Figure 42: Key Triples Transformation Note that keys are added under the authority of the Verifier because the key verification check is performed by the Verifier. After the keys relations are staged, processing commences as described in Section 8.3.4.3.3. 8.3.3.7.5. Domain Membership Transformation Domain membership transformation maps Domain Membership triples into dm relations (see Section 8.3.2.2.5). Birkholz, et al. Expires 5 May 2027 [Page 90] Internet-Draft CoRIM November 2026 Prior to adding a domain membership relation, a domain-membership- triple-record (Figure 7) is transformed into a domain-item (Figure 28) using the domain membership transformation algorithm Figure 43. FUNC transform( T: domain-membership-triple-record signer: [ + $crypto-key-type-choice ], profile: $profile-type-choice ) -> domain-item { item := domain-item::NEW() item.condition.members = T.members item.addition.environment = T.domain-id item.addition.members = T.members item.addition.authority = signer IF profile: item.addition.profile = profile RETURN item } Figure 43: Domain Membership Transformation Subsequent to transformation the domain membership relations are processed using the domain membership processing algorithm Section 8.3.4.3.4. 8.3.3.7.6. Trust Dependency Transformation Prior to adding a trust dependency relation, Trust Dependency triples trust-dependency-triple-record (Figure 8) are transformed into td relations (see Section 8.3.2.2.6) using the trust dependency transformation algorithm Figure 44. Birkholz, et al. Expires 5 May 2027 [Page 91] Internet-Draft CoRIM November 2026 FUNC transform( T: trust-dependcy-triple-record, signer: [ + $crypto-key-type-choice ], profile: $profile-type-choice ) -> trust-dependency-item item := T-ECT::NEW() item.condition.environment = T.domain-id item.condition.members = T.members item.addition.environment = T.domain-id item.addition.members = T.members item.addition.authority = signer IF profile: item.addition.profile = profile RETURN item } Figure 44: Trust Dependency Transformation Subsequent to transformation, the trust dependency relations are processed using the trust dependency processing algorithm Section 8.3.4.3.5. 8.3.3.8. Appraisal Context Initialization At the end of Phase 1 all of the extracted and validated tags are loaded into an "appraisal context", consisting of the ACS and the staging area. The ACS is initialized with all the addition ECTs in the ae relation: FUNC init_acs(ae: ae) -> ACS { FOREACH item IN ae: acs::APPEND(item.addition) RETURN acs } Figure 45: ACS Initialization The staging area is loaded with rv, ev, evs, keys, dm and td relations, in that order. Birkholz, et al. Expires 5 May 2027 [Page 92] Internet-Draft CoRIM November 2026 FUNC init_staging_area( rv: rv, ev: ev, evs: evs, keys: keys, dm: dm, dd: td, ) -> StagingArea { sa := StagingArea::NEW() IF rv: sa::APPEND(rv) IF ev: sa::APPEND(ev) IF evs: sa::APPEND(evs) IF keys: sa::APPEND(keys) IF dm: sa::APPEND(dm) IF td: sa::APPEND(td) RETURN sa } Figure 46: Staging Area Initialization 8.3.4. ACS Augmentation (Phases 2, 3 and 4) This section describes the "match and augment" algorithm, through which the ACS is updated incrementally to reflect the actual state of the Attester as asserted by RATS Roles (i.e., Attester, Reference Value Provider, and Endorser). Generally, the match and augment process involves pulling relations from the staging area one by one, in a specific order, and matching their conditions against the current state of the ACS according to the matching rules defined for each relation. If there is a match, the additions in the matched relation are added to the ACS, thereby providing its "augmentation". Otherwise, the algorithm moves on to the next relation. Any augmentations to the ACS (i.e., the acs::APPEND operation in Figure 47) MUST be atomic. Once all the relations in the staging area have been processed, the CoRIM processor forwards the augmented ACS to subsequent appraisal processors as needed. Birkholz, et al. Expires 5 May 2027 [Page 93] Internet-Draft CoRIM November 2026 FUNC match_and_augment(acs: ACS, sa: StagingArea) -> ACS { FOREACH rel IN sa: FOREACH item IN rel: IF acs::MATCH(item.condition): IF !acs::APPEND(item.addition): FAIL RETURN acs } Figure 47: Match and Augment Algorithm The acs::MATCH operation depends on the type of relation. The matching logic for each type of relation is described in the following sections. The acs::APPEND operation is defined by a pre-condition and a post- condition: * Pre-condition: addition is eligible to be appended. * Post-condition: the ACS resulting from the append satisfies the required consistency invariants (e.g., that a graph encoded across ACS entries remains acyclic). Both conditions are relation-specific; the concrete criteria for each relation are described in the following sections. If a relation's processing rules do not state a pre-condition or a post-condition, that condition is assumed to be a null operation (i.e., always satisfied) for that relation. acs::APPEND fails, leaving the ACS unchanged, if either the pre- condition or the post-condition does not hold. A failure of acs::APPEND MUST cause match_and_augment to terminate immediately, without processing any further relations or items: the appraisal that invoked it is thereby considered to have failed. 8.3.4.1. Ordering of Relations The order in which items within relations are processed is important. Processing a relation may result in ACS modifications that affect the matching behavior of other relations. The Verifier MUST ensure that any relation including a matching condition is processed after any other relation that modifies or adds an ACS entry with an environment matching the condition. This can be achieved by sorting the relations before processing, repeating the processing of some relations after ACS modifications, or using other algorithms. The "match and augment" algorithm described in Figure 47 assumes that Birkholz, et al. Expires 5 May 2027 [Page 94] Internet-Draft CoRIM November 2026 relations have been topologically sorted prior to loading into the staging area (Figure 46). 8.3.4.2. Reference Values Corroboration and Augmentation (Phase 3) Corroboration is the process of determining whether actual Attester state (as contained in the ACS) can be satisfied by Reference Values. 8.3.4.2.1. Processing rv Relations Reference Values are matched with ACS entries by iterating through the rv list. For each rv entry, the condition ECT is compared against an ACS ECT with cmtype 2 (i.e., evidence). If the two match, the following two steps are performed: 1. The element-list of the matched ACS ECT is copied to the element- list of the addition ECT. 2. The addition ECT is added to the ACS. Note that this new ACS item is essentially a copy of the matched evidence ECT, which has been re-asserted under the authority of the Reference Value Provider. 8.3.4.3. Endorsed Values Augmentation (Phase 4) Endorsed values augmentation is the process of adding Claims about the Attester's actual state with Endorser authority rather than Attester authority. Augmentation is predicated on a certain condition matching the actual state currently encoded in the ACS. 8.3.4.3.1. Processing ev Relations Endorsed Values and Conditional Endorsed Values are matched with ACS entries by iterating through the ev list. For each ev entry, the condition ECT is compared with an ACS ECT with cmtype 0, 1 or 2 (i.e., reference-values, endorsements or evidence). If the two match, the addition ECT is added to the ACS. 8.3.4.3.2. Processing evs Relations The Conditional Endorsement Series relation is processed using a modified match_and_augment function (see Figure 47) where SERIES- MATCH() calls MATCH() (see Figure 48). The first series item that matches terminates processing of subsequent series items. Birkholz, et al. Expires 5 May 2027 [Page 95] Internet-Draft CoRIM November 2026 The matched item is appended to the ACS. FUNC match_and_augment(acs: ACS, sa: StagingArea) -> ACS { FOREACH rel IN sa: FOREACH item IN rel: IF ser-add = SERIES-MATCH(acs, item.series): IF !acs::APPEND(ser-add): FAIL RETURN acs } FUNC SERIES-MATCH(acs: ACS, series: SERIES) -> Endorsement-addition-ECT { FOREACH sitem IN series: IF acs::MATCH(sitem.condition): RETURN sitem.addition } Figure 48: Series Match and Augment Algorithm 8.3.4.3.3. Processing keys Relations Keys relations identify cryptographic keys that require additional key verification steps before being appended to the ACS. Processing follows the algorithm as defined in Section 8.3.4. The keys list is iterated for each key-item where the acs::MATCH() function uses condition, if specified, to search the ACS for preexisting keys or to locate claims, where key verification is applied. Match conditions may return a variety of results including Evidence-addition-ECT, Reference-Value-addition-ECT, Endorsement-addition-ECT, and Key- addition-ECT ECTs. If Evidence-addition-ECT, Reference-Value- addition-ECT, or Endorsement-addition-ECT are matched, the element- list.element-map.measurement-values-map.cryptokeys list is appended to key-item.addition.key-list. If Key-addition-ECT ECTs are matched, its key-list is appended to key-item.addition.key-list. Key verification steps, such as Section 6 of [RFC5280], are applied to each key in key-item.addition.key-list. A key that is successfully verified is retained in key-item.addition.key-list; any other key is discarded. The pre-condition of acs::APPEND for keys relations is that key-item.addition.key-list contains at least one verified key. The post-condition of acs::APPEND for keys relations is null. Birkholz, et al. Expires 5 May 2027 [Page 96] Internet-Draft CoRIM November 2026 8.3.4.3.4. Processing dm Relations Domain Membership relations describe the expected topological arrangement of the Attester. Domains are matched with ACS entries by iterating through the dm list, in the staging area. For each dm entry (M-ECT), the condition ECT is compared with either an ACS Element ECT with cmtype 2 (i.e., evidence) or a Domain ECT (M-ECT). All other ECTs are ignored. If all the members environments in the condition ECT have a matching ECT in the ACS, the addition ECT is added to the ACS. The matching dm entry is pruned from the dm list. The post-condition of acs::APPEND for dm relations is that the domain-membership graph encoded by the ACS remains acyclic; the append does not take effect if this does not hold. If there is no match, processing moves to the next dm entry, till the list is exhausted; a single pass over the entire dm list constitutes one complete iteration. If there are additions to ACS, then the above algorithm is repeated until there are no more additions. The algorithm is terminated when there are no more additions to ACS. This algorithm can be optimized to complete in a single iteration, if the dm entries in the staging area and the ACS entries are topologically sorted (bottom up, from leaves to root). This specification does not mandate any specific topological sorting algorithm. 8.3.4.3.5. Processing td Relations The objective of processing a td relation is to verify that each edge in a trust dependency graph (TDG) has a corresponding edge in a domain membership graph (DMG). TDGs MUST be directed acyclic graphs (DAG) before they can be added to the ACS. TDGs need not be isomorphs of DMGs. The matching algorithm ensures that the td items queued for addition to the ACS are also Domain Membership ECTs already contained in the ACS. This matching algorithm is the plug-in for the parameter item- condition of acs::MATCH defined in Figure 47. Birkholz, et al. Expires 5 May 2027 [Page 97] Internet-Draft CoRIM November 2026 FUNC ACS::MATCH(condition: Trust-Dependency-condition-ECT) -> bool { FOREACH dm-item IN ACS.ECT(.cm==member): IF condition.environment == dm-item.environment: FOREACH trustee IN condition.trustees: IF !trustee::MEMBEROF(dm-item.members): BREAK # break inner loop, try another dm-item RETURN TRUE RETURN FALSE Figure 49: Process Trust Dependency Algorithm The pre-condition of acs::APPEND for td relations is that item.addition corresponds to a domain already present in the ACS. The post-condition of acs::APPEND for td relations is that the trust- dependency graph encoded by the ACS remains acyclic; the append does not take effect if this does not hold. Since TDGs need not be isomorphs of DMGs, this post-condition is independent of the one defined for dm relations in Section 8.3.4.3.4. Subsequent processing phases SHOULD evaluate the Trust Domain Graph against ACS corroborated Evidence to ensure trustee graphs are also trusted. For example, a Target Environment (TE-1) with corroborated Evidence that has another trustee Target Environment (TE-2), should ensure TE-2 also has corroborated Evidence before TE-1 is considered trustworthy. Additionally, a trust dependency might specify a strength of function requirement for TE-1. The trust dependency implies TE-2 should have at least the same strength of function as TE-1. 8.3.4.4. Rules of Comparison The matching component of the "match and augment" algorithm (see Section 8.3.4) relies on a standardized set of comparison rules for ECTs. These rules depend on the type of elements being compared. This section provides a normative description of the rules for comparing ECT elements found in relation conditions (referred to as C-ECTs for the remainder of this text) with ECTs in the ACS (referred to as ACS-ECTs for the remainder of this text). Birkholz, et al. Expires 5 May 2027 [Page 98] Internet-Draft CoRIM November 2026 When comparing a C-ECT against the ACS, the processor iterates over all ACS entries and attempts to match the C-ECT with each ACS entry. Typically, the comparison is between ECTs of the same type (i.e., Element ECTs are compared with Element ECTs, Key ECTs with Key ECTs and Domain ECTs with Domain ECTs). However, ECTs of different types can sometimes be compared if the comparison is based on common attributes (Figure 12). See Section 8.3.4.3.4 for an example of this, where the environments of M-ECTs and E-ECTs are compared. Conceptually, the processor creates a "matched entries" set and populates it with all ACS entries that match the C-ECT. If, after visiting all the entries in the ACS, the matched entries set is not empty, the C-ECT matches the ACS. Conversely, if the matched entries set is empty, the C-ECT does not match the ACS. If the C-ECT contains a profile and the profile defines an algorithm for a given codepoint, the processor MUST use the algorithm defined by the profile in comparisons involving that codepoint. If the condition ECT contains a profile, but the profile does not define an algorithm for a particular codepoint, the processor MUST use the standard algorithm described in this document for comparisons involving that codepoint. The specific comparisons performed depend on the type of relation being processed. In general, the processor will perform comparisons based on environment (see Section 8.3.4.4.1) as well as more specialized comparisons based on the type of ECT matched. Element ECTs will match on element-list (see Section 8.3.4.4.3), Key ECTs will match on key-list, Domain Membership ECTs will typically match on members (see Section 8.3.4.3.4) and Trust Dependency ECTs will typically match on trustees (see Section 8.3.4.3.5). // [TBC] Check, for each relation processing, where authority // comparisons apply. Each of these comparisons compares one attribute in the C-ECT against the same attribute in the ACS-ECT. If all the attributes match, the C-ECT matches the ACS-ECT. If any attributes do not match, the C-ECT does not match the ACS-ECT. Birkholz, et al. Expires 5 May 2027 [Page 99] Internet-Draft CoRIM November 2026 8.3.4.4.1. Environment Comparison The processor MUST compare each attribute which is present in the C-ECT's environment with the corresponding attribute in the ACS-ECT's environment using binary comparison. Before performing the binary comparison, the processor SHOULD convert the attributes in both environments into a form that meets the CBOR core deterministic encoding requirements described in Section 4.2 of [STD94]. If all the attributes which are present in the C-ECT environment (e.g., instance or group) are also present in the ACS-ECT and are binary identical, the two environments match. Otherwise, the environments do not match. In other words, a match succeeds when the C-ECT's environment is contained in the ACS-ECT's environment as defined by Attribute Path Containment (see Section 1.1.1) - i.e., for every Attribute Path defined in the C-ECT's environment, the ACS-ECT's environment defines the same path with an equal value. Any attribute that is present in the ACS-ECT but not in the C-ECT is ignored in the comparison. 8.3.4.4.2. Authority Comparison The comparison between a C-ECT's authority value and an ACS-ECT's authority value is as follows: if every entry in the C-ECT authority matches byte-by-byte an entry in the ACS-ECT authority, the authorities match. Otherwise, the authorities do not match. The order of the items within each authority does not affect the result of the comparison. When comparing two $crypto-key-type-choice items for equality, the processor MUST treat them as equal if their deterministic CBOR encoding is binary equal. 8.3.4.4.3. Element List Comparison A C-ECT's element-list matches an ACS-ECT's element-list if all the element-maps in the C-ECT's element-list match the element-maps in the ACS-ECT's element-list. Any element-map that is present in the ACS-ECT's element-list but not in the C-ECT's is ignored in the comparison. The rules for matching element-maps are described in Section 8.3.4.4.4. Birkholz, et al. Expires 5 May 2027 [Page 100] Internet-Draft CoRIM November 2026 8.3.4.4.4. Element Map Comparison The C-ECT's element-map matches an ACS-ECT's element-map if both the element-id and element-claims match. element-claims matching uses Attribute Path Containment (see Section 1.1.1): every Attribute Path defined in the C-ECT's element- claims MUST be defined in the ACS-ECT's element-claims, and the ACS- ECT value at each such path MUST satisfy the corresponding C-ECT value according to the rules in Section 8.3.4.4.5.1; additional attributes in the ACS-ECT are ignored. Two element-ids are considered the same if they are either both omitted, or both present with binary identical deterministic encodings. Before performing the binary comparison, the processor SHOULD convert the element-id attributes into a form that meets the CBOR core deterministic encoding requirements described in Section 4.2 of [STD94]. The rules for matching element-claims are described in Section 8.3.4.4.5. 8.3.4.4.5. Measurement Values Map Comparison The C-ECT's element-claims match an ACS-ECT's element-claims when the C-ECT's element-claims is contained in the ACS-ECT's element-claims as defined by Attribute Path Containment (Section 1.1.1). At each Attribute Path present in both maps, the ACS-ECT value MUST satisfy the C-ECT value. For most attribute types, satisfaction means equality; for range and bound types (for example, int-range and tagged-min-svn), satisfaction means that the ACS-ECT value lies within the bounds expressed by the C-ECT value, as specified in Section 8.3.4.4.5.1. Otherwise, the element claims do not match. The rules for matching a single measurement-values-map attribute are described in Section 8.3.4.4.5.1. 8.3.4.4.5.1. Comparison of a Single Measurement Values Map Attribute The algorithm used to compare two values of a measurement-values-map attribute depends on the attribute's type. In Attribute Path Containment comparisons (Section 1.1.1), the C-ECT value at an Attribute Path plays the role of the *condition* and the ACS-ECT value at the same path plays the role of the *entry*. The comparison algorithms in this section define when an entry value Birkholz, et al. Expires 5 May 2027 [Page 101] Internet-Draft CoRIM November 2026 *satisfies* a condition value at that path. The processor needs to select the appropriate algorithm for the given attribute, including any extensions defined by a supported profile. Non-negative codepoints represent standard data representations. The comparison algorithms for these are defined in this document (in the sections below) or in other specifications. Some attributes allow different types. These are designated by a CBOR tag that allows clear type disambiguation. Negative codepoints represent profile-defined data representations. The processor MUST use the attribute name, the profile associated with the condition ECT, and, if present, the CBOR tag value to select the comparison algorithm. An attribute defined by this specification that has no comparison subsection of its own is compared by binary comparison. Before performing the binary comparison, the processor MUST convert the C-ECT value and the ACS-ECT value into a form that meets the CBOR core deterministic encoding requirements described in Section 4.2 of [STD94]. The comparison returns true if and only if the two encodings are binary identical. This applies to mac-addr (codepoint 6), ip-addr (codepoint 7), serial-number (codepoint 8), ueid (codepoint 9), uuid (codepoint 10) and name (codepoint 11). If the processor does not recognize an attribute, or is otherwise unable to determine the applicable comparison algorithm for it, it MUST behave as though the C-ECT does not match the ACS-ECT. The following subsections define the comparison algorithms for the other measurement-values-map attributes defined by this specification. 8.3.4.4.5.2. Comparison for version entries The value stored under measurement-values-map codepoint 0 is of type version-map. Since, in general - with the exception of semver - they are colloquial versions that cannot specify ordering, two version-map values can only be compared for equality. 8.3.4.4.5.3. Comparison for svn entries The value stored under measurement-values-map codepoint 1 is a security version number of type svn-type-choice. Birkholz, et al. Expires 5 May 2027 [Page 102] Internet-Draft CoRIM November 2026 If the ACS-ECT's svn-type-choice is a svn or tagged-svn (i.e., uint or a uint wrapped in tag 552), comparison with the uint in the C-ECT is as follows: * If the C-ECT value is of type svn or tagged-svn, an equality comparison is performed on the uint components. The comparison MUST return true if the uint values are equal. * If the C-ECT value is of type tagged-min-svn, a minimum comparison is performed. The comparison MUST return true if the uint value in the C-ECT is less than or equal to the value in the ACS-ECT. If the ACS-ECT's svn-type-choice is tagged-min-svn (i.e., uint wrapped in tag 553), then comparison with the uint in the C-ECT is as follows. * If the C-ECT value for measurement-values-map codepoint 1 is svn or tagged-svn (i.e., uint or a uint wrapped in tag 552), the comparison is not allowed and MUST return false. * If the condition ECT value for measurement-values-map codepoint 1 is a tagged-min-svn (i.e., uint wrapped in tag 553), an equality comparison is performed. The comparison MUST return true if the uint values are equal. A minimum SVN is only meaningful as an entry value when it is an endorsed value that has been added to the ACS. The condition therefore treats the minimum SVN as an exact state, rather than as something to be compared with inequality. The pseudocode for the above algorithm is shown in Figure 50. Birkholz, et al. Expires 5 May 2027 [Page 103] Internet-Draft CoRIM November 2026 FUNC compare( c_ect: svn-type-choice, acs_ect: svn-type-choice ) -> bool { IF is_plain_svn(acs_ect): IF is_plain_svn(c_ect): RETURN get_svn_value(c_ect) == get_svn_value(acs_ect) ELSE: RETURN get_svn_value(c_ect) <= get_svn_value(acs_ect) ELSE: IF is_plain_svn(c_ect): RETURN false ELSE: RETURN get_svn_value(c_ect) == get_svn_value(acs_ect) } FUNC get_svn_value(v: svn-type-choice) -> uint { IF TYPEOF(v) == svn: RETURN v ELIF TYPEOF(v) == tagged-svn: RETURN ~v ELIF TYPEOF(v) == tagged-min-svn: RETURN ~v } FUNC is_plain_svn(v: svn-type-choice) -> bool { RETURN TYPEOF(v) == svn OR TYPEOF(v) == tagged-svn } Figure 50: SVN Comparison 8.3.4.4.5.4. Comparison for digests entries A digests entry contains one or more digests, each measuring the same object. When multiple digests are provided, each represents a different acceptable algorithm to the C-ECT author. In the simplest case, a C-ECT digests entry containing one digest matches an ACS-ECT entry containing a single entry with the same algorithm and value. Birkholz, et al. Expires 5 May 2027 [Page 104] Internet-Draft CoRIM November 2026 If there are multiple algorithms in common between the C-ECT and ACS- ECT, the bytes paired with common algorithms MUST be equal. This is to prevent downgrade attacks. The processor MUST treat two algorithm identifiers as equal if they have the same deterministic binary encoding. If both an integer and a string representation are defined for an algorithm, then entities creating ECTs SHOULD use the integer representation. If C-ECT and ACS-ECT use different names for the same algorithm, and the processor does not recognize that they are the same, then a downgrade attack is possible. The comparison MUST return false if the CBOR encoding of the digests entry in the C-ECT or the ACS-ECT value with the same codepoint is incorrect. For example, if fields are missing or if they are the wrong type. The comparison MUST return false if the C-ECT digests entry does not contain any digests. The comparison MUST return false if either digests entry contains multiple values for the same hash algorithm. The processor iterates over the C-ECT digests array to locate the common hash algorithm identifiers which are present in both the C-ECT and in the ACS-ECT. The comparison MUST return false if there are no hash algorithms in common between the C-ECT and the ACS-ECT. The comparison MUST return false if the value associated with any common hash algorithm identifier in the C-ECT differs from the value for the same algorithm identifier in the ACS-ECT. If all the values associated with the common hash algorithm identifiers match, the comparison returns true. 8.3.4.4.5.5. Comparison for flags entries The value stored under measurement-values-map codepoint 3 is of type flags-map. Each flag is compared separately. For each flag present in the C-ECT flags-map, the comparison MUST return false if that flag is absent from the ACS-ECT flags-map or has a different value. Flags present in the ACS-ECT flags-map but absent from the C-ECT flags-map are ignored. A flag that is absent from the ACS-ECT flags-map is not treated as false. If every flag in the C-ECT flags-map matches, the same flag in the ACS-ECT flags-map, the comparison returns true. 8.3.4.4.5.6. Comparison for raw-value entries A raw-value entry contains binary data. Birkholz, et al. Expires 5 May 2027 [Page 105] Internet-Draft CoRIM November 2026 The value stored under measurement-values-map codepoint 4 in an ACS- ECT MUST be a raw-value entry, which MUST be tagged-bytes. The value stored under the C-ECT measurement-values-map codepoint 4 may additionally be a tagged-masked-raw-value entry, which specifies an expected value and a mask. If the C-ECT measurement-values-map codepoint 4 is of type tagged- bytes, and there is no value stored under codepoint 5, the processor treats it as if it were a tagged-masked-raw-value with the value field holding the same contents and a mask of the same length as the value, with all bits set. The standard comparison function defined in this document removes the CBOR tag before performing the comparison. For backwards compatibility, if the C-ECT measurement-values-map codepoint 4 is of type tagged-bytes, and there is a mask stored under codepoint 5, the processor treats it as a tagged-masked-raw-value with the value field holding the same contents and a mask holding the contents of codepoint 5. Codepoint 5 is used only as part of the codepoint 4 comparison and is not compared on its own, so it does not need to be present in the ACS-ECT. The comparison MUST return false if the lengths of the ACS-ECT entry value and the C-ECT value are different. The comparison MUST return false if the lengths of the C-ECT mask and value are different. The comparison MUST use the mask to determine which bits to compare. If a bit in the mask is 0 then this indicates that the corresponding bit in the ACS-ECT value is ignored. The comparison returns true if, for every bit position in the mask whose value is 1, the corresponding bits in both values are equal. 8.3.4.4.5.7. Comparison for cryptokeys entries The CBOR tag of the first entry in the C-ECT cryptokeys array is compared with the CBOR tag of the first entry of the ACS-ECT cryptokeys value. If the CBOR tags match, then the bytes following the CBOR tag from the C-ECT entry are compared byte-by-byte with the bytes following the CBOR tag from the ACS-ECT entry. If the byte strings match and there are more array entries, the next C-ECT array entry is compared with the next ACS-ECT array entry. If all the C-ECT array entries match their corresponding entries in the ACS-ECT array, the C-ECT cryptokeys match. Otherwise, the C-ECT cryptokeys do not match. Birkholz, et al. Expires 5 May 2027 [Page 106] Internet-Draft CoRIM November 2026 8.3.4.4.5.8. Comparison for Integrity Registers For each Integrity Register entry in the C-ECT, the processor will use the associated identifier (i.e., integrity-register-id-type- choice) to look up the matching Integrity Register entry in the ACS- ECT. If no matching entry is found, the comparison MUST return false. Instead, if an entry is found, the digest comparison proceeds as defined in Section 8.3.4.4.5.4 after equivalence has been established according to Section 5.1.4.7. Note that it is not required for all the entries in the C-ECT to be used during matching: the C-ECT may represent only a subset of the device's register space. In TPM parlance, a TPM "quote" may report all PCRs in Evidence, while a C-ECT could describe a subset of PCRs. 8.3.4.4.5.9. Comparison for int-range entries The ACS-ECT value stored under measurement-values-map codepoint 15 is an int range value of int-range-type-choice. Consider an int ACS-ECT value named ENTRY in a measurement-values-map codepoint (e.g., 15) that allows comparing int against either another int or an int-range named CONDITION. * If CONDITION is an int then an equality comparison is performed with ENTRY. * If CONDITION is an int-range (CBOR tag 564), then a range inclusion comparison is performed. The comparison MUST return true if and only if all the following conditions are true: - CONDITION.min is null or ENTRY is greater than or equal to CONDITION.min. - CONDITION.max is null or ENTRY is less than or equal to CONDITION.max. Consider an int-range (CBOR tag 564) value named ENTRY in a measurement-values-map codepoint (e.g., 15) that allows comparing an int-range against either another int-range or an int named CONDITION. * If CONDITION is an int, then the comparison MUST return true if and only if ENTRY.min and ENTRY.max are both equal to CONDITION. * If CONDITION is an int-range (CBOR tag 564), then a range subsumption comparison is performed (i.e., the condition range includes all values of the entry range). The comparison MUST return true if and only if all the following conditions are true: Birkholz, et al. Expires 5 May 2027 [Page 107] Internet-Draft CoRIM November 2026 - CONDITION.min is null or ENTRY.min is an int that is greater than or equal to CONDITION.min - CONDITION.max is null or ENTRY.max is an int that is less than or equal to CONDITION.max. 8.3.4.4.5.10. Comparison for bool entries The value stored under measurement-values-map codepoint 16 is of type bool-matcher, which is a bare bool. An equality comparison is performed between the C-ECT value and the ACS-ECT value. Set match (CBOR tag 566) is not defined for bool since bool has only two possible values. A set of two or more elements represents the full domain, which can be already expressed by omitting the entry. 8.3.4.4.5.11. Comparison for integer entries The value stored under measurement-values-map codepoint 17 is of type integer-matcher. The ACS-ECT value at this codepoint is always a bare int (see Section 5.1.4.9); the comparison rules below are defined against the form of the C-ECT value. If the C-ECT value is a bare int, an equality comparison is performed with the ACS-ECT value. If the C-ECT value is a tagged-integer-range (CBOR tag 565), null in the first element represents negative infinity (no lower bound) and null in the second element represents positive infinity (no upper bound). The comparison MUST return true if and only if both of the following conditions are met: * The C-ECT min is null or the ACS-ECT value is greater than or equal to min. * The C-ECT max is null or the ACS-ECT value is less than or equal to max. At least one of min and max of a tagged-integer-range MUST be non- null. A tagged-integer-range whose min and max are both null is malformed and MUST be rejected; to match any value, the entry is omitted. If the C-ECT value is a tagged-integer-set (CBOR tag 566), the comparison MUST return true if and only if the ACS-ECT value equals any element of the set. Birkholz, et al. Expires 5 May 2027 [Page 108] Internet-Draft CoRIM November 2026 8.3.4.4.5.12. Comparison for float entries The value stored under measurement-values-map codepoint 20 is of type float-matcher. The ACS-ECT value at this codepoint is always a bare float (see Section 5.1.4.9); the comparison rules below are defined against the form of the C-ECT value. Comparison is numeric, not byte-wise: it does not depend on the width (e.g., half, single or double precision) or on the preferred or non- preferred serialization used to encode a value. * +0.0 and -0.0 are equal. * +Infinity and -Infinity are equal only to themselves, and order above and below all finite values, respectively. NaN MUST NOT appear in a float-matcher, whether as a bare value, as a range bound, or as a set element. A float-matcher that contains a NaN is malformed and MUST be rejected. An Evidence transformation MUST NOT produce a NaN as the ACS-ECT value; Evidence that would result in one MUST be rejected. If the C-ECT value is a bare float, an equality comparison is performed with the ACS-ECT value. If the C-ECT value is a tagged-float-range (CBOR tag 565), null in the first element represents negative infinity (no lower bound) and null in the second element represents positive infinity (no upper bound). The comparison MUST return true if and only if both of the following conditions are met: * The C-ECT min is null or the ACS-ECT value is greater than or equal to min. * The C-ECT max is null or the ACS-ECT value is less than or equal to max. The min and max of a tagged-float-range MUST NOT be +Infinity or -Infinity; null is the only way to express an unbounded range. A tagged-float-range that violates this requirement is malformed and MUST be rejected. At least one of min and max of a tagged-float-range MUST be non-null. A tagged-float-range whose min and max are both null is malformed and MUST be rejected; to match any value, the entry is omitted. Birkholz, et al. Expires 5 May 2027 [Page 109] Internet-Draft CoRIM November 2026 If the C-ECT value is a tagged-float-set (CBOR tag 566), the comparison MUST return true if and only if the ACS-ECT value equals any element of the set. 8.3.4.4.5.13. Comparison for text entries The value stored under measurement-values-map codepoint 18 is of type text-matcher. The ACS-ECT value at this codepoint is always a bare text (see Section 5.1.4.9); the comparison rules below are defined against the form of the C-ECT value. If the C-ECT value is a bare text, an equality comparison is performed with the ACS-ECT value. If the C-ECT value is a tagged-text-set (CBOR tag 566), the comparison MUST return true if and only if the ACS-ECT value equals any element of the set. 8.3.4.4.5.14. Comparison for bytes entries The value stored under measurement-values-map codepoint 19 is of type bytes-matcher. The ACS-ECT value at this codepoint is always a bare bytes (see Section 5.1.4.9); the comparison rules below are defined against the form of the C-ECT value. If the C-ECT value is a bare bytes, an equality comparison is performed with the ACS-ECT value. If the C-ECT value is a tagged-bytes-set (CBOR tag 566), the comparison MUST return true if and only if the ACS-ECT value equals any element of the set. 8.3.4.4.6. Profile-directed Comparison A profile MUST specify comparison algorithms for its additions to $-prefixed CoRIM CDDL codepoints when this specification does not prescribe binary comparison. The profile MUST specify how to compare the CBOR tagged value against the ACS. 8.3.5. Handoff Once all the relations in the staging area have been processed, the computed ACS is ready to be handed over to the Verifier for further processing in subsequent phases. Typically, the ACS is passed to a policy engine that applies a policy to deduce high-level characteristics of the Attester from the low-level information contained in the ACS. This information can then be encoded in an Attestation Result that can be understood by a Relying Party, which Birkholz, et al. Expires 5 May 2027 [Page 110] Internet-Draft CoRIM November 2026 does not need to know all the details in order to make a trust decision. 8.3.6. Example Appraisal The following example describes the appraisal of a PSA Attester [RFC9783] from the fictitious vendor "Acme Inc.", which uses the CoRIM profile documented in [I-D.fdb-rats-psa-endorsements]. 8.3.6.1. Input CoRIMs In this scenario, the Verifier obtains two CoRIM files from two different actors in the supply chain: * The device manufacturer (Acme Inc.); and * A certifier (Certifier Inc.), which has evaluated the device according to the PSA Certified scheme. The manufacturer's CoRIM contains a single CoMID with two Reference Values triples (see Figure 51) describing two acceptable states of the Attester. The Attester is identified by the class attribute Implementation ID with the value 6163..3031. One state has a digest of 9a27..86aa for the "PRoT" component, and the other has a digest of a3fe..5065. For the remainder of this section, we will assume that the CoRIM containing this CoMID is signed using the manufacturer's certificate, which has a thumbprint of 482e..78b3. / concise-mid-tag / { / comid.tag-identity / 1 : { / comid.tag-id / 0 : "acme.example/gizmo-v1" }, / comid.entity / 2 : [ { / comid.entity-name / 0 : "ACME Inc.", / comid.reg-id / 1 : 32("https://acme.example"), / comid.role / 2 : [ 0 ] / tag-creator / } ], / comid.triples / 4 : { / comid.reference-triples / 0 : [ [ / environment-map / { / comid.class / 0 : { / comid.class-id / 0 : / tagged-bytes / 560( h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031' ) Birkholz, et al. Expires 5 May 2027 [Page 111] Internet-Draft CoRIM November 2026 } }, [ / measurement-map / { / comid.mkey / 0 : "psa.software-component", / comid.mval / 1 : { / comid.digests / 2 : [ [ / hash-alg-id / "sha-256", / hash-value / h'9a271f2a916b0b6ee6cecb2426f0b320 6ef074578be55d9bc94f6f3fe3ab86aa' ] ], / name / 11 : "PRoT", / cryptokeys / 13 : [ 560(h'5378796307535df3ec8d8b15a2 e2dc5641419c3d3060cfe32238 c0fa973f7aa3') ] } } ] ], [ / environment-map / { / comid.class / 0 : { / comid.class-id / 0 : / tagged-bytes / 560( h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031' ) } }, [ / measurement-map / { / comid.mkey / 0 : "psa.software-component", / comid.mval / 1 : { / comid.digests / 2 : [ [ / hash-alg-id / "sha-256", / hash-value / h'a3fe9f414586c0d3cacbe3b6920a09d8 718e503bca22e23fef882203bf765065' ] ], / name / 11 : "PRoT", / cryptokeys / 13 : [ 560(h'5378796307535df3ec8d8b15a2 e2dc5641419c3d3060cfe32238 c0fa973f7aa3') ] } } ] ] ] } } Birkholz, et al. Expires 5 May 2027 [Page 112] Internet-Draft CoRIM November 2026 Figure 51: Example Manufacturer CoMID The CoMID from the certifier contains a Conditional Endorsement triple that describes the Attester who was granted the security certification 1234567890123 - 12345 (see Figure 52). This Attester has Implementation ID 6163..3031 and the digest associated with the "PRoT" component is 9a27..86aa. In the triple, the security certification is represented as endorsements, while the target identification information is represented as conditions. / concise-mid-tag / { / comid.tag-identity / 1 : { / comid.tag-id / 0 : "certifier.example/gizmo-v1" }, / comid.entity / 2 : [ { / comid.entity-name / 0 : "Certifier Inc.", / comid.reg-id / 1 : 32("https://certifier.example"), / comid.role / 2 : [ 0 ] / tag-creator / } ], / comid.triples / 4 : { / comid.conditional-endorsement-triple / 10 : [ [ / conditions / [ / stateful-environment / [ / environment-map / { / comid.class / 0 : { / comid.class-id / 0 : / tagged-bytes / 560( h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031' ) } }, / claims-list / [ / measurement-map / { / comid.mkey / 0 : "psa.software-component", / comid.mval / 1 : { / comid.digests / 2 : [ [ / hash-alg-id / "sha-256", / hash-value / h'9a271f2a916b0b6ee6cecb2426f0b320 6ef074578be55d9bc94f6f3fe3ab86aa' ] ], / name / 11 : "PRoT", / cryptokeys / 13 : [ 560(h'5378796307535df3ec8d8b15a2 e2dc5641419c3d3060cfe32238 c0fa973f7aa3') ] } } Birkholz, et al. Expires 5 May 2027 [Page 113] Internet-Draft CoRIM November 2026 ] ] ], / endorsements / [ / endorsed-triple / [ / environment / { / comid.class / 0 : { / comid.class-id / 0 : / tagged-bytes / 560( h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031' ) } }, [ / measurement-map / { / comid.mkey / 0 : "psa.certification", / comid.mval / 1 : { / psa.cert-num / 100 : "1234567890123 - 12345" } } ] ] ] ] ] } } Figure 52: Example Certifier CoMID For the remainder of this section, we will assume that the CoRIM containing this CoMID is signed using the certifier's certificate, which has a thumbprint of 768f..75b1. 8.3.6.2. Input Evidence The Verifier obtains Evidence from a PSA Attester in the format described in [RFC9783] and verifies its cryptographic integrity and validity. 8.3.6.3. Internal Representations As described in Section 8.3.3, once all the "raw" inputs have been validated, input transformations can start. Birkholz, et al. Expires 5 May 2027 [Page 114] Internet-Draft CoRIM November 2026 The two Reference Values triples from the manufacturer's CoMID are mapped to their corresponding rv-items (Figure 53, Figure 54) using the transformations defined in Figure 38. The first triple: Birkholz, et al. Expires 5 May 2027 [Page 115] Internet-Draft CoRIM November 2026 { "condition": { "environment": { 0: { 0: 560(h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031') } }, "element-list": [ { "element-id": "psa.software-component", "element-claims": { 2: [ [ "sha-256", h'9a271f2a916b0b6ee6cecb2426f0b320 6ef074578be55d9bc94f6f3fe3ab86aa' ] ], 11: "PRoT", 13: [ 560(h'5378796307535df3ec8d8b15a2e2dc56 41419c3d3060cfe32238c0fa973f7aa3') ] } } ] }, "addition": { "environment": { 0: { 0: 560(h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031') } }, "authority": [ 559([ "sha-256", h'482e829ad29ac6ea6eda2d47d1d93a00 2bf41d9d88710ba972c36e59038f78b3' ]) ], "cmtype": 0, "profile": 32("tag:arm.com,2025:psa#1.0.0") } } Figure 53: First rv Relation Item The second triple: Birkholz, et al. Expires 5 May 2027 [Page 116] Internet-Draft CoRIM November 2026 { "condition": { "environment": { 0: { 0: 560(h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031') } }, "element-list": [ { "element-id": "psa.software-component", "element-claims": { 2: [ [ "sha-256", h'a3fe9f414586c0d3cacbe3b6920a09d8 718e503bca22e23fef882203bf765065' ] ], 11: "PRoT", 13: [ 560(h'5378796307535df3ec8d8b15a2e2dc56 41419c3d3060cfe32238c0fa973f7aa3') ] } } ] }, "addition": { "environment": { 0: { 0: 560(h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031') } }, "authority": [ 559([ "sha-256", h'482e829ad29ac6ea6eda2d47d1d93a00 2bf41d9d88710ba972c36e59038f78b3' ]) ], "cmtype": 0, "profile": 32("tag:arm.com,2025:psa#1.0.0") } } Figure 54: Second rv Relation Item Birkholz, et al. Expires 5 May 2027 [Page 117] Internet-Draft CoRIM November 2026 Note the authorities in the addition ECT of both items, which are set to 482e..78b3, and correspond to the thumbprint of the manufacturer's signing certificate. The Conditional Endorsement triple from the certifier's CoMID is mapped to its corresponding ev-item (Figure 55) using the transformation defined in Figure 40. { "condition": [ { "environment": { 0: { 0: 560(h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031') } }, "element-list": [ { "element-id": "psa.software-component", "element-claims": { 2 : [ [ "sha-256", h'9a271f2a916b0b6ee6cecb2426f0b320 6ef074578be55d9bc94f6f3fe3ab86aa' ] ], 11 : "PRoT", 13 : [ 560(h'5378796307535df3ec8d8b15a2 e2dc5641419c3d3060cfe32238 c0fa973f7aa3') ] } } ] } ], "addition": [ { "environment": { 0: { 0: 560(h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031') } }, "element-list": [ { "element-id": "psa.certification", Birkholz, et al. Expires 5 May 2027 [Page 118] Internet-Draft CoRIM November 2026 "element-claims": { 100: "1234567890123 - 12345" } } ], "authority": [ 559([ "sha-256", h'768ff09154f6aacda857cb175ef29cf9 d23ef9c38c69efdbf20354dbfd7875b1' ]) ], "cmtype": 1, "profile": 32("tag:arm.com,2025:psa#1.0.0") } ] } Figure 55: First (and only) ev Relation Item Note the authority in the addition ECT, which is set to 768f..75b1, and corresponds to the thumbprint of the certifier's signing certificate. Evidence from the PSA Attester is transformed into the corresponding ae-item using the transformation defined in [I-D.fdb-rats-psa-endorsements]: Birkholz, et al. Expires 5 May 2027 [Page 119] Internet-Draft CoRIM November 2026 { "addition": { "environment": { 0: { 0: 560(h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031') }, 1: 550(h'01 4ca3e4f50bf248c39787020d68ffd05c 88767751bf2645ca923f57a98becd296') }, "element-list": [ { "element-id": "psa.software-component", "element-claims": { 2: [ [ "sha-256", h'9a271f2a916b0b6ee6cecb2426f0b320 6ef074578be55d9bc94f6f3fe3ab86aa' ] ], 11: "PRoT", 13: [ 560(h'5378796307535df3ec8d8b15a2e2dc56 41419c3d3060cfe32238c0fa973f7aa3') ] } } ], "authority": [ 554("-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAETl4iCZ47zrRbRG0TVf0dw7VFlHtv 18HInYhnmMNybo+A1wuECyVqrDSmLt4QQzZPBECV8ANHS5HgGCCSr7E/Lg== -----END PUBLIC KEY----- ") ], "cmtype": 2, "profile": 32("tag:arm.com,2025:psa#1.0.0") } } Figure 56: ae-item Note the authority in the ECT, which is set to MFkw..Lg==, and corresponds to the Attester's PEM-encoded SPKI. Birkholz, et al. Expires 5 May 2027 [Page 120] Internet-Draft CoRIM November 2026 8.3.6.4. Appraisal As described in Section 8.3.3.8, the appraisal context is bootstrapped by loading the ae ECT(s) into the ACS, and the rv and ev relations into the Staging Area. Then, ACS augmentation described in Section 8.3.4 can begin. The first relation to be processed is rv, according to the rules described in Section 8.3.4.2.1. The condition of the first rv-item (Figure 53) is matched against the ACS which, at this time, contains a single ECT obtained from the ae- item (Figure 56). The cmtype of the ACS-ECT is 2 (evidence), which is exactly the type rv-items need to match against. When the two are compared, it is found that the environments of the rv-item condition and the ACS-ECT match (note that the instance identifier in the ACS- ECT is ignored because it is not present in the rv-item). The matching algorithm then proceeds to try to match the respective element-lists. Both lists contain a single element, whose ID and claims are a perfect match. Therefore, all the matching criteria are satisfied and the rv-item addition ECT is appended to the ACS. Before this addition is made, the matched element from the rv-item condition is copied to the addition element-list. The ACS now contains two ECTs, one with cmtype 2 (evidence), and a second one with cmtype 0 (reference-value) that corroborates the first one with manufacturer authority (Figure 57). [ / Evidence ECT / { "environment": { 0: { 0: 560(h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031') }, 1: 550(h'01 4ca3e4f50bf248c39787020d68ffd05c 88767751bf2645ca923f57a98becd296') }, "element-list": [ { "element-id": "psa.software-component", "element-claims": { 2: [ [ "sha-256", h'9a271f2a916b0b6ee6cecb2426f0b320 6ef074578be55d9bc94f6f3fe3ab86aa' Birkholz, et al. Expires 5 May 2027 [Page 121] Internet-Draft CoRIM November 2026 ] ], 11: "PRoT", 13: [ 560(h'5378796307535df3ec8d8b15a2e2dc56 41419c3d3060cfe32238c0fa973f7aa3') ] } } ], "authority": [ 554("-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAETl4iCZ47zrRbRG0TVf0dw7VFlHtv 18HInYhnmMNybo+A1wuECyVqrDSmLt4QQzZPBECV8ANHS5HgGCCSr7E/Lg== -----END PUBLIC KEY----- ") ], "cmtype": 2, "profile": 32("tag:arm.com,2025:psa#1.0.0") }, / Reference Value ECT / { "environment": { 0: { 0: 560(h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031') } }, "element-list": [ { "element-id": "psa.software-component", "element-claims": { 2: [ [ "sha-256", h'9a271f2a916b0b6ee6cecb2426f0b320 6ef074578be55d9bc94f6f3fe3ab86aa' ] ], 11: "PRoT", 13: [ 560(h'5378796307535df3ec8d8b15a2e2dc56 41419c3d3060cfe32238c0fa973f7aa3') ] } } ], "authority": [ 559([ "sha-256", h'482e829ad29ac6ea6eda2d47d1d93a00 2bf41d9d88710ba972c36e59038f78b3' ]) Birkholz, et al. Expires 5 May 2027 [Page 122] Internet-Draft CoRIM November 2026 ], "cmtype": 0, "profile": 32("tag:arm.com,2025:psa#1.0.0") } ] Figure 57: ACS State after Corroboration The algorithm then moves on to the second rv-item (Figure 54), checking its condition against the ACS. Once again, the ACS-ECT with cmtype 2 (evidence) is selected for matching. This time, the environments match, but the state represented in the rv-item's element-list is not (the digest differs). This results in a no-op on the ACS. Next, the ev relation is popped from the Staging Area for processing according to the rules described in Section 8.3.4.3.1. The condition of the first (and only) ev-item (Figure 55) is then matched against the ACS. The only applicable ACS-ECT is the one with cmtype 2 (evidence). // The fact that {{sec-proc-ev-rel}} requires matching against // reference values seems incorrect. When compared, the environment in the ev-item condition matches that of the ACS-ECT (again, the instance identifier in the ACS-ECT is ignored because it is not present in the ev-item), and the matching algorithm proceeds to try to match the respective element-lists. Both lists contain a single element, whose ID and claims are an exact match. Therefore, all the matching criteria are satisfied and the ev-item addition ECT is appended to the ACS. The ACS now contains three ECTs, one with cmtype 2 (evidence), a second with cmtype 0 (reference-value), which corroborates the first with manufacturer authority, and a third one with cmtype 1 (endorsements) which adds the PSA certification identifier as an endorsed value for the appraised environment with certifier's authority (Figure 58). [ / Evidence ECT / { "environment": { 0: { 0: 560(h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031') }, 1: 550(h'01 4ca3e4f50bf248c39787020d68ffd05c 88767751bf2645ca923f57a98becd296') }, Birkholz, et al. Expires 5 May 2027 [Page 123] Internet-Draft CoRIM November 2026 "element-list": [ { "element-id": "psa.software-component", "element-claims": { 2: [ [ "sha-256", h'9a271f2a916b0b6ee6cecb2426f0b320 6ef074578be55d9bc94f6f3fe3ab86aa' ] ], 11: "PRoT", 13: [ 560(h'5378796307535df3ec8d8b15a2e2dc56 41419c3d3060cfe32238c0fa973f7aa3') ] } } ], "authority": [ 554("-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAETl4iCZ47zrRbRG0TVf0dw7VFlHtv 18HInYhnmMNybo+A1wuECyVqrDSmLt4QQzZPBECV8ANHS5HgGCCSr7E/Lg== -----END PUBLIC KEY----- ") ], "cmtype": 2, "profile": 32("tag:arm.com,2025:psa#1.0.0") }, / Reference Value ECT / { "environment": { 0: { 0: 560(h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031') } }, "element-list": [ { "element-id": "psa.software-component", "element-claims": { 2: [ [ "sha-256", h'9a271f2a916b0b6ee6cecb2426f0b320 6ef074578be55d9bc94f6f3fe3ab86aa' ] ], 11: "PRoT", 13: [ 560(h'5378796307535df3ec8d8b15a2e2dc56 41419c3d3060cfe32238c0fa973f7aa3') ] Birkholz, et al. Expires 5 May 2027 [Page 124] Internet-Draft CoRIM November 2026 } } ], "authority": [ 559([ "sha-256", h'482e829ad29ac6ea6eda2d47d1d93a00 2bf41d9d88710ba972c36e59038f78b3' ]) ], "cmtype": 0, "profile": 32("tag:arm.com,2025:psa#1.0.0") }, / Endorsed Value ECT / { "environment": { 0: { 0: 560(h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031') } }, "element-list": [ { "element-id": "psa.certification", "element-claims": { 100: "1234567890123 - 12345" } } ], "authority": [ 559([ "sha-256", h'768ff09154f6aacda857cb175ef29cf9 d23ef9c38c69efdbf20354dbfd7875b1' ]) ], "cmtype": 1, "profile": 32("tag:arm.com,2025:psa#1.0.0") } ] Figure 58: ACS State after Endorsements Augmentation At this point, all the relations in the Staging Area have been processed, and the match_and_augment algorithm (Figure 47) terminates, returning the computed ACS. Birkholz, et al. Expires 5 May 2027 [Page 125] Internet-Draft CoRIM November 2026 9. Implementation Status This section is to be removed before publishing as an RFC. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalogue of available implementations or their features. Readers are advised to note that other implementations may exist. According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as Evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". 9.1. Veraison * Organization responsible for the implementation: Veraison Project, Linux Foundation * Implementation's web page: https://github.com/veraison/corim/ README.md (https://github.com/veraison/corim/blob/main/README.md) * Brief general description: There are three CoRIM libraries under project Veraison. 1. CoRIM golang library (https://github.com/veraison/corim) The corim/corim and corim/comid packages provide a golang API for low-level manipulation of Concise Reference Integrity Manifest (CoRIM) and Concise Module Identifier (CoMID) tags respectively. 2. CoRIM rust library (https://github.com/veraison/corim-rs) provide a rust implementation of CoRIM specification. 3. CoRIM Processor (https://github.com/veraison/cover) provides a library for appraisal of Evidence by processing CoRIMs as outlined in Section 8.3 of this specification. Birkholz, et al. Expires 5 May 2027 [Page 126] Internet-Draft CoRIM November 2026 In addition to the base CoRIM Libraries, the cocli package (https://github.com/veraison/cocli) uses the golang API above (as well as the API from the veraison/swid package) to provide a user command line interface for working with CoRIM, CoMID and CoSWID. Specifically, it allows creating, signing, verifying, displaying, uploading, and more. See https://github.com/veraison/cocli/ README.md (https://github.com/veraison/cocli/README.md) for further details. * Implementation's level of maturity: alpha. * Coverage: the whole protocol is implemented, including PSA- specific extensions [I-D.fdb-rats-psa-endorsements]. * Version compatibility: Version -06 of the draft * Licensing: Apache 2.0 https://github.com/veraison/corim/blob/main/ LICENSE (https://github.com/veraison/corim/blob/main/LICENSE) * Implementation experience: n/a * Contact information: https://veraison.zulipchat.com (https://veraison.zulipchat.com) * Last updated: https://github.com/veraison/corim/commits/main (https://github.com/veraison/corim/commits/main) https://github.com/veraison/corim-rs/commits/master/ (https://github.com/veraison/corim-rs/commits/master/) https://github.com/veraison/cover/commits/main/ (https://github.com/veraison/cover/commits/main/) 10. Security and Privacy Considerations Evidence appraisal is at the core of any RATS protocol flow, mediating all interactions between Attesters and their Relying Parties. The Verifier is effectively part of the Attesters' and Relying Parties' trusted computing base (TCB). Any mistake in the appraisal procedure conducted by the Verifier could have security implications. For instance, it could lead to the subversion of an access control function, which creates a chance for privilege escalation. Therefore, the Verifier's code and configuration, especially those of the CoRIM processor, are primary security assets that must be built and maintained as securely as possible. Birkholz, et al. Expires 5 May 2027 [Page 127] Internet-Draft CoRIM November 2026 The protection of the Verifier system should be considered throughout its entire lifecycle, from design to operation. This includes the following aspects: * Minimizing implementation complexity (see also Section 6.1 of [I-D.ietf-rats-endorsements]); * Using memory-safe programming languages; * Using secure defaults; * Minimizing the attack surface by avoiding unnecessary features that could be exploited by attackers; * Applying the principle of least privilege to the system's users; * Minimizing the potential impact of security breaches by implementing separation of duties in both the software and operational architecture; * Conducting regular, automated audits and reviews of the system, such as ensuring that users' privileges are correctly configured and that any new code has been audited and approved by independent parties; * Failing securely in the event of errors to avoid compromising the security of the system. It is critical that appraisal procedures are auditable and reproducible. The integrity of code and data during execution is an explicit objective, for example, ensuring that the appraisal functions are executed in an attestable trusted execution environment (TEE). Please review the Security and Privacy Considerations in Sections 8 and 9 of [I-D.ietf-rats-endorsements]; these considerations apply to this document as well. 11. IANA Considerations 11.1. New COSE Header Parameters 11.2. New CBOR Tags IANA is requested to allocate the following tags in the "CBOR Tags" registry [IANA.cbor-tags], preferably with the specific CBOR tag value requested: Birkholz, et al. Expires 5 May 2027 [Page 128] Internet-Draft CoRIM November 2026 +=========+=============+===============================+===========+ | Tag | Data Item | Semantics | Reference | +=========+=============+===============================+===========+ | 500 | tag | Reserved for backward | RFCthis | | | | compatibility | | +---------+-------------+-------------------------------+-----------+ | 501 | map | A tagged-unsigned-corim- | RFCthis | | | | map, see Section 4.1 | | +---------+-------------+-------------------------------+-----------+ | 502-504 | any | Earmarked for CoRIM | RFCthis | +---------+-------------+-------------------------------+-----------+ | 505 | bytes | A tagged-concise-swid-tag, | RFCthis | | | | see Section 4.1.2 | | +---------+-------------+-------------------------------+-----------+ | 506 | bytes | A tagged-concise-mid-tag, | RFCthis | | | | see Section 4.1.2 | | +---------+-------------+-------------------------------+-----------+ | 507 | any | Earmarked for CoRIM | RFCthis | +---------+-------------+-------------------------------+-----------+ | 508 | bytes | A tagged-concise-tl-tag, | RFCthis | | | | see Section 4.1.2 | | +---------+-------------+-------------------------------+-----------+ | 509-549 | any | Earmarked for CoRIM | RFCthis | +---------+-------------+-------------------------------+-----------+ | 550 | bytes .size | tagged-ueid-type, see | RFCthis | | | (7..33) | Section 7.5 | | +---------+-------------+-------------------------------+-----------+ | 551 | any | Earmarked for CoRIM | RFCthis | +---------+-------------+-------------------------------+-----------+ | 552 | uint | tagged-svn, see | RFCthis | | | | Section 5.1.4.5.4 | | +---------+-------------+-------------------------------+-----------+ | 553 | uint | tagged-min-svn, see | RFCthis | | | | Section 5.1.4.5.4 | | +---------+-------------+-------------------------------+-----------+ | 554 | text | tagged-pkix-base64-key- | RFCthis | | | | type, see Section 5.1.4.6 | | +---------+-------------+-------------------------------+-----------+ | 555 | text | tagged-pkix-base64-cert- | RFCthis | | | | type, see Section 5.1.4.6 | | +---------+-------------+-------------------------------+-----------+ | 556 | text | tagged-pkix-base64-cert- | RFCthis | | | | path-type, see | | | | | Section 5.1.4.6 | | +---------+-------------+-------------------------------+-----------+ | 557 | [int/text, | tagged-key-thumbprint-type, | RFCthis | | | bytes] | see Section 7.7 | | +---------+-------------+-------------------------------+-----------+ Birkholz, et al. Expires 5 May 2027 [Page 129] Internet-Draft CoRIM November 2026 | 558 | COSE_Key | tagged-cose-key-type, see | RFCthis | | | | Section 5.1.4.6 | | +---------+-------------+-------------------------------+-----------+ | 559 | digest | tagged-cert-thumbprint- | RFCthis | | | | type, see Section 5.1.4.6 | | +---------+-------------+-------------------------------+-----------+ | 560 | bytes | tagged-bytes, see | RFCthis | | | | Section 7.8 | | +---------+-------------+-------------------------------+-----------+ | 561 | digest | tagged-cert-path- | RFCthis | | | | thumbprint-type, see | | | | | Section 5.1.4.6 | | +---------+-------------+-------------------------------+-----------+ | 562 | bytes | tagged-pkix-asn1der-cert- | RFCthis | | | | type, see Section 5.1.4.6 | | +---------+-------------+-------------------------------+-----------+ | 563 | tagged- | tagged-masked-raw-value, | RFCthis | | | masked-raw- | see Section 5.1.4.5.6 | | | | value | | | +---------+-------------+-------------------------------+-----------+ | 564 | array | tagged-int-range, see | RFCthis | | | | Section 5.1.4.8 | | +---------+-------------+-------------------------------+-----------+ | 565 | array | tagged-{integer,float}- | RFCthis | | | | range, see Section 5.1.4.9 | | +---------+-------------+-------------------------------+-----------+ | 566 | array | tagged- | RFCthis | | | | {integer,float,text,bytes}- | | | | | set, see Section 5.1.4.9 | | +---------+-------------+-------------------------------+-----------+ | 567-599 | any | Earmarked for CoRIM | RFCthis | +---------+-------------+-------------------------------+-----------+ Table 4 Tags designated as "Earmarked for CoRIM" can be reassigned by IANA based on advice from the designated expert for the CBOR Tags registry. 11.3. CoRIM Map Registry This document defines a new registry titled "CoRIM Map". The registry uses integer values as index values for items in corim-map CBOR maps. Future registrations for this registry are to be made based on [RFC8126] as follows: Birkholz, et al. Expires 5 May 2027 [Page 130] Internet-Draft CoRIM November 2026 +=========+=========================+ | Range | Registration Procedures | +=========+=========================+ | 0-127 | Standards Action | +---------+-------------------------+ | 128-255 | Specification Required | +---------+-------------------------+ Table 5: CoRIM Map Items Registration Procedures All negative values are reserved for Private Use. Initial registrations for the "CoRIM Map" registry are provided below. Assignments consist of an integer index value, the item name, and a reference to the defining specification. +=======+================+===============+ | Index | Item Name | Specification | +=======+================+===============+ | 0 | id | RFCthis | +-------+----------------+---------------+ | 1 | tags | RFCthis | +-------+----------------+---------------+ | 2 | dependent-rims | RFCthis | +-------+----------------+---------------+ | 3 | profile | RFCthis | +-------+----------------+---------------+ | 4 | rim-validity | RFCthis | +-------+----------------+---------------+ | 5 | entities | RFCthis | +-------+----------------+---------------+ | 6-255 | Unassigned | | +-------+----------------+---------------+ Table 6: CoRIM Map Items Initial Registrations 11.4. CoRIM Entity Map Registry This document defines a new registry titled "CoRIM Entity Map". The registry uses integer values as index values for items in corim- entity-map CBOR maps. Future registrations for this registry are to be made based on [RFC8126] as follows: Birkholz, et al. Expires 5 May 2027 [Page 131] Internet-Draft CoRIM November 2026 +=========+=========================+ | Range | Registration Procedures | +=========+=========================+ | 0-127 | Standards Action | +---------+-------------------------+ | 128-255 | Specification Required | +---------+-------------------------+ Table 7: CoRIM Entity Map Items Registration Procedures All negative values are reserved for Private Use. Initial registrations for the "CoRIM Entity Map" registry are provided below. Assignments consist of an integer index value, the item name, and a reference to the defining specification. +=====+===========+==================+=============+===============+ |Index|Item Name | Value Type |Description | Specification | +=====+===========+==================+=============+===============+ |0 |entity-name| text |Name of the | RFCthis | | | | |entity | | | | | |responsible | | | | | |for the | | | | | |actions of | | | | | |the role. | | +-----+-----------+------------------+-------------+---------------+ |1 |reg-id | uri |A URI | RFCthis | | | | |associated | | | | | |with the | | | | | |organization | | | | | |that owns the| | | | | |entity name. | | +-----+-----------+------------------+-------------+---------------+ |2 |role | [ + role-type- |A type choice| RFCthis | | | | choice ] |defining the | | | | | |roles that | | | | | |the entity is| | | | | |claiming. | | +-----+-----------+------------------+-------------+---------------+ |3-255|Unassigned | | | | +-----+-----------+------------------+-------------+---------------+ Table 8: CoRIM Entity Map Items Initial Registrations Birkholz, et al. Expires 5 May 2027 [Page 132] Internet-Draft CoRIM November 2026 11.5. CoRIM Signer Map Registry This document defines a new registry titled "CoRIM Signer Map". The registry uses integer values as index values for items in corim- signer-map CBOR maps. Future registrations for this registry are to be made based on [RFC8126] as follows: +=========+=========================+ | Range | Registration Procedures | +=========+=========================+ | 0-127 | Standards Action | +---------+-------------------------+ | 128-255 | Specification Required | +---------+-------------------------+ Table 9: CoRIM Signer Map Items Registration Procedures All negative values are reserved for Private Use. Initial registrations for the "CoRIM Signer Map" registry are provided below. Assignments consist of an integer index value, the item name, and a reference to the defining specification. +=======+=============+===============+ | Index | Item Name | Specification | +=======+=============+===============+ | 0 | signer-name | RFCthis | +-------+-------------+---------------+ | 1 | signer-uri | RFCthis | +-------+-------------+---------------+ | 2-255 | Unassigned | | +-------+-------------+---------------+ Table 10: CoRIM Signer Map Items Initial Registrations 11.6. CoMID Map Registry This document defines a new registry titled "CoMID Map". The registry uses integer values as index values for items in concise- mid-tag CBOR maps. Future registrations for this registry are to be made based on [RFC8126] as follows: Birkholz, et al. Expires 5 May 2027 [Page 133] Internet-Draft CoRIM November 2026 +=========+=========================+ | Range | Registration Procedures | +=========+=========================+ | 0-127 | Standards Action | +---------+-------------------------+ | 128-255 | Specification Required | +---------+-------------------------+ Table 11: CoMID Map Items Registration Procedures All negative values are reserved for Private Use. Initial registrations for the "CoMID Map" registry are provided below. Assignments consist of an integer index value, the item name, and a reference to the defining specification. +=======+==============+===============+ | Index | Item Name | Specification | +=======+==============+===============+ | 0 | language | RFCthis | +-------+--------------+---------------+ | 1 | tag-identity | RFCthis | +-------+--------------+---------------+ | 2 | entities | RFCthis | +-------+--------------+---------------+ | 3 | linked-tags | RFCthis | +-------+--------------+---------------+ | 4 | triples | RFCthis | +-------+--------------+---------------+ | 5-255 | Unassigned | | +-------+--------------+---------------+ Table 12: CoMID Map Items Initial Registrations 11.7. CoMID Entity Map Registry This document defines a new registry titled "CoMID Entity Map". The registry uses integer values as index values for items in comid- entity-map CBOR maps. Future registrations for this registry are to be made based on [RFC8126] as follows: Birkholz, et al. Expires 5 May 2027 [Page 134] Internet-Draft CoRIM November 2026 +=========+=========================+ | Range | Registration Procedures | +=========+=========================+ | 0-127 | Standards Action | +---------+-------------------------+ | 128-255 | Specification Required | +---------+-------------------------+ Table 13: CoMID Entity Map Items Registration Procedures All negative values are reserved for Private Use. Initial registrations for the "CoMID Entity Map" registry are provided below. Assignments consist of an integer index value, the item name, and a reference to the defining specification. +=====+===========+==================+=============+===============+ |Index|Item Name | Value Type |Description | Specification | +=====+===========+==================+=============+===============+ |0 |entity-name| text |Name of the | RFCthis | | | | |entity | | | | | |responsible | | | | | |for the | | | | | |actions of | | | | | |the role. | | +-----+-----------+------------------+-------------+---------------+ |1 |reg-id | uri |A URI | RFCthis | | | | |associated | | | | | |with the | | | | | |organization | | | | | |that owns the| | | | | |entity name. | | +-----+-----------+------------------+-------------+---------------+ |2 |role | [ + role-type- |A type choice| RFCthis | | | | choice ] |defining the | | | | | |roles that | | | | | |the entity is| | | | | |claiming. | | +-----+-----------+------------------+-------------+---------------+ |3-255|Unassigned | | | | +-----+-----------+------------------+-------------+---------------+ Table 14: CoMID Entity Map Items Initial Registrations Birkholz, et al. Expires 5 May 2027 [Page 135] Internet-Draft CoRIM November 2026 11.8. CoMID Triples Map Registry This document defines a new registry titled "CoMID Triples Map". The registry uses integer values as index values for items in the triples-map CBOR maps in concise-mid-tag codepoint 4. Future registrations for this registry are to be made based on [RFC8126] as follows: +============================+=========================+ | Range | Registration Procedures | +============================+=========================+ | 0-1023 | Standards Action | +----------------------------+-------------------------+ | 1024-65535 | Specification Required | +----------------------------+-------------------------+ | 65536-18446744073709551616 | First come first served | +----------------------------+-------------------------+ Table 15: CoMID Triples Map Items Registration Procedures All negative values are reserved for Private Use. Initial registrations for the "CoMID Triples Map" registry are provided below. Assignments consist of an integer index value, the item name, and a reference to the defining specification. Birkholz, et al. Expires 5 May 2027 [Page 136] Internet-Draft CoRIM November 2026 +=========================+================+===============+ | Index | Item Name | Specification | +=========================+================+===============+ | 0 | reference- | RFCthis | | | triples | | +-------------------------+----------------+---------------+ | 1 | endorsed- | RFCthis | | | triples | | +-------------------------+----------------+---------------+ | 2 | identity- | RFCthis | | | triples | | +-------------------------+----------------+---------------+ | 3 | attest-key- | RFCthis | | | triples | | +-------------------------+----------------+---------------+ | 4 | dependency- | RFCthis | | | triples | | +-------------------------+----------------+---------------+ | 5 | membership- | RFCthis | | | triples | | +-------------------------+----------------+---------------+ | 6 | coswid-triples | RFCthis | +-------------------------+----------------+---------------+ | 7 | (reserved) | RFCthis | +-------------------------+----------------+---------------+ | 8 | conditional- | RFCthis | | | endorsement- | | | | series-triples | | +-------------------------+----------------+---------------+ | 9 | (reserved) | RFCthis | +-------------------------+----------------+---------------+ | 10 | conditional- | RFCthis | | | endorsement- | | | | triples | | +-------------------------+----------------+---------------+ | 11-18446744073709551616 | Unassigned | | +-------------------------+----------------+---------------+ Table 16: CoMID Triples Map Items Initial Registrations 11.9. CoMID Measurement Values Map Registry This document defines a new registry titled "CoMID Measurement Values Map". The registry uses integer values as index values for items in measurement-values-map. Future registrations for this registry are to be made based on [RFC8126] as follows: Birkholz, et al. Expires 5 May 2027 [Page 137] Internet-Draft CoRIM November 2026 +============================+=========================+ | Range | Registration Procedures | +============================+=========================+ | 0-1023 | Standards Action | +----------------------------+-------------------------+ | 1024-65535 | Specification Required | +----------------------------+-------------------------+ | 65536-18446744073709551616 | First come first served | +----------------------------+-------------------------+ Table 17: CoMID Measurement Values Map Items Registration Procedures All negative values are reserved for Private Use. Initial registrations for the "CoMID Measurement Values Map" registry are provided below. Assignments consist of an integer index value, the item name, and a reference to the defining specification. +=======================+===========================+=============+ |Index | Item Name |Specification| +=======================+===========================+=============+ |0 | version |RFCthis | +-----------------------+---------------------------+-------------+ |1 | svn |RFCthis | +-----------------------+---------------------------+-------------+ |2 | digests |RFCthis | +-----------------------+---------------------------+-------------+ |3 | flags |RFCthis | +-----------------------+---------------------------+-------------+ |4 | raw-value |RFCthis | +-----------------------+---------------------------+-------------+ |5 | raw-value-mask-DEPRECATED |RFCthis | +-----------------------+---------------------------+-------------+ |6 | mac-addr |RFCthis | +-----------------------+---------------------------+-------------+ |7 | ip-addr |RFCthis | +-----------------------+---------------------------+-------------+ |8 | serial-number |RFCthis | +-----------------------+---------------------------+-------------+ |9 | ueid |RFCthis | +-----------------------+---------------------------+-------------+ |10 | uuid |RFCthis | +-----------------------+---------------------------+-------------+ |11 | name |RFCthis | +-----------------------+---------------------------+-------------+ |12 | (reserved) |RFCthis | +-----------------------+---------------------------+-------------+ Birkholz, et al. Expires 5 May 2027 [Page 138] Internet-Draft CoRIM November 2026 |13 | cryptokeys |RFCthis | +-----------------------+---------------------------+-------------+ |14 | integrity-registers |RFCthis | +-----------------------+---------------------------+-------------+ |15 | int-range |RFCthis | +-----------------------+---------------------------+-------------+ |16 | bool |RFCthis | +-----------------------+---------------------------+-------------+ |17 | integer |RFCthis | +-----------------------+---------------------------+-------------+ |18 | text |RFCthis | +-----------------------+---------------------------+-------------+ |19 | bytes |RFCthis | +-----------------------+---------------------------+-------------+ |20 | float |RFCthis | +-----------------------+---------------------------+-------------+ |21-18446744073709551616| Unassigned | | +-----------------------+---------------------------+-------------+ Table 18: Measurement Values Map Items Initial Registrations 11.10. CoMID Flags Map Registry This document defines a new registry titled "CoMID Flags Map". The registry uses integer values as index values for items in measurement-values-map codepoint 3. Future registrations for this registry are to be made based on [RFC8126] as follows: +============================+=========================+ | Range | Registration Procedures | +============================+=========================+ | 0-1023 | Standards Action | +----------------------------+-------------------------+ | 1024-65535 | Specification Required | +----------------------------+-------------------------+ | 65536-18446744073709551616 | First come first served | +----------------------------+-------------------------+ Table 19: CoMID Flags Map Items Registration Procedures All negative values are reserved for Private Use. Initial registrations for the "CoMID Flags Map" registry are provided below. Assignments consist of an integer index value, the item name, and a reference to the defining specification. Birkholz, et al. Expires 5 May 2027 [Page 139] Internet-Draft CoRIM November 2026 +=======================+============================+=============+ |Index |Item Name |Specification| +=======================+============================+=============+ |0 |is-configured |RFCthis | +-----------------------+----------------------------+-------------+ |1 |is-secure |RFCthis | +-----------------------+----------------------------+-------------+ |2 |is-recovery |RFCthis | +-----------------------+----------------------------+-------------+ |3 |is-debug |RFCthis | +-----------------------+----------------------------+-------------+ |4 |is-replay-protected |RFCthis | +-----------------------+----------------------------+-------------+ |5 |is-integrity-protected |RFCthis | +-----------------------+----------------------------+-------------+ |6 |is-runtime-meas |RFCthis | +-----------------------+----------------------------+-------------+ |7 |is-immutable |RFCthis | +-----------------------+----------------------------+-------------+ |8 |is-tcb |RFCthis | +-----------------------+----------------------------+-------------+ |9 |is-confidentiality-protected|RFCthis | +-----------------------+----------------------------+-------------+ |10 |is-runtime-updatable |RFCthis | +-----------------------+----------------------------+-------------+ |11-18446744073709551616|Unassigned | | +-----------------------+----------------------------+-------------+ Table 20: Flags Map Items Initial Registrations 11.11. CoTL Map Registry This document defines a new registry titled "CoTL Map". The registry uses integer values as index values for items in 'concise-tl-tag' CBOR maps. Future registrations for this registry are to be made based on [RFC8126] as follows: Birkholz, et al. Expires 5 May 2027 [Page 140] Internet-Draft CoRIM November 2026 +=========+=========================+ | Range | Registration Procedures | +=========+=========================+ | 0-127 | Standards Action | +---------+-------------------------+ | 128-255 | Specification Required | +---------+-------------------------+ Table 21: CoTL Map Items Registration Procedures All negative values are reserved for Private Use. Initial registrations for the "CoTL Map" registry are provided below. Assignments consist of an integer index value, the item name, and a reference to the defining specification. +=======+==============+===============+ | Index | Item Name | Specification | +=======+==============+===============+ | 0 | tag-identity | RFCthis | +-------+--------------+---------------+ | 1 | tags-list | RFCthis | +-------+--------------+---------------+ | 2 | tl-validity | RFCthis | +-------+--------------+---------------+ | 3-255 | Unassigned | | +-------+--------------+---------------+ Table 22: CoTL Map Items Initial Registrations 11.12. New Media Types IANA is requested to add the following media types to the "Media Types" registry [IANA.media-types]. +==========+======================+============================+ | Name | Template | Reference | +==========+======================+============================+ | rim+cbor | application/rim+cbor | RFCthis, (Section 11.12.1) | +----------+----------------------+----------------------------+ | rim+cose | application/rim+cose | RFCthis, (Section 11.12.2) | +----------+----------------------+----------------------------+ Table 23: New Media Types Birkholz, et al. Expires 5 May 2027 [Page 141] Internet-Draft CoRIM November 2026 11.12.1. rim+cbor Type name: application Subtype name: rim+cbor Required parameters: n/a Optional parameters: "profile" (CoRIM profile in string format. OIDs MUST use the dotted-decimal notation.) Encoding considerations: binary Security considerations: Section 10 of RFCthis Interoperability considerations: n/a Published specification: RFCthis Applications that use this media type: Attestation Verifiers, Endorsers and Reference-Value providers that need to transfer unprotected CoRIM payloads over HTTP(S), CoAP(S), and other transports. Fragment identifier considerations: n/a Magic number(s): D9 01 F5 File extension(s): .corim Macintosh file type code(s): n/a Person and email address to contact for further information: RATS WG mailing list (rats@ietf.org) Intended usage: COMMON Restrictions on usage: none Author/Change controller: IETF Provisional registration? no 11.12.2. rim+cose Type name: application Subtype name: rim+cose Required parameters: n/a (cose-type is explicitly not supported, as it is understood to be "cose-sign1") Optional parameters: "profile" (CoRIM profile in string format. OIDs MUST use the dotted-decimal notation.) Encoding considerations: binary Security considerations: Section 10 of RFCthis Interoperability considerations: n/a Published specification: RFCthis Applications that use this media type: Attestation Verifiers, Endorsers and Reference-Value providers that need to transfer CoRIM payloads protected using COSE Sign1 over HTTP(S), CoAP(S), and other transports. Fragment identifier considerations: n/a Magic number(s): D2 84 File extension(s): .corim Macintosh file type code(s): n/a Person and email address to contact for further information: RATS WG mailing list (rats@ietf.org) Birkholz, et al. Expires 5 May 2027 [Page 142] Internet-Draft CoRIM November 2026 Intended usage: COMMON Restrictions on usage: none Author/Change controller: IETF Provisional registration? no 11.13. CoAP Content-Formats Registration IANA is requested to register the two following Content-Format numbers in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry [IANA.core-parameters]: +======================+================+======+===========+ | Content-Type | Content Coding | ID | Reference | +======================+================+======+===========+ | application/rim+cbor | - | TBD1 | RFCthis | +----------------------+----------------+------+-----------+ | application/rim+cose | - | TBD2 | RFCthis | +----------------------+----------------+------+-----------+ Table 24: New Content-Formats 11.14. New Software ID Version Scheme Value IANA is requested to register the following Version Scheme Name in the "Software ID Version Scheme Values" registry within the "Software ID Values" [IANA.software-id] registry group. +=======+=====================+==============================+ | Index | Version Scheme Name | Reference | +=======+=====================+==============================+ | 5 | binary | Section 5.1.4.5.3 of RFCthis | +-------+---------------------+------------------------------+ Table 25 12. References 12.1. Normative References [I-D.ietf-rats-eat-measured-component] Frost, S., Fossati, T., Tschofenig, H., and H. Birkholz, "Entity Attestation Token (EAT) Measured Component", Work in Progress, Internet-Draft, draft-ietf-rats-eat-measured- component-12, 20 February 2026, . Birkholz, et al. Expires 5 May 2027 [Page 143] Internet-Draft CoRIM November 2026 [I-D.ietf-rats-msg-wrap] Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-23, 11 December 2025, . [IANA.cbor-tags] IANA, "Concise Binary Object Representation (CBOR) Tags", . [IANA.core-parameters] IANA, "Constrained RESTful Environments (CoRE) Parameters", . [IANA.language-subtag-registry] IANA, "Language Subtag Registry", . [IANA.media-types] IANA, "Media Types", . [IANA.software-id] IANA, "Software ID Values", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, April 2015, . Birkholz, et al. Expires 5 May 2027 [Page 144] Internet-Draft CoRIM November 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC9090] Bormann, C., "Concise Binary Object Representation (CBOR) Tags for Object Identifiers", RFC 9090, DOI 10.17487/RFC9090, July 2021, . [RFC9164] Richardson, M. and C. Bormann, "Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes", RFC 9164, DOI 10.17487/RFC9164, December 2021, . [RFC9393] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Waltermire, "Concise Software Identification Tags", RFC 9393, DOI 10.17487/RFC9393, June 2023, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, . [RFC9597] Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . [RFC9995] Steele, O., Lasker, S., and H. Birkholz, "CBOR Object Signing and Encryption (COSE) Hash Envelope", RFC 9995, DOI 10.17487/RFC9995, July 2026, . Birkholz, et al. Expires 5 May 2027 [Page 145] Internet-Draft CoRIM November 2026 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [STD94] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [X.690] International Telephone and Telegraph Consultative Committee, "ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002. 12.2. Informative References [DICE.cert] Trusted Computing Group, "DICE Certificate Profiles", Version 1.1 , April 2025, . [DICE.endorsement] Trusted Computing Group, "DICE Endorsement Architecture for Devices", Version 1.0, Revision 0.38 , November 2022, . [DICE.Layer] Trusted Computing Group, "DICE Layering Architecture", Version 1.0, Revision 0.19 , July 2020, . [I-D.fdb-rats-psa-endorsements] Fossati, T., Deshpande, Y., and H. Birkholz, "A CoRIM Profile for Arm's Platform Security Architecture (PSA) Endorsements", Work in Progress, Internet-Draft, draft- fdb-rats-psa-endorsements-10, 29 June 2026, . Birkholz, et al. Expires 5 May 2027 [Page 146] Internet-Draft CoRIM November 2026 [I-D.ietf-rats-concise-ta-stores] Wallace, C., Housley, R., Fossati, T., and Y. Deshpande, "Concise TA Stores (CoTS)", Work in Progress, Internet- Draft, draft-ietf-rats-concise-ta-stores-03, 27 July 2026, . [I-D.ietf-rats-endorsements] Thaler, D., Birkholz, H., and T. Fossati, "Remote Attestation Procedures (RATS) Endorsements", Work in Progress, Internet-Draft, draft-ietf-rats-endorsements-13, 14 October 2026, . [I-D.ietf-rats-evidence-trans] Damato, F., Draper, A., and N. Smith, "Evidence Transformations", Work in Progress, Internet-Draft, draft- ietf-rats-evidence-trans-03, 30 October 2026, . [I-D.ydb-rats-cca-endorsements] Deshpande, Y. and T. Fossati, "A CoRIM Profile for Arm's Confidential Computing Architecture (CCA) Endorsements", Work in Progress, Internet-Draft, draft-ydb-rats-cca- endorsements-04, 26 June 2026, . [IANA.coswid] IANA, "Concise Software Identifier (CoSWID)", . [IEEE-802.OandA] "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE, DOI 10.1109/ieeestd.2014.6847097, ISBN ["9780738192192"], July 2014, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . Birkholz, et al. Expires 5 May 2027 [Page 147] Internet-Draft CoRIM November 2026 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 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, . [RFC9783] Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T. Fossati, "Arm's Platform Security Architecture (PSA) Attestation Token", RFC 9783, DOI 10.17487/RFC9783, June 2025, . [SPDM] Distributed Management Task Force, "Security Protocol and Data Model (SPDM) Specification", Version 1.4.1 , July 2026, . [TNC.Arch] Trusted Computing Group, "TCG Trusted Network Connect TNC Architecture for Interoperability", Specification Version 1.1 Revision 2 , May 2006, . [TPM2.Part1] Trusted Computing Group, "Trusted Platform Module Library, Part 1: Architecture", Family "2.0", Level 00, Revision 01.83 , January 2024, . [W3C.rdf11-primer] "RDF 1.1 Primer", W3C NOTE rdf11-primer, W3C rdf11-primer, . Appendix A. Base CoRIM CDDL =============== NOTE: '\' line wrapping per RFC 8792 ================ corim = concise-rim-type-choice concise-rim-type-choice /= tagged-unsigned-corim-map / signed-corim concise-tl-tag = { &(tag-identity: 0) => tag-identity-map, &(tags-list: 1) => [+ tag-identity-map], &(tl-validity: 2) => validity-map, } $concise-tag-type-choice /= tagged-concise-swid-tag / tagged-concise\ Birkholz, et al. Expires 5 May 2027 [Page 148] Internet-Draft CoRIM November 2026 -mid-tag / tagged-concise-tl-tag corim-entity-map = entity-map<$corim-role-type-choice, $$corim-\ entity-map-extension> $corim-id-type-choice /= tstr / uuid-type corim-locator-map = { &(href: 0) => uri / [+ uri], ? &(thumbprint: 1) => eatmc.digest / [+ eatmc.digest], } corim-map = { &(id: 0) => $corim-id-type-choice, &(tags: 1) => [+ $concise-tag-type-choice], ? &(dependent-rims: 2) => [+ corim-locator-map], ? &(profile: 3) => $profile-type-choice, ? &(rim-validity: 4) => validity-map, ? &(entities: 5) => [+ corim-entity-map], * $$corim-map-extension, } unsigned-corim-map = corim-map corim-meta-map = { &(signer: 0) => corim-signer-map, ? &(signature-validity: 1) => validity-map, } $corim-role-type-choice /= &(manifest-creator: 1) / &(manifest-\ signer: 2) corim-signer-map = { &(signer-name: 0) => $entity-name-type-choice, ? &(signer-uri: 1) => uri, * $$corim-signer-map-extension, } COSE-Sign1-corim = [ protected: bstr .cbor protected-corim-header-map, unprotected: unprotected-corim-header-map, payload: bstr .cbor tagged-unsigned-corim-map / hash-envelope-\ digest / nil, signature: bstr, ] hash-envelope-digest = bstr COSE-Sign-corim = [ protected: bstr .cbor protected-corim-header-map, unprotected: unprotected-corim-header-map, payload: bstr .cbor tagged-unsigned-corim-map / hash-envelope-\ digest / nil, signature: [+ signature-structure], ] $profile-type-choice /= uri / tagged-oid-type cwt-claims = { &(iss: 1) => tstr, ? &(sub: 2) => tstr, Birkholz, et al. Expires 5 May 2027 [Page 149] Internet-Draft CoRIM November 2026 ? &(exp: 4) => int / float, ? &(nbf: 5) => int / float, * int => any, } protected-corim-header-map = protected-corim-header-map-inline / \ protected-corim-header-map-hash-envelope protected-corim-header-map-inline = { &(alg: 1) => int, &(content-type: 3) => "application/rim+cbor", meta-group, * cose-label => cose-value, } protected-corim-header-map-hash-envelope = { &(alg: 1) => int, &(payload_hash_alg: 258) => int, &(payload_preimage_content_type: 259) => "application/rim+cbor", ? &(payload_location: 260) => tstr, meta-group, * cose-label => cose-value, } meta-group = (( corim-meta-identity, ? cwt-claims-identity, ) // cwt-claims-identity) corim-meta-identity = (&(corim-meta: 8) => bstr .cbor corim-meta-map) cwt-claims-identity = (&(CWT-Claims: 15) => cwt-claims) signed-corim = #6.18(COSE-Sign1-corim) / #6.98(COSE-Sign-corim) tagged-concise-swid-tag = #6.505(bytes .cbor coswid.concise-swid-tag) signature-structure = [ protected: bstr .cbor protected-corim-header-map, unprotected: unprotected-corim-header-map, signature: bstr, ] tagged-concise-mid-tag = #6.506(bytes .cbor concise-mid-tag) tagged-concise-tl-tag = #6.508(bytes .cbor concise-tl-tag) tagged-unsigned-corim-map = #6.501(unsigned-corim-map) unprotected-corim-header-map = {* cose-label => cose-value} validity-map = { ? &(not-before: 0) => time, &(not-after: 1) => time, } concise-mid-tag = { ? &(language: 0) => text, &(tag-identity: 1) => tag-identity-map, ? &(entities: 2) => [+ comid-entity-map], ? &(linked-tags: 3) => [+ linked-tag-map], &(triples: 4) => triples-map, * $$concise-mid-tag-extension, Birkholz, et al. Expires 5 May 2027 [Page 150] Internet-Draft CoRIM November 2026 } attest-key-triple-record = [ environment: environment-map, key-list: [+ $crypto-key-type-choice], ? conditions: non-empty<{ ? &(mkey: 0) => $measured-element-type-choice, ? &(authorized-by: 1) => [+ $crypto-key-type-choice], }>, ] $class-id-type-choice /= tagged-oid-type / tagged-uuid-type / tagged\ -bytes class-map = non-empty<{ ? &(class-id: 0) => $class-id-type-choice, ? &(vendor: 1) => tstr, ? &(model: 2) => tstr, ? &(layer: 3) => uint, ? &(index: 4) => uint, }> comid-entity-map = entity-map<$comid-role-type-choice, $$comid-\ entity-map-extension> $comid-role-type-choice /= &(tag-creator: 0) / &(creator: 1) / &(\ maintainer: 2) conditional-endorsement-series-triple-record = [ common-condition: [ environment: environment-map, claims-list: [* measurement-map], ? authorized-by: [+ $crypto-key-type-choice], ], series: [+ conditional-series-record], ] conditional-series-record = [ condition: [+ measurement-map], addition: [+ measurement-map], ] COSE_Key = { 1 => tstr / int, ? 2 => bstr, ? 3 => tstr / int, ? 4 => [+ tstr / int], ? 5 => bstr, * cose-label => cose-value, } cose-label = int / tstr cose-value = any coswid-triple-record = [ environment-map, [+ coswid.tag-id], ] Birkholz, et al. Expires 5 May 2027 [Page 151] Internet-Draft CoRIM November 2026 $crypto-key-type-choice /= tagged-pkix-base64-key-type / tagged-pkix\ -base64-cert-type / tagged-pkix-base64-cert-path-type / tagged-cose-\ key-type / tagged-pkix-asn1der-cert-type / tagged-key-thumbprint-\ type / tagged-cert-thumbprint-type / tagged-cert-path-thumbprint-\ type / tagged-bytes tagged-pkix-base64-key-type = #6.554(tstr) tagged-pkix-base64-cert-type = #6.555(tstr) tagged-pkix-base64-cert-path-type = #6.556(tstr) tagged-key-thumbprint-type = #6.557(eatmc.digest) tagged-cose-key-type = #6.558(COSE_Key) tagged-cert-thumbprint-type = #6.559(eatmc.digest) tagged-cert-path-thumbprint-type = #6.561(eatmc.digest) tagged-pkix-asn1der-cert-type = #6.562(bstr) trust-dependency-triple-record = [ domain-id: domain-type, trustees: [+ domain-type], ] domain-membership-triple-record = [ domain-id: domain-type, members: [+ domain-type], ] conditional-endorsement-triple-record = [ conditions: [+ stateful-environment-record], endorsements: [+ endorsed-triple-record], ] domain-type = environment-map endorsed-triple-record = [ condition: environment-map, endorsement: [+ measurement-map], ] entity-map = { &(entity-name: 0) => $entity-name-type-choice, ? &(reg-id: 1) => uri, &(role: 2) => [+ role-type-choice], * extension-socket, } $entity-name-type-choice /= text environment-map = non-empty<{ ? &(class: 0) => class-map, ? &(instance: 1) => $instance-id-type-choice, ? &(group: 2) => $group-id-type-choice, }> flags-map = non-empty<{ ? &(is-configured: 0) => bool, ? &(is-secure: 1) => bool, ? &(is-recovery: 2) => bool, ? &(is-debug: 3) => bool, ? &(is-replay-protected: 4) => bool, Birkholz, et al. Expires 5 May 2027 [Page 152] Internet-Draft CoRIM November 2026 ? &(is-integrity-protected: 5) => bool, ? &(is-runtime-meas: 6) => bool, ? &(is-immutable: 7) => bool, ? &(is-tcb: 8) => bool, ? &(is-confidentiality-protected: 9) => bool, ? &(is-runtime-updatable: 10) => bool, * $$flags-map-extension, }> $group-id-type-choice /= tagged-uuid-type / tagged-bytes identity-triple-record = [ environment: environment-map, key-list: [+ $crypto-key-type-choice], ? conditions: non-empty<{ ? &(mkey: 0) => $measured-element-type-choice, ? &(authorized-by: 1) => [+ $crypto-key-type-choice], }>, ] $instance-id-type-choice /= tagged-ueid-type / tagged-uuid-type / \ tagged-bytes / tagged-pkix-base64-key-type / tagged-pkix-base64-cert\ -type / tagged-cose-key-type / tagged-key-thumbprint-type / tagged-\ cert-thumbprint-type / tagged-pkix-asn1der-cert-type ip-addr-type-choice /= cbor-ip.ipv4-address / cbor-ip.ipv6-address int-range-type-choice = int / tagged-int-range int-range = [ min: int / negative-inf, max: int / positive-inf, ] tagged-int-range = #6.564(int-range) positive-inf = null negative-inf = null tagged-integer-set = #6.566([2*int]) tagged-float-set = #6.566([2*float]) tagged-text-set = #6.566([2*text]) tagged-bytes-set = #6.566([2*bytes]) tagged-integer-range = #6.565([ int / null, int / null, ]) tagged-float-range = #6.565([ float / null, float / null, ]) bool-matcher = bool integer-matcher = int / tagged-integer-range / tagged-integer-set float-matcher = float / tagged-float-range / tagged-float-set text-matcher = text / tagged-text-set bytes-matcher = bytes / tagged-bytes-set linked-tag-map = { Birkholz, et al. Expires 5 May 2027 [Page 153] Internet-Draft CoRIM November 2026 &(linked-tag-id: 0) => $tag-id-type-choice, &(tag-rel: 1) => $tag-rel-type-choice, } mac-addr-type-choice = eui48-addr-type / eui64-addr-type eui48-addr-type = bytes .size 6 eui64-addr-type = bytes .size 8 $measured-element-type-choice /= tagged-oid-type / tagged-uuid-type \ / uint / tstr measurement-map = { ? &(mkey: 0) => $measured-element-type-choice, &(mval: 1) => measurement-values-map, ? &(authorized-by: 2) => [+ $crypto-key-type-choice], } measurement-values-map = non-empty<{ ? &(version: 0) => version-map, ? &(svn: 1) => svn-type-choice, ? &(digests: 2) => digests-type, ? &(flags: 3) => flags-map, ? ( &(raw-value: 4) => $raw-value-type-choice, ? &(raw-value-mask-DEPRECATED: 5) => raw-value-\ mask-type, ), ? &(mac-addr: 6) => mac-addr-type-choice, ? &(ip-addr: 7) => ip-addr-type-choice, ? &(serial-number: 8) => text, ? &(ueid: 9) => ueid-type, ? &(uuid: 10) => uuid-type, ? &(name: 11) => text, ? &(cryptokeys: 13) => [+ $crypto-key-type-choice], ? &(integrity-registers: 14) => integrity-registers, ? &(int-range: 15) => int-range-type-choice, ? &(bool: 16) => bool-matcher, ? &(integer: 17) => integer-matcher, ? &(text: 18) => text-matcher, ? &(bytes: 19) => bytes-matcher, ? &(float: 20) => float-matcher, * $$measurement-values-map-extension, }> non-empty = M .and ({+ any => any}) oid-type = bytes tagged-oid-type = #6.111(oid-type) $raw-value-type-choice /= tagged-bytes / tagged-masked-raw-value raw-value-mask-type = bytes tagged-masked-raw-value = #6.563([ value: bytes, mask: bytes, ]) Birkholz, et al. Expires 5 May 2027 [Page 154] Internet-Draft CoRIM November 2026 reference-triple-record = [ ref-env: environment-map, ref-claims: [+ measurement-map], ] stateful-environment-record = [ environment: environment-map, claims-list: [+ measurement-map], ] svn-type = uint svn = svn-type min-svn = svn-type tagged-svn = #6.552(svn) tagged-min-svn = #6.553(min-svn) svn-type-choice = svn / tagged-svn / tagged-min-svn $tag-id-type-choice /= tstr / uuid-type tag-identity-map = { &(tag-id: 0) => $tag-id-type-choice, ? &(tag-version: 1) => tag-version-type, } $tag-rel-type-choice /= &(supplements: 0) / &(replaces: 1) tag-version-type = uint tagged-bytes = #6.560(bytes) triples-map = non-empty<{ ? &(reference-triples: 0) => [+ reference-triple-record], ? &(endorsed-triples: 1) => [+ endorsed-triple-record], ? &(identity-triples: 2) => [+ identity-triple-record], ? &(attest-key-triples: 3) => [+ attest-key-triple-record], ? &(dependency-triples: 4) => [+ trust-dependency-triple-record], ? &(membership-triples: 5) => [+ domain-membership-triple-record\ ], ? &(coswid-triples: 6) => [+ coswid-triple-record], ? &(conditional-endorsement-series-triples: 8) => [+ conditional\ -endorsement-series-triple-record], ? &(conditional-endorsement-triples: 10) => [+ conditional-\ endorsement-triple-record], * $$triples-map-extension, }> ueid-type = bytes .size (7 .. 33) tagged-ueid-type = #6.550(ueid-type) uuid-type = bytes .size 16 tagged-uuid-type = #6.37(uuid-type) version-map = { &(version: 0) => text, ? &(version-scheme: 1) => coswid.$version-scheme, } digests-type = [+ eatmc.digest] integrity-register-id-type-choice = uint / text integrity-registers = {+ integrity-register-id-type-choice => \ Birkholz, et al. Expires 5 May 2027 [Page 155] Internet-Draft CoRIM November 2026 digests-type} $$measurement-values-map-extension //= (&(psa-cert-num: 100) => psa-\ cert-num-type) psa-cert-num-type = text .regexp "[0-9]{13} - [0-9]{5}" eatmc.measured-component = { eatmc.component-id-label => eatmc.component-id, eatmc.measurement, ? eatmc.authorities-label => [+ eatmc.authority-id-type], ? eatmc.flags-label => eatmc.flags-type, } eatmc.measurement //= (eatmc.digested-measurement-label => eatmc.\ digest // eatmc.raw-measurement-label => bytes) eatmc.authority-id-type = eatmc.eat.JC eatmc.flags-type = eatmc.eat.JC eatmc.component-id = [ name: text, ? version: eatmc.version, ] eatmc.version = [ val: text, ? scheme: eatmc.coswid.$version-scheme, ] eatmc.digest = [ alg: int / text, val: eatmc.digest-value-type, ] eatmc.digest-value-type = eatmc.eat.JC eatmc.bytes-b64u = text .b64u bytes eatmc.bytes8 = bytes .size 8 eatmc.bytes8-b64u = text .b64u eatmc.bytes8 eatmc.component-id-label = eatmc.eat.JC<"id", 1> eatmc.digested-measurement-label = eatmc.eat.JC<"digested-\ measurement", 2> eatmc.raw-measurement-label = eatmc.eat.JC<"raw-measurement", 5> eatmc.authorities-label = eatmc.eat.JC<"authorities", 3> eatmc.flags-label = eatmc.eat.JC<"flags", 4> eatmc.mc-cbor = bytes .cbor eatmc.measured-component eatmc.mc-json = text .json eatmc.measured-component eatmc.$measurements-body-cbor /= eatmc.mc-cbor / eatmc.mc-json eatmc.$measurements-body-json /= eatmc.mc-json / text .b64u eatmc.mc\ -cbor eatmc.eat.JSON-ONLY = J .feature "json" eatmc.eat.CBOR-ONLY = C .feature "cbor" eatmc.eat.JC = eatmc.eat.JSON-ONLY / eatmc.eat.CBOR-ONLY eatmc.coswid.$version-scheme /= eatmc.coswid.multipartnumeric / \ eatmc.coswid.multipartnumeric-suffix / eatmc.coswid.alphanumeric / \ eatmc.coswid.decimal / eatmc.coswid.semver / int / text eatmc.coswid.multipartnumeric = 1 Birkholz, et al. Expires 5 May 2027 [Page 156] Internet-Draft CoRIM November 2026 eatmc.coswid.multipartnumeric-suffix = 2 eatmc.coswid.alphanumeric = 3 eatmc.coswid.decimal = 4 eatmc.coswid.semver = 16384 coswid.concise-swid-tag = { coswid.tag-id => text / bstr .size 16, coswid.tag-version => integer, ? coswid.corpus => bool, ? coswid.patch => bool, ? coswid.supplemental => bool, coswid.software-name => text, ? coswid.software-version => text, ? coswid.version-scheme => coswid.$version-scheme, ? coswid.media => text, ? coswid.software-meta => coswid.one-or-more, coswid.entity => coswid.one-or-more, ? coswid.link => coswid.one-or-more, ? coswid.payload-or-evidence, * $$coswid-extension, coswid.global-attributes, } coswid.tag-id = 0 coswid.$version-scheme /= coswid.multipartnumeric / coswid.\ multipartnumeric-suffix / coswid.alphanumeric / coswid.decimal / \ coswid.semver / int / text coswid.one-or-more = T / [2*T] coswid.tag-version = 12 coswid.corpus = 8 coswid.patch = 9 coswid.supplemental = 11 coswid.software-name = 1 coswid.software-version = 13 coswid.version-scheme = 14 coswid.media = 10 coswid.software-meta = 5 coswid.software-meta-entry = { ? coswid.activation-status => text, ? coswid.channel-type => text, ? coswid.colloquial-version => text, ? coswid.description => text, ? coswid.edition => text, ? coswid.entitlement-data-required => bool, ? coswid.entitlement-key => text, ? coswid.generator => text / bstr .size 16, ? coswid.persistent-id => text, ? coswid.product => text, ? coswid.product-family => text, Birkholz, et al. Expires 5 May 2027 [Page 157] Internet-Draft CoRIM November 2026 ? coswid.revision => text, ? coswid.summary => text, ? coswid.unspsc-code => text, ? coswid.unspsc-version => text, * $$software-meta-extension, coswid.global-attributes, } coswid.entity = 2 coswid.entity-entry = { coswid.entity-name => text, ? coswid.reg-id => coswid.any-uri, coswid.role => coswid.one-or-more, ? coswid.thumbprint => coswid.hash-entry, * $$entity-extension, coswid.global-attributes, } coswid.link = 4 coswid.link-entry = { ? coswid.artifact => text, coswid.href => coswid.any-uri, ? coswid.media => text, ? coswid.ownership => coswid.$ownership, coswid.rel => coswid.$rel, ? coswid.media-type => text, ? coswid.use => coswid.$use, * $$link-extension, coswid.global-attributes, } coswid.payload-or-evidence //= (coswid.payload => coswid.payload-\ entry // coswid.evidence => coswid.evidence-entry) coswid.global-attributes = ( ? coswid.lang => text, * coswid.any-attribute, ) coswid.multipartnumeric = 1 coswid.multipartnumeric-suffix = 2 coswid.alphanumeric = 3 coswid.decimal = 4 coswid.semver = 16384 coswid.activation-status = 43 coswid.channel-type = 44 coswid.colloquial-version = 45 coswid.description = 46 coswid.edition = 47 coswid.entitlement-data-required = 48 coswid.entitlement-key = 49 coswid.generator = 50 coswid.persistent-id = 51 Birkholz, et al. Expires 5 May 2027 [Page 158] Internet-Draft CoRIM November 2026 coswid.product = 52 coswid.product-family = 53 coswid.revision = 54 coswid.summary = 55 coswid.unspsc-code = 56 coswid.unspsc-version = 57 coswid.entity-name = 31 coswid.reg-id = 32 coswid.any-uri = uri coswid.role = 33 coswid.$role /= coswid.tag-creator / coswid.software-creator / \ coswid.aggregator / coswid.distributor / coswid.licensor / coswid.\ maintainer / int / text coswid.thumbprint = 34 coswid.hash-entry = [ hash-alg-id: int, hash-value: bytes, ] coswid.artifact = 37 coswid.href = 38 coswid.ownership = 39 coswid.$ownership /= coswid.shared / coswid.private / coswid.\ abandon / int / text coswid.rel = 40 coswid.$rel /= coswid.ancestor / coswid.component / coswid.feature \ / coswid.installationmedia / coswid.packageinstaller / coswid.\ parent / coswid.patches / coswid.requires / coswid.see-also / coswid\ .supersedes / coswid.supplemental / -256 .. 65536 / text coswid.media-type = 41 coswid.use = 42 coswid.$use /= coswid.optional / coswid.required / coswid.\ recommended / int / text coswid.payload = 6 coswid.payload-entry = { coswid.resource-collection, * $$payload-extension, coswid.global-attributes, } coswid.evidence = 3 coswid.evidence-entry = { coswid.resource-collection, ? coswid.date => coswid.integer-time, ? coswid.device-id => text, ? coswid.location => text, * $$evidence-extension, coswid.global-attributes, } coswid.lang = 15 Birkholz, et al. Expires 5 May 2027 [Page 159] Internet-Draft CoRIM November 2026 coswid.any-attribute = (coswid.label => coswid.one-or-more / \ coswid.one-or-more) coswid.tag-creator = 1 coswid.software-creator = 2 coswid.aggregator = 3 coswid.distributor = 4 coswid.licensor = 5 coswid.maintainer = 6 coswid.shared = 3 coswid.private = 2 coswid.abandon = 1 coswid.ancestor = 1 coswid.component = 2 coswid.feature = 3 coswid.installationmedia = 4 coswid.packageinstaller = 5 coswid.parent = 6 coswid.patches = 7 coswid.requires = 8 coswid.see-also = 9 coswid.supersedes = 10 coswid.optional = 1 coswid.required = 2 coswid.recommended = 3 coswid.resource-collection = ( coswid.path-elements-group, ? coswid.process => coswid.one-or-more, ? coswid.resource => coswid.one-or-more, * $$resource-collection-extension, ) coswid.date = 35 coswid.integer-time = #6.1(int) coswid.device-id = 36 coswid.location = 23 coswid.label = text / int coswid.path-elements-group = ( ? coswid.directory => coswid.one-or-more, ? coswid.file => coswid.one-or-more, ) coswid.process = 18 coswid.process-entry = { coswid.process-name => text, ? coswid.pid => integer, * $$process-extension, coswid.global-attributes, } coswid.resource = 19 coswid.resource-entry = { Birkholz, et al. Expires 5 May 2027 [Page 160] Internet-Draft CoRIM November 2026 coswid.type => text, * $$resource-extension, coswid.global-attributes, } coswid.directory = 16 coswid.directory-entry = { coswid.filesystem-item, ? coswid.path-elements => {coswid.path-elements-group}, * $$directory-extension, coswid.global-attributes, } coswid.file = 17 coswid.file-entry = { coswid.filesystem-item, ? coswid.size => uint, ? coswid.file-version => text, ? coswid.hash => coswid.hash-entry, * $$file-extension, coswid.global-attributes, } coswid.process-name = 27 coswid.pid = 28 coswid.type = 29 coswid.filesystem-item = ( ? coswid.key => bool, ? coswid.location => text, coswid.fs-name => text, ? coswid.root => text, ) coswid.path-elements = 26 coswid.size = 20 coswid.file-version = 21 coswid.hash = 7 coswid.key = 22 coswid.fs-name = 24 coswid.root = 25 cbor-ip.ipv4-address = bytes .size 4 cbor-ip.ipv6-address = bytes .size 16 Acknowledgments The authors would like to thank the following people for their review and comments on this document: Greg Kostal, Carl Wallace, Hannes Tschofenig, Jag Raman, Giri Mandyam, Jeremy O'Donoghue, Michael Richardson, Dhawal Kumar, Spencer Gilson, and Sergei Trofimov. Contributors Birkholz, et al. Expires 5 May 2027 [Page 161] Internet-Draft CoRIM November 2026 Carsten Bormann Universität Bremen TZI Email: cabo@tzi.org Carsten Bormann contributed to the CDDL specifications and the IANA considerations. Andrew Draper Altera Email: andrew.draper@altera.com Andrew contributed the concept, description, and semantics of conditional endorsements as well as consistent contribution to weekly reviews of others' edits. Dionna Glaze Google LLC Email: dionnaglaze@google.com Dionna contributed many clarifying questions and disambiguations to the semantics of attestation appraisal as well as consistent contribution to weekly reviews of others' edits. Steven Bellock NVIDIA Email: sbellock@nvidia.com Steven contributed a thorough review of the specification, with many fixes and clarifications to the CDDL, IANA considerations, Reference Verifier pseudocode and normative text. Authors' Addresses Henk Birkholz Fraunhofer SIT Email: henk.birkholz@ietf.contact Thomas Fossati NVIDIA Email: tfossati@nvidia.com Birkholz, et al. Expires 5 May 2027 [Page 162] Internet-Draft CoRIM November 2026 Yogesh Deshpande arm Email: yogesh.deshpande@arm.com Ned Smith Independent Email: ned.smith.ietf@outlook.com Wei Pan Huawei Technologies Email: william.panwei@huawei.com Birkholz, et al. Expires 5 May 2027 [Page 163]