Concise Reference Integrity Manifest
draft-ietf-rats-corim-11
| Document | Type | Active Internet-Draft (rats WG) | |
|---|---|---|---|
| Authors | Henk Birkholz , Thomas Fossati , Yogesh Deshpande , Ned Smith , Wei Pan | ||
| Last updated | 2026-07-06 | ||
| 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-11
Remote ATtestation ProcedureS H. Birkholz
Internet-Draft Fraunhofer SIT
Intended status: Standards Track T. Fossati
Expires: 7 January 2027 Linaro
Y. Deshpande
arm
N. Smith
Independent
W. Pan
Huawei Technologies
6 July 2026
Concise Reference Integrity Manifest
draft-ietf-rats-corim-11
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 7 January 2027 [Page 1]
Internet-Draft CoRIM July 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 7 January 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 . . . . . . . . . . . . . . . . . 8
2.1. Interactions with ACS . . . . . . . . . . . . . . . . . . 8
2.2. Consistency of ACS . . . . . . . . . . . . . . . . . . . 9
3. Typographical Conventions for CDDL . . . . . . . . . . . . . 9
4. Concise Reference Integrity Manifest (CoRIM) . . . . . . . . 10
4.1. CoRIM Map . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. CoRIM Identifier . . . . . . . . . . . . . . . . . . 13
4.1.2. Tags . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.3. Locator Map . . . . . . . . . . . . . . . . . . . . . 13
4.1.4. Profile Types . . . . . . . . . . . . . . . . . . . . 14
4.1.5. Entities . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Signed CoRIM . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Protected Header Map . . . . . . . . . . . . . . . . 16
4.2.2. CWT Claims . . . . . . . . . . . . . . . . . . . . . 17
4.2.3. Meta Map . . . . . . . . . . . . . . . . . . . . . . 18
4.2.4. Unprotected CoRIM Header Map . . . . . . . . . . . . 19
4.3. Signer authority of securely conveyed unsigned CoRIM . . 19
4.3.1. CoRIM collections . . . . . . . . . . . . . . . . . . 19
5. Concise Module Identifier (CoMID) . . . . . . . . . . . . . . 22
5.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.1. Tag Identity . . . . . . . . . . . . . . . . . . . . 24
5.1.2. Entities . . . . . . . . . . . . . . . . . . . . . . 25
Birkholz, et al. Expires 7 January 2027 [Page 2]
Internet-Draft CoRIM July 2026
5.1.3. Linked Tag . . . . . . . . . . . . . . . . . . . . . 26
5.1.4. Triples . . . . . . . . . . . . . . . . . . . . . . . 26
5.1.5. Reference Values Triple . . . . . . . . . . . . . . . 40
5.1.6. Endorsed Values Triple . . . . . . . . . . . . . . . 42
5.1.7. Conditional Endorsement Triple . . . . . . . . . . . 42
5.1.8. Conditional Endorsement Series Triple . . . . . . . . 43
5.1.9. Device Identity Triple . . . . . . . . . . . . . . . 45
5.1.10. Attest Key Triple . . . . . . . . . . . . . . . . . . 46
5.1.11. Triples for domain definition . . . . . . . . . . . . 47
5.1.12. CoMID-CoSWID Linking Triple . . . . . . . . . . . . . 50
5.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 50
5.2.1. Map Extensions . . . . . . . . . . . . . . . . . . . 50
5.2.2. Data Type Extensions . . . . . . . . . . . . . . . . 50
6. CoTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 51
7. Common Types . . . . . . . . . . . . . . . . . . . . . . . . 52
7.1. Non-Empty . . . . . . . . . . . . . . . . . . . . . . . . 52
7.2. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.3. Validity . . . . . . . . . . . . . . . . . . . . . . . . 53
7.4. UUID . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.5. UEID . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.6. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.7. Digest . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.8. Tagged Bytes Type . . . . . . . . . . . . . . . . . . . . 54
8. Reference Verifier . . . . . . . . . . . . . . . . . . . . . 55
8.1. Appraisal Logical Phases . . . . . . . . . . . . . . . . 55
8.2. The CoRIM Processor . . . . . . . . . . . . . . . . . . . 56
8.2.1. High-Level View . . . . . . . . . . . . . . . . . . . 56
8.2.2. Data Structures . . . . . . . . . . . . . . . . . . . 58
8.2.3. Input Validation and Transformation (Phase 1) . . . . 71
8.2.4. ACS Augmentation (Phases 2, 3 and 4) . . . . . . . . 82
8.2.5. Handoff . . . . . . . . . . . . . . . . . . . . . . . 96
8.2.6. Example Appraisal . . . . . . . . . . . . . . . . . . 96
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 111
9.1. Veraison . . . . . . . . . . . . . . . . . . . . . . . . 111
10. Security and Privacy Considerations . . . . . . . . . . . . . 112
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 113
11.1. New COSE Header Parameters . . . . . . . . . . . . . . . 113
11.2. New CBOR Tags . . . . . . . . . . . . . . . . . . . . . 113
11.3. CoRIM Map Registry . . . . . . . . . . . . . . . . . . . 115
11.4. CoRIM Entity Map Registry . . . . . . . . . . . . . . . 116
11.5. CoRIM Signer Map Registry . . . . . . . . . . . . . . . 117
11.6. CoMID Map Registry . . . . . . . . . . . . . . . . . . . 118
11.7. CoMID Entity Map Registry . . . . . . . . . . . . . . . 119
11.8. CoMID Triples Map Registry . . . . . . . . . . . . . . . 120
11.9. CoMID Measurement Values Map Registry . . . . . . . . . 122
11.10. CoMID Flags Map Registry . . . . . . . . . . . . . . . . 124
11.11. CoTL Map Registry . . . . . . . . . . . . . . . . . . . 126
Birkholz, et al. Expires 7 January 2027 [Page 3]
Internet-Draft CoRIM July 2026
11.12. New Media Types . . . . . . . . . . . . . . . . . . . . 126
11.12.1. rim+cbor . . . . . . . . . . . . . . . . . . . . . 127
11.12.2. rim+cose . . . . . . . . . . . . . . . . . . . . . 127
11.13. CoAP Content-Formats Registration . . . . . . . . . . . 128
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 128
12.1. Normative References . . . . . . . . . . . . . . . . . . 128
12.2. Informative References . . . . . . . . . . . . . . . . . 131
Appendix A. Base CoRIM CDDL . . . . . . . . . . . . . . . . . . 133
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 146
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 146
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., digest ) 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 Attesters can evolve and therefore new measurement
types need to be expressed, but an Endorser may also want to provide
new security relevant attributes about an Attester at a future point
in time.
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
Birkholz, et al. Expires 7 January 2027 [Page 4]
Internet-Draft CoRIM July 2026
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].
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.
Birkholz, et al. Expires 7 January 2027 [Page 5]
Internet-Draft CoRIM July 2026
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].
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].
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:
A domain is a hierarchical description of a Composite Attester in
terms of its constituent Environments and their compositional
relationships.
Endorsed values:
Birkholz, et al. Expires 7 January 2027 [Page 6]
Internet-Draft CoRIM July 2026
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 that is unique to that 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].
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:
Birkholz, et al. Expires 7 January 2027 [Page 7]
Internet-Draft CoRIM July 2026
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.
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.
Birkholz, et al. Expires 7 January 2027 [Page 8]
Internet-Draft CoRIM July 2026
+================+========+=========================================+
| 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._
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.2 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 follows the naming conventions
illustrated in Table 2.
Birkholz, et al. Expires 7 January 2027 [Page 9]
Internet-Draft CoRIM July 2026
+========================+===============+==========================+
| 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
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 uniquely 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.
Birkholz, et al. Expires 7 January 2027 [Page 10]
Internet-Draft CoRIM July 2026
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 a unique 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.
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.
Birkholz, et al. Expires 7 January 2027 [Page 11]
Internet-Draft CoRIM July 2026
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): A unique identifier to identify 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.
* 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)
Birkholz, et al. Expires 7 January 2027 [Page 12]
Internet-Draft CoRIM July 2026
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
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.
* thumbprint (index 1): expected digest or an array of digests
referenced by href or an array of hrefs. See Section 7.7.
Birkholz, et al. Expires 7 January 2027 [Page 13]
Internet-Draft CoRIM July 2026
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 type defined in
Section 11.12.1 with the profile parameter set to the appropriate
value. Alternatively, it MAY define and register its own media type.
A profile identifier is either an OID [RFC9090] or a URL [STD66].
The profile identifier uniquely 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.
Birkholz, et al. Expires 7 January 2027 [Page 14]
Internet-Draft CoRIM July 2026
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)
Signing a CoRIM follows the procedures defined in CBOR Object Signing
and Encryption [STD96]. A CoRIM tag MUST be wrapped in a COSE_Sign1
structure. The CoRIM MUST be signed by the CoRIM creator.
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.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.
Birkholz, et al. Expires 7 January 2027 [Page 15]
Internet-Draft CoRIM July 2026
* signature: A COSE signature block, as defined in Section 4 of
[STD96].
4.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)
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.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:
Birkholz, et al. Expires 7 January 2027 [Page 16]
Internet-Draft CoRIM July 2026
* 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
([I-D.ietf-cose-hash-envelope]):
* 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.
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.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.
Additional data can be included in the COSE header map as per
(Section 3 of [STD96]).
4.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.3.1.
Birkholz, et al. Expires 7 January 2027 [Page 17]
Internet-Draft CoRIM July 2026
* 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.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.3.1.
* signature-validity (index 1): Validity period for the CoRIM.
Described in Section 7.3.
4.2.3.1. 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.
Birkholz, et al. Expires 7 January 2027 [Page 18]
Internet-Draft CoRIM July 2026
4.2.4. Unprotected CoRIM Header Map
unprotected-corim-header-map = {
* cose-label => cose-value
}
4.3. Signer authority of securely conveyed unsigned CoRIM
An unsigned (#6.501-tagged) CoRIM may be a payload in an enveloping
signed document, [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 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:{{&SELF}}:corim.
Birkholz, et al. Expires 7 January 2027 [Page 19]
Internet-Draft CoRIM July 2026
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. The COSE
protected header can include a Collection CMW type name by using the
cmwc_t content type parameter for the &(content-type: 3) COSE header,
or &(payload_preimage_content_type: 259) in the case of hash
envelopes.
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:{{&SELF}}:corim",
+ cmw-label => [TBD1, bytes .cbor tagged-corim-map]
}
cmw-label = text / int
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 tag:{{&SELF}}: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 have different profiles.
Birkholz, et al. Expires 7 January 2027 [Page 20]
Internet-Draft CoRIM July 2026
=============== NOTE: '\' line wrapping per RFC 8792 ================
/ cbor-collection / {
"__cmwc_t": "tag:{{&SELF}}:corim",
"adee8cd4-4e47-461f-b341-2aba3ae4cbda":
/ cbor-cmw / [TBD1, << / tagged-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: {
/ profile-foo / -404:
h'\
6094685f8bb9b67daaf35707bd2c391f536a1df2ce5152c3cc'
}}]],
/ coswid-triples / 6: [[
{/ class / 0: {/ class-id / 0: 560(h'c0de')}},
[h'369a6688451240b9b74905b1dd5fae9f']]]}}>>)],
/ profile / 3: "tag:example.com,2025/example-profile",
/ dependent-rims / 2: [{
/ href / 0: [
"urn:uuid:51a5f633-71c0-45f5-855e-43e8254c1806",
"https://example.com/369a6688451240b9b74905b1dd5fae9f.\
corim"
]}]}) >>],
"51a5f633-71c0-45f5-855e-43e8254c1806":
/ cbor-cmw / [TBD1, << / tagged-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-bar / 4294967295: {
/ profile-baz / 0: 5,
/ profile-qux / 1: h'f76e41f3462a62e8'}}>>)],
/ profile / 3: "tag:example.com,2025/software-profile"})>>]
}
Birkholz, et al. Expires 7 January 2027 [Page 21]
Internet-Draft CoRIM July 2026
5. Concise Module Identifier (CoMID)
A CoMID tag contains information about hardware, firmware, or module
composition.
Each CoMID has a unique ID that is used to unambiguously 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).
Birkholz, et al. Expires 7 January 2027 [Page 22]
Internet-Draft CoRIM July 2026
* Device Identity triples: containing cryptographic credentials -
for example, an IDevID - uniquely identifying a device
(Section 5.1.9).
* 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.
* lang (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
Birkholz, et al. Expires 7 January 2027 [Page 23]
Internet-Draft CoRIM July 2026
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 unique
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): A universally unique 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
A Tag ID is either a 16-byte binary string, or a textual identifier,
uniquely referencing the CoMID. The tag identifier MUST be globally
unique. Failure to ensure global uniqueness can create ambiguity in
tag use since the tag-id serves as the global key for matching,
Birkholz, et al. Expires 7 January 2027 [Page 24]
Internet-Draft CoRIM July 2026
lookups and linking. If represented as a 16-byte binary string, the
identifier MUST be a valid universally unique identifier as defined
by [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].
5.1.1.2. Tag Version
tag-version-type = uint .default 0
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.
* maintainer (value 2): an entity making changes to the module
described by the CoMID tag.
Birkholz, et al. Expires 7 January 2027 [Page 25]
Internet-Draft CoRIM July 2026
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 tag-identity-map.
* linked-tag-id (index 0): Unique 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 category 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 7 January 2027 [Page 26]
Internet-Draft CoRIM July 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 7 January 2027 [Page 27]
Internet-Draft CoRIM July 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 globally unique. The combination of values
within class-map MUST combine to form a globally unique identifier.
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 a unique 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 7 January 2027 [Page 28]
Internet-Draft CoRIM July 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 is a unique value that 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 7 January 2027 [Page 29]
Internet-Draft CoRIM July 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 a unique identifier that is reliably bound to a group
of Attesters, for example when a number of Attester 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 7 January 2027 [Page 30]
Internet-Draft CoRIM July 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): The cryptographic identity of the entity
(individual or organization) that is the designated authority for
measurement Claims. For example, the signer of a CoMID triple.
See Section 5.1.4.6. An entity is authoritative when it makes
Claims that are inside its area of competence.
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 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 7 January 2027 [Page 31]
Internet-Draft CoRIM July 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
* $$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.
* 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.
Birkholz, et al. Expires 7 January 2027 [Page 32]
Internet-Draft CoRIM July 2026
* 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.2.4.4.5.6.
* integrity-registers (index 14): A group of one or more named
measurements associated with the environment. Described in
Section 5.1.4.7.
Birkholz, et al. Expires 7 January 2027 [Page 33]
Internet-Draft CoRIM July 2026
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
* version-scheme (index 1): an optional indicator of the versioning
convention used in the version attribute. Defined in Section 4.1
of [RFC9393]. The CDDL is copied below for convenience.
$version-scheme /= &(multipartnumeric: 1)
$version-scheme /= &(multipartnumeric-suffix: 2)
$version-scheme /= &(alphanumeric: 3)
$version-scheme /= &(decimal: 4)
$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.
Birkholz, et al. Expires 7 January 2027 [Page 34]
Internet-Draft CoRIM July 2026
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
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.
Birkholz, et al. Expires 7 January 2027 [Page 35]
Internet-Draft CoRIM July 2026
* 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.
* 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.
Birkholz, et al. Expires 7 January 2027 [Page 36]
Internet-Draft CoRIM July 2026
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.
$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].
Birkholz, et al. Expires 7 January 2027 [Page 37]
Internet-Draft CoRIM July 2026
* 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:
* 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.
Birkholz, et al. Expires 7 January 2027 [Page 38]
Internet-Draft CoRIM July 2026
;# 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 a unique 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).
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
Birkholz, et al. Expires 7 January 2027 [Page 39]
Internet-Draft CoRIM July 2026
{
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.
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 unless
either min or max are infinite as represented by null, in which case,
each infinity is necessarily exclusive.
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.
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:
Birkholz, et al. Expires 7 January 2027 [Page 40]
Internet-Draft CoRIM July 2026
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.
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
Birkholz, et al. Expires 7 January 2027 [Page 41]
Internet-Draft CoRIM July 2026
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.
To process a 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:
Birkholz, et al. Expires 7 January 2027 [Page 42]
Internet-Draft CoRIM July 2026
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.
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:
Birkholz, et al. Expires 7 January 2027 [Page 43]
Internet-Draft CoRIM July 2026
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.
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
Birkholz, et al. Expires 7 January 2027 [Page 44]
Internet-Draft CoRIM July 2026
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.
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 ]
}>
]
Birkholz, et al. Expires 7 January 2027 [Page 45]
Internet-Draft CoRIM July 2026
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.
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.
Birkholz, et al. Expires 7 January 2027 [Page 46]
Internet-Draft CoRIM July 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 ]
}>
]
Figure 6: Attest Key Triple Definition
See Section 5.1.9 for additional details.
5.1.11. Triples for domain definition
A domain is a graphical description of a Composite Attester 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.
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.
Birkholz, et al. Expires 7 January 2027 [Page 47]
Internet-Draft CoRIM July 2026
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.2.3.7.5) then processed as described in
Section 8.2.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).
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.2.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.
Birkholz, et al. Expires 7 January 2027 [Page 48]
Internet-Draft CoRIM July 2026
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 create domains. Instead, TDT processing first checks
that a domain-id has already been accepted into the ACS before adding
trust dependencies.
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.
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.
Birkholz, et al. Expires 7 January 2027 [Page 49]
Internet-Draft CoRIM July 2026
* 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.2.3.7.6) then processed as described in
Section 8.2.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 unique 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.
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.
Birkholz, et al. Expires 7 January 2027 [Page 50]
Internet-Draft CoRIM July 2026
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 valid for appraisal.
There may be cases when 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.
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 and additional
grammatical requirements specified in the text of this Section MUST
be followed when creating or validating a CoTL tag are given below:
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.
Birkholz, et al. Expires 7 January 2027 [Page 51]
Internet-Draft CoRIM July 2026
* tag-identity (index 0): A tag-identity-map containing unique
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 })
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
Birkholz, et al. Expires 7 January 2027 [Page 52]
Internet-Draft CoRIM July 2026
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).
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)
Birkholz, et al. Expires 7 January 2027 [Page 53]
Internet-Draft CoRIM July 2026
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 ]
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
responsible allocator entity SHOULD ensure uniqueness within the
context that it is used.
tagged-bytes = #6.560(bytes)
Birkholz, et al. Expires 7 January 2027 [Page 54]
Internet-Draft CoRIM July 2026
8. Reference Verifier
This section outlines the behaviour 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. 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.
Birkholz, et al. Expires 7 January 2027 [Page 55]
Internet-Draft CoRIM July 2026
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
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.2 describes the handoff interface between
Phase 4 and the subsequent phases in terms of the computed ACS.
8.2. The CoRIM Processor
This document assumes that Verifier implementations will differ. In
order to describe normative Verifier behaviour, this section presents
a reference Verifier and illustrates how the data is utilized within
the appraisal phases detailed in Section 8.1. If the Verifier
operates on CoRIM documents, it is RECOMMENDED that it follows this
algorithm.
8.2.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.
Birkholz, et al. Expires 7 January 2027 [Page 56]
Internet-Draft CoRIM July 2026
.-----------------------.
| Reference Values |
| and Endorsements |
'-----------+-----------'
|
.-------+-----------.
.-+-----------------. |
.-+-----------------. +-'
| CoRIM file(s) +-'
'---------+---------'
|
.--------------------------|---------------.
| RATS Verifier | |
| .-----------------------+------------. |
| | CoRIM Processor v | |
| | .--------------. | |
| | | 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 | |
'----------------' | '-------------' |
'------------------------------------------'
Birkholz, et al. Expires 7 January 2027 [Page 57]
Internet-Draft CoRIM July 2026
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. Instead, the internal 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.2.2. Data Structures
This section describes the data structures used by the CoRIM
processor.
8.2.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.
Birkholz, et al. Expires 7 January 2027 [Page 58]
Internet-Draft CoRIM July 2026
Claims in ECTs have a both 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.2.2.1.1;
* M-ECT (Domain Membership ECT): used to represent domain membership
Claims, as detailed in Section 8.2.2.1.2;
* T-ECT (Trust Dependency ECT): used to represent trust dependency
Claims, as detailed in Section 8.2.2.1.2;
* K-ECT (Key ECT): used to represent Identity and Attestation keys,
as detailed in Section 8.2.2.1.4.
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.
Birkholz, et al. Expires 7 January 2027 [Page 59]
Internet-Draft CoRIM July 2026
* 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 is a mandatory attribute in an ECT.
* 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.2.4.4.
8.2.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
Birkholz, et al. Expires 7 January 2027 [Page 60]
Internet-Draft CoRIM July 2026
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).
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.
Birkholz, et al. Expires 7 January 2027 [Page 61]
Internet-Draft CoRIM July 2026
8.2.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 member nodes that comprises the domain.
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 attributes.
*Merge Rules.*
If two Domain ECTs have the same environment, authority and profile
then their members are merged. Any duplicates MUST be pruned.
8.2.2.1.3. Trust Dependency ECT
A Trust Depedency 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 comprises 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 chainto the parent environment.
Birkholz, et al. Expires 7 January 2027 [Page 62]
Internet-Draft CoRIM July 2026
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 attributes.
*Merge Rules.*
If two Trust ECTs have the same environment, authority and profile
then their trustees are merged. Any duplicates MUST be pruned.
8.2.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 encodes the name of the Claim. The value of the Claim is
encoded in the key-list attribute.
Birkholz, et al. Expires 7 January 2027 [Page 63]
Internet-Draft CoRIM July 2026
*Merge Rules.*
No merge rules are specified for a Key ECT.
8.2.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 condition 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).
// [TODO] Merge §2.1 and §2.2. to explain the high-level principles
// before delving into the details.
8.2.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
Birkholz, et al. Expires 7 January 2027 [Page 64]
Internet-Draft CoRIM July 2026
Figure 19: Profiled ECT for Evidence
All E-ECT attributes are mandatory, except profile.
8.2.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.2.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)
Birkholz, et al. Expires 7 January 2027 [Page 65]
Internet-Draft CoRIM July 2026
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.
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.2.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 7 January 2027 [Page 66]
Internet-Draft CoRIM July 2026
The evs relation compares the condition ECTs with the ACS.
// [TBC] There is only one ECT in the condition. The description
// doesn't seem to match the data format. If all the ECTs are found
in the ACS, each entry in the series list is evaluated. The
selection ECTs are then compared with the ACS. If the selection
criteria are met, the addition ECTs are added to the ACS and the
series evaluation ends. If the selection criteria are not satisfied,
evaluation proceeds to the next series list entry.
Figure 25 shows the profiled Element ECT 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 ECT for Endorsed Values and Endorsed Values
Series tuples (condition)
Figure 26 shows the profiled Element ECT an Endorsed Value selection.
Endorsement-selection-ECT = ({
environment: environment-map
element-list: [ + element-map ]
? authority: [ + $crypto-key-type-choice ]
}) .within E-ECT
Figure 26: Profiled ECT for Endorsed Values and Endorsed Values
Series tuples (selection)
Figure 27 shows the profiled Element ECT 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 27: Profiled ECT for Endorsed Values and Endorsed Values
Series tuples (addition)
Birkholz, et al. Expires 7 January 2027 [Page 67]
Internet-Draft CoRIM July 2026
8.2.2.2.4. Keys
The internal representation of Attest Key and Device Identity triples
uses the keys relation (Figure 28), 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 28: Keys Relation
// [TODO] Specialise condition/addition ECTs. Define constraints.
8.2.2.2.5. Domain Memberships
The internal representation of Domain Membership uses the dm relation
(Figure 29), whereby each domain-item corresponds to a domain-
membership-triple-record.
dm = [ + domain-item ]
Figure 29: Domain Membership Relation
domain-item = {
condition: Domain-condition-ECT
addition: Domain-addition-ECT
}
Figure 30: Domain Item
Figure 31 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 31: Profiled ECT for Domain Membership (condition)
Birkholz, et al. Expires 7 January 2027 [Page 68]
Internet-Draft CoRIM July 2026
Only the members are used for matching, not the environment.
Therefore, the environment attribute is excluded from the ECT
condition.
Figure 32 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 32: Profiled ECT for Domain Membership (addition)
8.2.2.2.6. Trust Dependencies
The internal representation of Trust Dependency uses the td relation
(Figure 33), whereby each td-item corresponds to a trust-dependency-
triple-record.
td = [ + td-item ]
Figure 33: Trust Dependency Relation
td-item = {
condition: Trust-Dependency-condition-ECT
addition: Trust-Dependency-addition-ECT
}
Figure 34: Trust Dependency Item
Figure 35 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 35: Profiled ECT for Trust Dependency (condition)
Both the trustees and environment are used for matching.
Figure 36 shows the profiled T-ECT for Trust Dependency additions.
Birkholz, et al. Expires 7 January 2027 [Page 69]
Internet-Draft CoRIM July 2026
Trust-Dependency-addition-ECT = ({
environment: environment-map
authority: [ + $crypto-key-type-choice ]
? profile: $profile-type-choice
trustees: [ + environment-map ]
}) .within T-ECT
Figure 36: Profiled ECT for Trust Dependency (addition)
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 48. 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 enviroment and
all trustess exist in the membership graph expressed by the dm
relation (Figure 29) in the ACS.
8.2.2.3. ACS
The ACS (Figure 37) 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 37: 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.2.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.
Birkholz, et al. Expires 7 January 2027 [Page 70]
Internet-Draft CoRIM July 2026
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.2.2.4. Staging Area
The staging area (Figure 38) is a list of the relations corresponding
to the transformed triples.
StagingArea = [
? rv,
? ev,
? evs,
? keys,
? dm,
? dd,
]
Figure 38: 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.2.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.1, 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.
Birkholz, et al. Expires 7 January 2027 [Page 71]
Internet-Draft CoRIM July 2026
8.2.3.1. CoRIM Selection
All available CoRIMs 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.
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.2.3.2. CoRIM Trust Anchors
If CoRIM tags are signed, the signatures MUST be validated 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.
8.2.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.
8.2.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.
Birkholz, et al. Expires 7 January 2027 [Page 72]
Internet-Draft CoRIM July 2026
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.2.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.2.2.2.1), making it suitable for
appraisal processing.
The exact protocol used to collect Evidence is out of scope of this
specification.
8.2.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 collected it MUST provide the required security. In such
cases, the cryptographic validation of Evidence depends on the
security offered by the conveyance protocol.
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.
Birkholz, et al. Expires 7 January 2027 [Page 73]
Internet-Draft CoRIM July 2026
As a second example, the verification public key use 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.2.3.7. Input Transformation
This section describes how the relevant RATS Conceptual Messages are
transformed upon ingestion by the CoRIM processor.
8.2.3.7.1. Evidence
Evidence transformation involves mapping Evidence into one or more
Evidence-ECTs (see Section 8.2.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.2.3.7.2. Reference Values
Reference Values transformation involves mapping Reference Value
triples into into an rv relation (see Section 8.2.2.2.2). Each
reference-triple-record (Figure 1) is transformed into an rv-item
(Figure 20) as described in Figure 39. (The code reuses the
mms_to_ems function from Figure 14.)
Birkholz, et al. Expires 7 January 2027 [Page 74]
Internet-Draft CoRIM July 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 39: 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.2.3.7.3. Endorsed Values
Endorsed Values transformation involves mapping EV, CE and CES
triples into into ev or evs relations (see Section 8.2.2.2.3).
A endorsed-triple-record (Figure 2) 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 7 January 2027 [Page 75]
Internet-Draft CoRIM July 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 40: Endorsed Value Triple Transformation
A conditional-endorsement-triple-record (Figure 3) is transformed
into an ev-item (Figure 23) as described in Figure 41. (The code
reuses the mms_to_ems function from Figure 14.)
Birkholz, et al. Expires 7 January 2027 [Page 76]
Internet-Draft CoRIM July 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 41: Conditional Endorsement Triple Transformation
Each conditional-endorsement-series-triple-record (Figure 4) is
transformed into an evs-item (Figure 24) as described in Figure 42.
(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.2.4.3.2).
Birkholz, et al. Expires 7 January 2027 [Page 77]
Internet-Draft CoRIM July 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
ELSE_IF 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[index-of(sitem)] = sitem
RETURN evsitem
}
Figure 42: Conditional Endorsement Series Triple Transformation
8.2.3.7.4. Keys
Keys transformation involves mapping Attest Key and Device Identity
triples into into a key relation (see Section 8.2.2.2.4).
An attest-key-triple-record (Figure 6) or an identity-triple-record
(Figure 5) is transformed into a key-item (Figure 28) as described in
Figure 43.
Birkholz, et al. Expires 7 January 2027 [Page 78]
Internet-Draft CoRIM July 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 43: Key Triple Transformation
Note that keys are added under the authority of the verifier.
8.2.3.7.5. Domain Membership Transformation
Domain membership transformation maps Domain Membership triples into
dm relations (see Section 8.2.2.2.5).
Prior to adding a domain membership relation, a domain-membership-
triple-record (Figure 7) is transformed into a domain-item
(Figure 29) using the domain membership transformation algorithm
Figure 44.
Birkholz, et al. Expires 7 January 2027 [Page 79]
Internet-Draft CoRIM July 2026
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 44: Domain Membership Transformation
Subsequent to transformation the domain membership relations are
processed using the domain membershp processing algorithm
Section 8.2.4.3.4.
8.2.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.2.2.2.6) using the trust dependency
transformation algorithm Figure 45.
Birkholz, et al. Expires 7 January 2027 [Page 80]
Internet-Draft CoRIM July 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 45: Trust Dependency Transformation
Subsequent to transformation, the trust dependency relations are
processed using the trust dependency processing algorithm
Section 8.2.4.3.5.
8.2.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 ev relation:
FUNC init_acs(ae: ae) -> ACS {
FOREACH item IN ae:
acs::APPEND(item.addition)
RETURN acs
}
Figure 46: ACS Initialization
The staging area is loaded with rv, ev, evs, keys, dm and td
relations, in that order.
Birkholz, et al. Expires 7 January 2027 [Page 81]
Internet-Draft CoRIM July 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 47: Staging Area Initialization
8.2.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 48) 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 7 January 2027 [Page 82]
Internet-Draft CoRIM July 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::CHECK(item.addition):
acs::APPEND(item.addition)
RETURN acs
}
Figure 48: 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::CHECK operation does consistency
checks. The checking logic for each type of relation is described in
the following sections. The acs::APPEND operation also depends on
the type of relation. This could involve simply appending the
addition ECT.
The addition could result in inconsistent ACS. Additional ACS
consistency checking might be needed.
8.2.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 behaviour 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 48 assumes that
relations have been topologically sorted prior to loading into the
staging area (Figure 47).
8.2.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.2.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).
Birkholz, et al. Expires 7 January 2027 [Page 83]
Internet-Draft CoRIM July 2026
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.2.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.2.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.2.4.3.2. Processing evs Relations
The Conditional Endorsement Series relation is processed using a
modified match_and_augment function (see Figure 48) where SERIES-
MATCH() calls MATCH() (see Figure 49).
The first series item that matches terminates processing of
subsequent series items.
The matched item is appended to the ACS.
Birkholz, et al. Expires 7 January 2027 [Page 84]
Internet-Draft CoRIM July 2026
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):
acs::APPEND(ser-add)
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 49: Series Match and Augment Algorithm
8.2.4.3.3. Processing keys Relations
Keys relations identify cryptographic keys that require additional
key verification steps.
Keys are matched with ACS entries by iterating through the keys list.
For each keys entry, the condition ECT is compared with an ACS ECT
with cmtype 1 or 2 (i.e., endorsements or evidence). If they match,
perform the following steps for each key in the condition ECT key-
list:
1. Verify the certificate signatures for each certificate in the
certification path.
2. Verify the revocation status for each certificate in the
certification path.
3. Verify the key usage restrictions that are appropriate for key-
type.
A key that successfully passes the above checks is said to be
verified.
Add all the verified keys to the addition ECT's key-list and add the
addition ECT to the ACS.
8.2.4.3.4. Processing dm Relations
Domain Membership relations describe the expected topological
arrangement of the Attester.
Birkholz, et al. Expires 7 January 2027 [Page 85]
Internet-Draft CoRIM July 2026
Domains are matched with ACS entries by iterating through the dm
list, in the staging area.
The acs::CHECK() does acyclic graph consistency checks of the
condition ECTs in the dm relation.
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 member 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.
If there is no match, processing moves to the next dm entry, till the
list is exhausted and is known as 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 optimised 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.2.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 48.
Birkholz, et al. Expires 7 January 2027 [Page 86]
Internet-Draft CoRIM July 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::IS-MEMBER(dm-item.members):
BREAK # break inner loop, try another dm-item
RETURN TRUE
RETURN FALSE
Figure 50: Process Trust Dependency Algorithm
The ACS::CHECK() function does acyclic graph consistency checks of
the condition ECTs in the td relation.
The ACS:: APPEND() function adds the dm-item.addition to the ACS.
Subsequent to the append, the ACS acyclic consistency check needs to
be performed.
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 a minimum strength of function as TE-1.
8.2.4.4. Rules of Comparison
The matching component of the "match and augment" algorithm (see
Section 8.2.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).
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.2.4.3.4 for an example of
this, where the environments of M-ECTs and E-ECTs are compared.
Birkholz, et al. Expires 7 January 2027 [Page 87]
Internet-Draft CoRIM July 2026
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.2.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.2.4.4.3), Key ECTs
will match on key-list, Domain Membership ECTs will typically match
on members (see Section 8.2.4.3.4) and Trust Dependency ECTs will
typically match on trustees (see Section 8.2.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.
8.2.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-id or group-id) are also present in the ACS-ECT and
are binary identical, the two environments match. Otherwise, the
environments do not match.
Any attribute that is present in the ACS-ECT but not in the C-ECT is
ignored in the comparison.
Birkholz, et al. Expires 7 January 2027 [Page 88]
Internet-Draft CoRIM July 2026
8.2.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.2.4.4.3. Element List Comparison
A C-ECT's element-list matches an ACS-ETC'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.2.4.4.4.
8.2.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.
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.2.4.4.5.
8.2.4.4.5. Measurement Values Map Comparison
The C-ECT's element-claims match an ACS-ECT's element-claims if:
1. Each attribute in the C-ECT's measurement-values-map is also
present in the ACS-ECT's measurement-values-map; and
Birkholz, et al. Expires 7 January 2027 [Page 89]
Internet-Draft CoRIM July 2026
2. The attribute values match.
Otherwise, the element claims do not match.
The rules for matching a single measurement-values-map attribute are
described in Section 8.2.4.4.5.1
8.2.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.
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.
If the processor is unable to determine the applicable comparison
algorithm for an attribute, it MUST behave as though the C-ECT does
not match the ACS-ECT.
The following subsections define the comparison algorithms for the
measurement-values-map attributes defined by this specification.
8.2.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.2.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 7 January 2027 [Page 90]
Internet-Draft CoRIM July 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 51.
Birkholz, et al. Expires 7 January 2027 [Page 91]
Internet-Draft CoRIM July 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 51: SVN Comparison
8.2.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 7 January 2027 [Page 92]
Internet-Draft CoRIM July 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.2.4.4.5.5. Comparison for raw-value entries
A raw-value entry contains binary data.
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.
Birkholz, et al. Expires 7 January 2027 [Page 93]
Internet-Draft CoRIM July 2026
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.
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.2.4.4.5.6. 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.
8.2.4.4.5.7. 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.2.4.4.5.4 after equivalence has been
Birkholz, et al. Expires 7 January 2027 [Page 94]
Internet-Draft CoRIM July 2026
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.2.4.4.5.8. 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 a 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:
- 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.
Birkholz, et al. Expires 7 January 2027 [Page 95]
Internet-Draft CoRIM July 2026
8.2.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.
Note that the processor may compare Reference Values in any order, so
the comparison SHOULD NOT be stateful.
8.2.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
does not need to know all the details in order to make a trust
decision.
8.2.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.2.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 52) 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.
Birkholz, et al. Expires 7 January 2027 [Page 96]
Internet-Draft CoRIM July 2026
/ 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'
)
}
},
[
/ 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'
)
}
},
[
Birkholz, et al. Expires 7 January 2027 [Page 97]
Internet-Draft CoRIM July 2026
/ 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') ]
}
}
]
] ]
}
}
Figure 52: 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 53). 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
Birkholz, et al. Expires 7 January 2027 [Page 98]
Internet-Draft CoRIM July 2026
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') ]
}
}
]
]
],
/ 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"
}
}
]
]
]
]
]
}
}
Birkholz, et al. Expires 7 January 2027 [Page 99]
Internet-Draft CoRIM July 2026
Figure 53: 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.2.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.2.6.3. Internal Representations
As described in Section 8.2.3, once all the "raw" inputs and have
been validated, input transformations can start.
The two Reference Values triples from the manufacturer's CoMID are
mapped to their corresponding rv-items (Figure 54, Figure 55) using
the transformations defined in Figure 39.
The first triple:
Birkholz, et al. Expires 7 January 2027 [Page 100]
Internet-Draft CoRIM July 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 54: First rv Relation Item
The second triple:
Birkholz, et al. Expires 7 January 2027 [Page 101]
Internet-Draft CoRIM July 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 55: Second rv Relation Item
Birkholz, et al. Expires 7 January 2027 [Page 102]
Internet-Draft CoRIM July 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 56) using the
transformation defined in Figure 41.
{
"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 7 January 2027 [Page 103]
Internet-Draft CoRIM July 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 56: 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 7 January 2027 [Page 104]
Internet-Draft CoRIM July 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 57: 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 7 January 2027 [Page 105]
Internet-Draft CoRIM July 2026
8.2.6.4. Appraisal
As described in Section 8.2.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.2.4 can begin.
The first relation to be processed is rv, according to the rules
described in Section 8.2.4.2.1.
The condition of the first rv-item (Figure 54) is matched against the
ACS which, at this time, contains a single ECT obtained from the ae-
item (Figure 57). 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 58).
[
/ 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 7 January 2027 [Page 106]
Internet-Draft CoRIM July 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 7 January 2027 [Page 107]
Internet-Draft CoRIM July 2026
],
"cmtype": 0,
"profile": 32("tag:arm.com,2025:psa#1.0.0")
}
]
Figure 58: ACS State after Corroboration
The algorithm then moves on to the second rv-item (Figure 55),
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.2.4.3.1. The condition
of the first (and only) ev-item (Figure 56) 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 59).
[
/ Evidence ECT / {
"environment": {
0: {
0: 560(h'61636d652d696d706c656d656e746174
696f6e2d69642d303030303030303031')
},
1: 550(h'01
4ca3e4f50bf248c39787020d68ffd05c
88767751bf2645ca923f57a98becd296')
}
Birkholz, et al. Expires 7 January 2027 [Page 108]
Internet-Draft CoRIM July 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 7 January 2027 [Page 109]
Internet-Draft CoRIM July 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 59: 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 48)
terminates, returning the computed ACS.
Birkholz, et al. Expires 7 January 2027 [Page 110]
Internet-Draft CoRIM July 2026
9. Implementation Status
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.2 of this specification.
Birkholz, et al. Expires 7 January 2027 [Page 111]
Internet-Draft CoRIM July 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 7 January 2027 [Page 112]
Internet-Draft CoRIM July 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 7 January 2027 [Page 113]
Internet-Draft CoRIM July 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- | RFCthis |
| | | tag, 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 | |
+---------+-------------+-------------------------------+-----------+
| 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- | RFCthis |
| | bytes] | type, see Section 7.7 | |
+---------+-------------+-------------------------------+-----------+
| 558 | COSE_Key | tagged-cose-key-type, see | RFCthis |
| | | Section 5.1.4.6 | |
Birkholz, et al. Expires 7 January 2027 [Page 114]
Internet-Draft CoRIM July 2026
+---------+-------------+-------------------------------+-----------+
| 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-599 | any | Earmarked for CoRIM | RFCthis |
+---------+-------------+-------------------------------+-----------+
Table 3
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 7 January 2027 [Page 115]
Internet-Draft CoRIM July 2026
+=========+=========================+
| Range | Registration Procedures |
+=========+=========================+
| 0-127 | Standards Action |
+---------+-------------------------+
| 128-255 | Specification Required |
+---------+-------------------------+
Table 4: 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 |
+-------+----------------+---------------+
| 3-255 | Unassigned | |
+-------+----------------+---------------+
Table 5: 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 7 January 2027 [Page 116]
Internet-Draft CoRIM July 2026
+=========+=========================+
| Range | Registration Procedures |
+=========+=========================+
| 0-127 | Standards Action |
+---------+-------------------------+
| 128-255 | Specification Required |
+---------+-------------------------+
Table 6: 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 | Specification |
+=======+=============+==================+========================+
| 0 | entity-name | text | Name of the entity |
| | | | responsible for the |
| | | | actions of the role. |
+-------+-------------+------------------+------------------------+
| 1 | reg-id | uri | A URI associated with |
| | | | the organization that |
| | | | owns the entity name. |
+-------+-------------+------------------+------------------------+
| 2 | role | [ + role-type- | A type choice defining |
| | | choice ] | the roles that the |
| | | | entity is claiming. |
+-------+-------------+------------------+------------------------+
| 3-255 | Unassigned | | |
+-------+-------------+------------------+------------------------+
Table 7: CoRIM Entity Map Items Initial Registrations
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:
Birkholz, et al. Expires 7 January 2027 [Page 117]
Internet-Draft CoRIM July 2026
+=========+=========================+
| Range | Registration Procedures |
+=========+=========================+
| 0-127 | Standards Action |
+---------+-------------------------+
| 128-255 | Specification Required |
+---------+-------------------------+
Table 8: 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 9: 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 7 January 2027 [Page 118]
Internet-Draft CoRIM July 2026
+=========+=========================+
| Range | Registration Procedures |
+=========+=========================+
| 0-127 | Standards Action |
+---------+-------------------------+
| 128-255 | Specification Required |
+---------+-------------------------+
Table 10: 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 | entity | RFCthis |
+-------+--------------+---------------+
| 3 | linked-tags | RFCthis |
+-------+--------------+---------------+
| 4 | triples | RFCthis |
+-------+--------------+---------------+
| 5-255 | Unassigned | |
+-------+--------------+---------------+
Table 11: CoMID Map Items Initial
Registrations
11.7. CoMID 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 7 January 2027 [Page 119]
Internet-Draft CoRIM July 2026
+=========+=========================+
| Range | Registration Procedures |
+=========+=========================+
| 0-127 | Standards Action |
+---------+-------------------------+
| 128-255 | Specification Required |
+---------+-------------------------+
Table 12: 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 | Specification |
+=======+=============+==================+========================+
| 0 | entity-name | text | Name of the entity |
| | | | responsible for the |
| | | | actions of the role. |
+-------+-------------+------------------+------------------------+
| 1 | reg-id | uri | A URI associated with |
| | | | the organization that |
| | | | owns the entity name. |
+-------+-------------+------------------+------------------------+
| 2 | role | [ + role-type- | A type choice defining |
| | | choice ] | the roles that the |
| | | | entity is claiming. |
+-------+-------------+------------------+------------------------+
| 3-255 | Unassigned | | |
+-------+-------------+------------------+------------------------+
Table 13: CoMID Entity Map Items Initial Registrations
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:
Birkholz, et al. Expires 7 January 2027 [Page 120]
Internet-Draft CoRIM July 2026
+============================+=========================+
| Range | Registration Procedures |
+============================+=========================+
| 0-1023 | Standards Action |
+----------------------------+-------------------------+
| 1024-65535 | Specification Required |
+----------------------------+-------------------------+
| 65536-18446744073709551616 | First come first served |
+----------------------------+-------------------------+
Table 14: 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 7 January 2027 [Page 121]
Internet-Draft CoRIM July 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 15: 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
multiple triples' representations.
Future registrations for this registry are to be made based on
[RFC8126] as follows:
Birkholz, et al. Expires 7 January 2027 [Page 122]
Internet-Draft CoRIM July 2026
+============================+=========================+
| Range | Registration Procedures |
+============================+=========================+
| 0-1023 | Standards Action |
+----------------------------+-------------------------+
| 1024-65535 | Specification Required |
+----------------------------+-------------------------+
| 65536-18446744073709551616 | First come first served |
+----------------------------+-------------------------+
Table 16: 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.
Birkholz, et al. Expires 7 January 2027 [Page 123]
Internet-Draft CoRIM July 2026
+=======================+===========================+=============+
|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 |
+-----------------------+---------------------------+-------------+
|13 | cryptokeys |RFCthis |
+-----------------------+---------------------------+-------------+
|14 | integrity-registers |RFCthis |
+-----------------------+---------------------------+-------------+
|15 | int-range |RFCthis |
+-----------------------+---------------------------+-------------+
|16-18446744073709551616| Unassigned | |
+-----------------------+---------------------------+-------------+
Table 17: 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:
Birkholz, et al. Expires 7 January 2027 [Page 124]
Internet-Draft CoRIM July 2026
+============================+=========================+
| Range | Registration Procedures |
+============================+=========================+
| 0-1023 | Standards Action |
+----------------------------+-------------------------+
| 1024-65535 | Specification Required |
+----------------------------+-------------------------+
| 65536-18446744073709551616 | First come first served |
+----------------------------+-------------------------+
Table 18: CoMID Flags 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 |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 19: Flags Map Items Initial Registrations
Birkholz, et al. Expires 7 January 2027 [Page 125]
Internet-Draft CoRIM July 2026
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:
+=========+=========================+
| Range | Registration Procedures |
+=========+=========================+
| 0-127 | Standards Action |
+---------+-------------------------+
| 128-255 | Specification Required |
+---------+-------------------------+
Table 20: 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 21: 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].
Birkholz, et al. Expires 7 January 2027 [Page 126]
Internet-Draft CoRIM July 2026
+==========+======================+============================+
| Name | Template | Reference |
+==========+======================+============================+
| rim+cbor | application/rim+cbor | RFCthis, (Section 11.12.1) |
+----------+----------------------+----------------------------+
| rim+cose | application/rim+cose | RFCthis, (Section 11.12.2) |
+----------+----------------------+----------------------------+
Table 22: New Media Types
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? Maybe
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
Birkholz, et al. Expires 7 January 2027 [Page 127]
Internet-Draft CoRIM July 2026
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)
Intended usage: COMMON
Restrictions on usage: none
Author/Change controller: IETF
Provisional registration? Maybe
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 23: New Content-Formats
12. References
12.1. Normative References
[I-D.ietf-cose-hash-envelope]
Steele, O., Lasker, S., and H. Birkholz, "COSE Hash
Envelope", Work in Progress, Internet-Draft, draft-ietf-
cose-hash-envelope-10, 15 November 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
hash-envelope-10>.
Birkholz, et al. Expires 7 January 2027 [Page 128]
Internet-Draft CoRIM July 2026
[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>.
[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>.
[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>.
[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 7 January 2027 [Page 129]
Internet-Draft CoRIM July 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>.
[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>.
Birkholz, et al. Expires 7 January 2027 [Page 130]
Internet-Draft CoRIM July 2026
[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 7 January 2027 [Page 131]
Internet-Draft CoRIM July 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-02, 5 December
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
rats-concise-ta-stores-02>.
[I-D.ietf-rats-endorsements]
Thaler, D., Birkholz, H., and T. Fossati, "RATS
Endorsements", Work in Progress, Internet-Draft, draft-
ietf-rats-endorsements-09, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
endorsements-09>.
[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-02, 17 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
evidence-trans-02>.
[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 7 January 2027 [Page 132]
Internet-Draft CoRIM July 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>.
[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\
-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
Birkholz, et al. Expires 7 January 2027 [Page 133]
Internet-Draft CoRIM July 2026
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
$profile-type-choice /= uri / tagged-oid-type
cwt-claims = {
&(iss: 1) => tstr,
? &(sub: 2) => tstr,
? &(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,
Birkholz, et al. Expires 7 January 2027 [Page 134]
Internet-Draft CoRIM July 2026
}
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)
tagged-concise-swid-tag = #6.505(bytes .cbor coswid.concise-swid-tag)
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,
}
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,
Birkholz, et al. Expires 7 January 2027 [Page 135]
Internet-Draft CoRIM July 2026
? &(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],
]
$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],
Birkholz, et al. Expires 7 January 2027 [Page 136]
Internet-Draft CoRIM July 2026
]
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,
? &(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],
}>,
Birkholz, et al. Expires 7 January 2027 [Page 137]
Internet-Draft CoRIM July 2026
]
$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
linked-tag-map = {
&(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,
* $$measurement-values-map-extension,
Birkholz, et al. Expires 7 January 2027 [Page 138]
Internet-Draft CoRIM July 2026
}>
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,
])
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 .default 0
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)
Birkholz, et al. Expires 7 January 2027 [Page 139]
Internet-Draft CoRIM July 2026
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 => \
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
Birkholz, et al. Expires 7 January 2027 [Page 140]
Internet-Draft CoRIM July 2026
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
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,
Birkholz, et al. Expires 7 January 2027 [Page 141]
Internet-Draft CoRIM July 2026
? 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,
? 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
Birkholz, et al. Expires 7 January 2027 [Page 142]
Internet-Draft CoRIM July 2026
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
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,
}
Birkholz, et al. Expires 7 January 2027 [Page 143]
Internet-Draft CoRIM July 2026
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
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>,
Birkholz, et al. Expires 7 January 2027 [Page 144]
Internet-Draft CoRIM July 2026
)
coswid.process = 18
coswid.process-entry = {
coswid.process-name => text,
? coswid.pid => integer,
* $$process-extension,
coswid.global-attributes,
}
coswid.resource = 19
coswid.resource-entry = {
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
Birkholz, et al. Expires 7 January 2027 [Page 145]
Internet-Draft CoRIM July 2026
Acknowledgments
The authors would like to thank the following people for their review
and comments on this document: Carl Wallace, Hannes Tschofenig,
Steven Bellock, Jag Raman, Giri Mandyam, Jeremy O'Donoghue, Michael
Richardson, Dhawal Kumar, Spencer Gilson, and Sergei Trofimov.
Contributors
Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
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.
Authors' Addresses
Henk Birkholz
Fraunhofer SIT
Email: henk.birkholz@ietf.contact
Thomas Fossati
Linaro
Birkholz, et al. Expires 7 January 2027 [Page 146]
Internet-Draft CoRIM July 2026
Email: Thomas.Fossati@linaro.org
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 7 January 2027 [Page 147]