Concise Reference Integrity Manifest
draft-ietf-rats-corim-12
| Document | Type | Active Internet-Draft (rats WG) | |
|---|---|---|---|
| Authors | Henk Birkholz , Thomas Fossati , Yogesh Deshpande , Ned Smith , Wei Pan | ||
| Last updated | 2026-11-01 | ||
| Replaces | draft-birkholz-rats-corim | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews |
ARTART Early review
(of
-09)
by Rich Salz
Ready w/nits
SECDIR Early Review due 2025-11-28
Incomplete
|
||
| Additional resources |
GitHub Repository
Mailing list discussion |
||
| Stream | WG state | In WG Last Call | |
| Associated WG milestone |
|
||
| Document shepherd | Michael Richardson | ||
| Shepherd write-up | Show Last changed 2025-08-16 | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | mcr+ietf@sandelman.ca |
draft-ietf-rats-corim-12
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> = (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<role-type-choice, extension-socket> = {
&(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,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
eat-measured-component-12>.
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, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-msg-wrap-23>.
[IANA.cbor-tags]
IANA, "Concise Binary Object Representation (CBOR) Tags",
<https://www.iana.org/assignments/cbor-tags>.
[IANA.core-parameters]
IANA, "Constrained RESTful Environments (CoRE)
Parameters",
<https://www.iana.org/assignments/core-parameters>.
[IANA.language-subtag-registry]
IANA, "Language Subtag Registry",
<https://www.iana.org/assignments/language-subtag-
registry>.
[IANA.media-types]
IANA, "Media Types",
<https://www.iana.org/assignments/media-types>.
[IANA.software-id]
IANA, "Software ID Values",
<https://www.iana.org/assignments/software-id>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
[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,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
April 2015, <https://www.rfc-editor.org/rfc/rfc7468>.
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, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.
[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, <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC9090] Bormann, C., "Concise Binary Object Representation (CBOR)
Tags for Object Identifiers", RFC 9090,
DOI 10.17487/RFC9090, July 2021,
<https://www.rfc-editor.org/rfc/rfc9090>.
[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,
<https://www.rfc-editor.org/rfc/rfc9164>.
[RFC9393] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
Waltermire, "Concise Software Identification Tags",
RFC 9393, DOI 10.17487/RFC9393, June 2023,
<https://www.rfc-editor.org/rfc/rfc9393>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/rfc/rfc9562>.
[RFC9597] Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in
COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024,
<https://www.rfc-editor.org/rfc/rfc9597>.
[RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/rfc/rfc9711>.
[RFC9995] Steele, O., Lasker, S., and H. Birkholz, "CBOR Object
Signing and Encryption (COSE) Hash Envelope", RFC 9995,
DOI 10.17487/RFC9995, July 2026,
<https://www.rfc-editor.org/rfc/rfc9995>.
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,
<https://www.rfc-editor.org/rfc/rfc3986>.
[STD94] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[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,
<https://trustedcomputinggroup.org/wp-content/uploads/
DICE-Certificate-Profiles-v1.1_pub.pdf>.
[DICE.endorsement]
Trusted Computing Group, "DICE Endorsement Architecture
for Devices", Version 1.0, Revision 0.38 , November 2022,
<https://trustedcomputinggroup.org/wp-content/uploads/TCG-
Endorsement-Architecture-for-Devices-V1-R38_pub.pdf>.
[DICE.Layer]
Trusted Computing Group, "DICE Layering Architecture",
Version 1.0, Revision 0.19 , July 2020,
<https://trustedcomputinggroup.org/wp-content/uploads/
DICE-Layering-Architecture-r19_pub.pdf>.
[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,
<https://datatracker.ietf.org/doc/html/draft-fdb-rats-psa-
endorsements-10>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
concise-ta-stores-03>.
[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, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-endorsements-13>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
evidence-trans-03>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ydb-rats-cca-
endorsements-04>.
[IANA.coswid]
IANA, "Concise Software Identifier (CoSWID)",
<https://www.iana.org/assignments/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, <https://doi.org/10.1109/ieeestd.2014.6847097>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[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,
<https://www.rfc-editor.org/rfc/rfc7942>.
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,
<https://www.rfc-editor.org/rfc/rfc8126>.
[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, <https://www.rfc-editor.org/rfc/rfc9334>.
[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, <https://www.rfc-editor.org/rfc/rfc9783>.
[SPDM] Distributed Management Task Force, "Security Protocol and
Data Model (SPDM) Specification", Version 1.4.1 , July
2026, <https://www.dmtf.org/dsp/DSP0274>.
[TNC.Arch] Trusted Computing Group, "TCG Trusted Network Connect TNC
Architecture for Interoperability", Specification Version
1.1 Revision 2 , May 2006,
<https://trustedcomputinggroup.org/wp-content/uploads/
TNC_Architecture_v1_1_r2.pdf>.
[TPM2.Part1]
Trusted Computing Group, "Trusted Platform Module Library,
Part 1: Architecture", Family "2.0", Level 00, Revision
01.83 , January 2024,
<https://trustedcomputinggroup.org/resource/tpm-library-
specification/>.
[W3C.rdf11-primer]
"RDF 1.1 Primer", W3C NOTE rdf11-primer, W3C rdf11-primer,
<https://www.w3.org/TR/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<role-type-choice, extension-socket> = {
&(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> = 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.bytes-b64u, bytes>
eatmc.flags-type = eatmc.eat.JC<eatmc.bytes8-b64u, eatmc.bytes8>
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, bytes>
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> = J .feature "json"
eatmc.eat.CBOR-ONLY<C> = C .feature "cbor"
eatmc.eat.JC<J, C> = eatmc.eat.JSON-ONLY<J> / eatmc.eat.CBOR-ONLY<C>
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.software-meta-\
entry>,
coswid.entity => coswid.one-or-more<coswid.entity-entry>,
? coswid.link => coswid.one-or-more<coswid.link-entry>,
? 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> = 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.$role>,
? 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<text> / \
coswid.one-or-more<int>)
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.process-entry>,
? coswid.resource => coswid.one-or-more<coswid.resource-entry>,
* $$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.directory-entry>,
? coswid.file => coswid.one-or-more<coswid.file-entry>,
)
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]