Concise Reference Integrity Manifest

Concise Reference Integrity Manifest Fraunhofer SIT

henk.birkholz@ietf.contact

NVIDIA

tfossati@nvidia.com

arm

yogesh.deshpande@arm.com

Independent

ned.smith.ietf@outlook.com

Huawei Technologies

william.panwei@huawei.com

Security Remote ATtestation ProcedureS RIM, RATS, attestation, verifier, supply chain 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 Source for this draft and an issue tracker can be found at .

Introduction The RATS Architecture specifies several roles, including Endorsers and Reference Value Providers. These two roles are typically fulfilled by supply chain actors, such as manufacturers, distributors, or device owners. Endorsers and Reference Value Providers supply Endorsements (e.g., test results or certification data) and Reference Values (e.g., digests) relating to an Attester. This information is used by a Verifier to appraise Evidence received from an Attester which describes Attester operational state. In a complex supply chain, multiple actors will likely produce these values over several points in time. As such, one supply chain actor might only supply a portion of the Reference Values or Endorsements that otherwise fully characterizes an Attester. Ideally, only the supply chain actor who is the most knowledgeable entity regarding a particular component will supply Reference Values or Endorsements for that component. Attesters vary across vendors and even across products from a single vendor. Not only can Attesters evolve, requiring new measurement types to be expressed, but an Endorser may also want to provide new security relevant attributes about an Attester at a future point in time. 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 encoding suitable for cryptographic operations (e.g., hashing, signing, encryption) and transmission over computer networks. Additionally, this document describes multiple phases of a Verifier Appraisal and provides an example of a possible use of CoRIM messages from multiple supply chain actors to represent a homogeneous representation of Attester state. CoRIM is extensible to accommodate supply chain diversity while supporting a common representation for Endorsement and Reference Value inputs to Verifiers. In essence, the goal of a CoRIM is to describe expected Attester state to Verifiers. This document is divided into two parts. The core data model is described in , and . 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. 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}

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 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 . For a complete glossary, see . This document uses the terms "actual state" and "reference state" as defined in . 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 , CDDL and COSE applies; in particular, CBOR diagnostic notation is defined in and . Terms and concepts are always referenced as proper nouns, i.e., with Capital Letters.

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 .
Attribute Path:: A sequence of one or more attribute identifiers that denotes a value within a structured data object by successive selection from a root value. Each identifier in the sequence names the next attribute to select; the final identifier in the sequence names the value reached by the path. An Attribute Path is said to be defined in a given value if every prefix of the path exists in that value; otherwise, the path is undefined in that value. In this document, structured data objects are typically CBOR maps whose attributes are identified by CDDL member names (for example, instance, class, class-id). Attribute Paths are used when comparing nested data structures during appraisal (see ).
Attribute Path Containment:: A comparison relation between two structured data objects, conventionally named the condition (C) and the entry (A), in which C is said to be contained in A when: 1. for every Attribute Path defined in C, the same Attribute Path is defined in A; and 2. for each such path, the value in A satisfies the value in C. Attributes present in A but not in C are ignored. Unless otherwise specified for a given attribute type, satisfies means that the two values are equal. Type-specific satisfaction rules - including range membership and minimum bound checks - are defined in and in profile extensions (see ). See and for examples.
Authority:: The entity that asserts a Claim. Typically, a Claim is asserted using a cryptographic key to digitally sign the Claim. A cryptographic key can be a proxy for a human or organizational entity.
Claim:: A piece of information, in the form of a key-value pair. See also and . 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 .
Collision-Resistant Name:: As defined in : "A name in a namespace that enables names to be allocated in a manner such that they are highly unlikely to collide with other names. Examples of collision-resistant namespaces include: Domain Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and X.670 Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an administratively delegated namespace, the definer of a name needs to take reasonable precautions to ensure they are in control of the portion of the namespace they use to define the name." CoRIM identifiers that function as global keys, such as Tag IDs and Environment identifiers, are Collision-Resistant Names.
Composite Attester:: A Composite Attester is either a Composite Device () or a Layered Attester () or any composition involving a combination of one or more Composite Devices or Layered Attesters.
Domain:: A Domain is the hierarchical container used to describe a Composite Attester in terms of its constituent Environments and the compositional relationships among them. Every Environment implicitly defines a Domain; therefore, any triple that creates an Environment also creates a corresponding Domain. Domains exist to organize the structural composition of the Attester, not to introduce additional semantic entities.
Endorsed values:: A set of characteristics of an Attester that do not appear in Evidence. For example, Endorsed Values may include testing or certification data related to a hardware or firmware module. Endorsed Values are said to be "conditional" when they apply if Attester's actual state matches certain conditions. See also .
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 .
Environment-Claim Tuple (ECT):: A structure containing a set of values that describe a Target Environment plus a set of Measurement / Claim values that describe properties of the Target Environment. The ECT also contains Authority which identifies the entity that authored the ECT.
Instance ID:: An identifier of an Environment instance, such as the serial number of a hardware module. See also .
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 , and Section 9.5.5 of .
Range Satisfaction:: A value satisfaction relation in which an entry value is said to satisfy a condition value when the entry lies within the bounds expressed by the condition. For example, an int entry satisfies an int-range condition when the entry is within the condition's inclusive bounds (see ), and an svn entry satisfies a tagged-min-svn condition when the entry is greater than or equal to the condition's minimum (see ).
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 , , and .
Triple:: A term derived from the Resource Description Framework (RDF) to mean a statement expressing a relationship between a subject and an object resource. The nature of the relationship between subject and object is expressed via a predicate. In CoRIM, unlike RDF, the predicate of the triple is implicit and is encoded in the triple's name/codepoint. CoRIM triples typically represent assertions made by the CoRIM author regarding Attesting or Target Environments and their security features, such as Measurements and cryptographic key material. See also Section 3.1 of .

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.

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 . Conceptual Message Representation Requirements

Input Type	Source	How the Verifier Updates the ACS
Evidence	The Device	If the device proves its identity, its claims are added to the ACS and tagged with the device's authority.
Reference Values	CoRIM	The Verifier checks the Reference 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.

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.

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. 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.

Typographical Conventions for CDDL The CDDL definitions in this document follow the naming conventions illustrated in . Type Traits and Typographical Conventions

Type trait	Example	Typographical convention
extensible type choice	`int / text / ...`	`$`NAME`-type-choice`
closed type choice	`int / text`	NAME`-type-choice`
group choice	`( 1 => int // 2 => text )`	`$$`NAME`-group-choice`
group	`( 1 => int, 2 => text )`	NAME`-group`
type	`int`	NAME`-type`
tagged type	`#6.123(int)`	`tagged-`NAME`-type`
map	`{ 1 => int, 2 => text }`	NAME-`map`
flags	`&( a: 1, b: 2 )`	NAME-`flags`

Concise Reference Integrity Manifest (CoRIM) A CoRIM is a collection of tags and related metadata in a concise CBOR encoding. A CoRIM can be digitally signed with a COSE signature. A tag is a structured, machine-readable data format used to identify, describe, and manage modules or components of a system. Tags can be of different types:

Concise Module ID (CoMID) tags () contain metadata and claims about the hardware and firmware modules.
Concise Software ID (CoSWID) tags () are used to identify, describe and manage software components.
Concise Tag List (CoTL) tags () contain the list of CoMID and CoSWID tags that the Verifier should consider as "active" at a certain point in time.

CoRIM allows for new types of tags to be added in future specifications. For example, Concise Trust Anchor Stores (CoTS) () is currently being defined as a standard CoRIM extension. Each CoRIM contains an identifier to distinguish a CoRIM from other CoRIMs. CoRIM can also carry the following optional metadata:

A locator, which allows discovery of possibly related RIMs.
A profile identifier, which is used to interpret the information contained in the enclosed tags. A profile allows the base CoRIM CDDL definition to be customized to fit a specific Attester by augmenting the base CDDL data definition via the specified extension points or by constraining types defined. A profile MUST NOT change the base CoRIM CDDL definition's semantics, which includes not changing or overloading names and numbers registered at IANA registries used by this document. For more detail, see .
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 () 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 () and transported over a secure channel. The following CDDL describes the top-level CoRIM. See Sections 4 and 5 of for diagrams and additional information on CoRIM structure.

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-id-type-choice &(tags: 1) => [ + $concise-tag-type-choice ] ? &(dependent-rims: 2) => [ + corim-locator-map ] ? &(profile: 3) => $profile-type-choice ? &(rim-validity: 4) => validity-map ? &(entities: 5) => [ + corim-entity-map ] * $$corim-map-extension } unsigned-corim-map = corim-map ]]> The following describes each child item of this map.

id (index 0): An identifier for a CoRIM. Described in .
tags (index 1): An array of one or more CoMID, CoSWID or CoTL tags. Described in .
dependent-rims (index 2): One or more services supplying additional, possibly dependent, manifests or related files. Described in .
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
rim-validity (index 4): Specifies the validity period of the CoRIM. Described in .
entities (index 5): A list of entities involved in a CoRIM life-cycle. Described in .
$$corim-map-extension: This CDDL socket is used to add new information structures to the corim-map. Described in .

A corim-map is unsigned, and its tagged form is an entrypoint for parsing a CoRIM, so it is named tagged-unsigned-corim-map.

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.

Tags A $concise-tag-type-choice is a tagged CBOR payload that carries either a CoMID (), a CoSWID (), or a CoTL ().

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. uri / [ + uri ] ? &(thumbprint: 1) => eatmc.digest / [ + eatmc.digest ] } ]]> The following describes each child element of this type.

href (index 0): a URI or array of alternative URIs identifying locations where the additional resource can be fetched. Every URI in the array identifies the same resource.
thumbprint (index 1): expected digest or an array of digests of the resource identified by href. See . Every digest in the array is computed over the same resource, and each uses a different hash algorithm.

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 (). Exercised extension points SHOULD preserve the intent of the original semantics. CoRIM profiles SHOULD be specified in a publicly available document. A CoRIM profile can use one of the base CoRIM media types defined in and 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 or a URL . The profile identifier identifies a documented profile. Any changes to the profile, even the slightest deviation, is considered a different profile that MUST have a different identifier. The CoRIM profile must describe at a minimum the following: (a) how cryptographic verification key material is represented (e.g., using Attestation Keys triples, or CoTS tags), and (b) how key material is associated with the Attesting Environment. The CoRIM profile should also specify whether CBOR deterministic encoding is required. For an example profile definition, see .

Entities The CoRIM Entity is an instantiation of the Entity generic () using a $corim-role-type-choice. The only role defined in this specification for a CoRIM Entity is manifest-creator. The $$corim-entity-map-extension extension socket is empty in this specification. $corim-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.

Signed CoRIM Signing a CoRIM follows the procedures defined in CBOR Object Signing and Encryption . A CoRIM tag MUST be wrapped either in a COSE_Sign1 structure or a COSE_Sign structure. The COSE_Sign structure may be used when:

Multiple authorities need to sign the same unsigned CoRIM payload; or
A single authority needs to sign the same unsigned CoRIM payload using different signing algorithms.

The CoRIM MUST be signed by the CoRIM creator. Other authorities MAY sign the CoRIM. (See for details on multi-signature CoRIM.)

Signing with Single signature COSE_Sign1 is used when a single signer need to produce a signature over an unsigned CoRIM (tagged-unsigned-corim-map). When using COSE_Sign1 the following CDDL specification defines a restrictive subset of COSE header parameters that MUST be used in the protected header alongside additional information about the CoRIM encoded in a corim-meta-map () or alternatively in a CWT-Claims (). The following describes each child element of this type.

protected: A CBOR Encoded protected header which is protected by the COSE signature. Contains information as given by Protected Header Map below.
unprotected: A COSE header that is not protected by COSE signature.
payload: When the payload is signed directly, either a CBOR-encoded tagged CoRIM, or nil if it is detached. When the payload is signed indirectly, the digest of a CBOR-encoded tagged CoRIM.
signature: A COSE signature block, as defined in .

Header Parameters This section describes the header parameters, that need to be set when a. A single signer need to produce a signature using (COSE_Sign1) object. OR b. When multiple signers, each with different authority, need to sign the same unsigned CoRIM, using COSE_Sign object. In this case each array entry of signature_structure has the header parameters that carry the details of the signature algorithm and signer information as detailed in

Protected Header Map 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 , or in a corim-meta map as a legacy alternative, described in . The following describes each child item of this map.

alg (index 1): An integer that identifies a signature algorithm.

Either, when the payload is signed directly:

content-type (index 3): A string that represents the "MIME Content type" carried in the CoRIM payload.

Or, when the payload is signed indirectly using a Hash Envelope ():

payload_hash_alg (index 258): The hash algorithm used to produce the payload.
payload_preimage_content_type (index 259): A string that represents the "MIME Content type" of the CoRIM document used as the pre-image of the payload.
payload_location (index 260): An optional identifier enabling retrieval of the original resource (preimage) identified by the payload.

The value of content-type or payload_preimage_content_type is exactly application/rim+cbor, without media type parameters. In particular, the profile parameter is not used in the COSE header, because the profile is carried in the profile field of the corim-map (). At least one of:

CWT-Claims (index 15): A map that contains metadata associated with a signed CoRIM. Described in .
corim-meta (index 8): A map that contains metadata associated with a signed CoRIM. Described in .

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 ().

CWT Claims The CWT Claims () 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 .
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 , such as:

exp (index 4): Expiration time, formerly signature-validity in .
nbf (index 5): Not before time, formerly signature-validity in .

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-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 .
signature-validity (index 1): Validity period for the CoRIM. Described in .

Signer Map $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.

Unprotected CoRIM Header Map cose-value } ]]>

Signing with Multiple Signatures When using COSE_Sign the following CDDL specification defines the overall structure. The following describes each child element of this type.

protected: The top level protected header parameter. Contains the information pertaining to the signature algorithm and signer details of the authority producing the signature. Refer to for details.
unprotected: The top level unprotected header parameter. Refer to for details.
payload: When the payload is signed directly, this element contains either a CBOR-encoded tagged CoRIM, or nil if it is detached. When the payload is signed indirectly, the digest of a CBOR-encoded tagged CoRIM.
signature: This element contains an array of signature structures, as defined in .

Signature Parameters of Multi Sign CoRIM The signature parameter of a COSE_Sign object contains an array of signature structures that has Header parameters along with signature bytes. These header parameters contain information relating to the content, as well as details about the signer performing the signature. The following describes each element of signature_structure.

protected: A CBOR Encoded protected header which is protected by the COSE signature.
unprotected: A COSE header that is not protected by the COSE signatur.
signature: A COSE signature block, as defined in .

Refer to section when setting the above parameters

Use of Header Parameters and Signatures in COSE_Sign This section provides the order in which the protected and unprotected header parameters should be set, along with an array of signature structures in a COSE_Sign object.

Single Signer, multiple signing algorithms:

The top-level protected and unprotected header parameters, as specified in , are populated first. These parameters identify the signature algorithm and the authority responsible for signing the CoRIM. The corresponding signature bytes are carried in the signature element of the first entry in the signatures array.
For each subsequent entry in the signatures array, the associated protected and unprotected header parameters identify the signing algorithm used to generate the corresponding signature. The signature bytes are carried in the signature element of that entry.

Multiple Signers

The top-level protected and unprotected header parameters, as specified in , are populated first, using the header parameter definitions provided in . These parameters identify the signing algorithm and the authority of the CoRIM creator i.e the entity responsible for signing the CoRIM. The corresponding signature bytes are carried in the signature element of the first entry in the signature-structure array.
Each subsequent entry in the signature-structure array contains the signature algorithm, signer identification information, and corresponding signature bytes associated with a distinct signing authority. Each authority independently signs the same unsigned CoRIM payload, with header parameters as defined in .

Signer authority of securely conveyed unsigned CoRIM An unsigned (#6.501-tagged) CoRIM may be a payload in an enveloping signed document (e.g., ), 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.

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) . The Collection CMW type is similar to a profile in its way of restricting the shape of the CMW collection. The Collection CMW type for a CoRIM collection SHALL be tag:ietf.org,2026:corim. A COSE_Sign1-signed CoRIM Collection CMW has a similar requirement to a signed CoRIM. The signing operation MUST include either a CWT-Claims or a corim-meta and MAY contain both, in the COSE_Sign1 protected-header parameter. These metadata containers ensure that each CoRIM in the collection has an identified signer. If using other signing envelope formats, () 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. "tag:ietf.org,2026:corim", + cmw-label => [rim-cbor-content-format, bytes .cbor tagged-unsigned-corim-map] } cmw-label = text / int ; RFC Editor: replace 65000 with the CoAP Content-Format ID assigned to ; application/rim+cbor (TBD1), here and in the example, and remove this note. rim-cbor-content-format = 65000 ]]> The Collection CMW MAY use any label for its CoRIMs. If there is a hierarchical structure to the CoRIM Collection CMW, the base entry point SHOULD be labeled 0 in CBOR or "base" in JSON. It is RECOMMENDED to label a CoRIM with its tag-id in string format, where uuid-type string format is specified by . 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:ietf.org,2026:corim:local,tag-id-tstr. It is RECOMMENDED for a corim-locator-map containing local URIs to afterwards list a nonzero number of reachable URLs as remote references. The following example demonstrates these recommendations for bundling CoRIMs with a common signer but with different profiles. >)], / profile / 3: 32("tag:example.com,2025:example-profile"), / dependent-rims / 2: [{ / href / 0: [ 32("urn:uuid:51a5f633-71c0-45f5-855e-43e8254c1806"), 32("https://example.com/369a6688451240b9b74905b1dd5fae9f.\ corim") ]}]}) >>], "51a5f633-71c0-45f5-855e-43e8254c1806": / cbor-cmw / [/ rim-cbor-content-format / 65000, << / tagged-\ unsigned-corim-map / 501({ / id / 0: h'51a5f63371c045f5855e43e8254c1806', / tags / 1: [/ tagged-concise-swid-tag / 505(<<{ / tag-id / 0: h'369a6688451240b9b74905b1dd5fae9f', / tag-version / 12: 2, / software-name / 1: "Gadget Firmware", / entity / 2: { / entity-name / 31: "ACME Firmware", / role / 33: / software-creator / 2 }}>>)], / profile / 3: 32("tag:example.com,2025:software-profile")})>>] } ]]>

Concise Module Identifier (CoMID) A CoMID tag contains information about hardware, firmware, or module composition. Each CoMID has an ID that is used to identify CoMID instances when cross referencing CoMID tags, for example in typed link relations, or in a CoTL tag. A CoMID defines several types of Claims, using "triples" semantics. At a high level, a triple is a statement that links a subject to an object via a predicate. CoMID triples typically encode assertions made by the CoRIM author about Attesting or Target Environments and their security features, for example measurements, cryptographic key material, etc. This specification defines two classes of triples, the Mandatory To Implement (MTI) and the Optional To Implement (OTI). The MTI triples are essential to basic appraisal processing as illustrated in and . 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 ().
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 ().
Conditional Endorsement triples: describing one or more conditions that, once matched, result in augmenting the Attester's actual state with the supplied Endorsed Values ().

OTI Triples:

Conditional Endorsement Series triples: describing conditional endorsements that are evaluated using a special matching algorithm ().
Device Identity triples: containing cryptographic credentials - for example, an IDevID - identifying a device ().
Attestation Key triples: containing cryptographic keys that are used to verify the integrity protection on the Evidence received from the Attester ().
Trust dependency triples: describing trust relationships between domains, i.e., collection of related environments and their measurements ().
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 ().
CoMID-CoSWID linking triples: associating a Target Environment with existing CoSWID Payload tags ().

CoMID triples are extensible (). Triples added via the extensibility feature MUST be OTI class triples. This document specifies profiles (see ). 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.

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: 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.

language (index 0): A textual language tag that conforms with IANA "Language Subtag Registry" . The context of the specified language applies to all sibling and descendant textual values, unless a descendant object has defined a different language tag. Thus, a new context is established when a descendant object redefines a new language tag. All textual values within a given context MUST be considered expressed in the specified language.
tag-identity (index 1): A tag-identity-map containing identification information for the CoMID. Described in .
entities (index 2): Provides information about one or more organizations responsible for producing the CoMID tag. Described in .
linked-tags (index 3): A list of one or more linked-tag-map providing typed relationships between this and other CoMIDs. Described in .
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 .

Tag Identity $tag-id-type-choice ? &(tag-version: 1) => tag-version-type } ]]> The following describes each member of the tag-identity-map.

tag-id (index 0): An identifier for the CoMID. Described in .
tag-version (index 1): Optional versioning information for the tag-id. Described in .

Tag ID A Tag ID is either a 16-byte binary string, or a textual identifier referencing the CoMID. The tag identifier MUST be a Collision-Resistant Name (see ). Failure to ensure collision resistance can create ambiguity in tag use since the tag-id serves as the global key for matching, lookups and linking. If represented as a 16-byte binary string, the identifier MUST be a valid universally unique identifier as defined by , and SHOULD follow the local uniqueness guidance of . There are no strict guidelines on how the identifier is structured, but examples include a 16-byte GUID (e.g., class 4 UUID) , or a URI , for example urn:example:widget:firmware:1.0.0.

Tag Version 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.

Entities ]]> The CoMID Entity is an instantiation of entity-map () using a $comid-role-type-choice. The $$comid-entity-map-extension extension socket is empty in this specification. 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.

Linked Tag The linked tag map represents a typed relationship between the embedding CoMID tag (the source) and another CoMID tag (the target). $tag-id-type-choice &(tag-rel: 1) => $tag-rel-type-choice } ]]> The following describes each member of the linked-tag-map.

linked-tag-id (index 0): Identifier for the target tag. See .
tag-rel (index 1): the kind of relation linking the source tag to the target identified by linked-tag-id.

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.

Triples The triples-map contains all the CoMID triples broken down per category. Not all categories need to be present but at least one category MUST be present and contain at least one entry. In most cases, the supply chain entity that is responsible for providing a triple (i.e., Reference Values or Endorsed Values) is by default the CoRIM signer. The signer of a triple is said to be its authority. However, multiple authorities may be involved in signing triples. See . Consequently, authority may differ for search criteria. See . [ + 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 .
endorsed-triples (index 1): Triples containing endorsed values. Described in .
identity-triples (index 2): Triples containing identity credentials. Described in .
attest-key-triples (index 3): Triples containing verification keys associated with attesting environments. Described in .
dependency-triples (index 4): Triples describing trust relationships between domains. Described in .
membership-triples (index 5): Triples describing topological relationships between (sub-)modules. Described in .
coswid-triples (index 6): Triples associating modules with existing CoSWID tags. Described in .
conditional-endorsement-series-triples (index 8): Triples describing a series of Endorsements that are applicable based on the acceptance of a condition. Described in .
conditional-endorsement-triples (index 10): Triples describing a series of conditional Endorsements based on the acceptance of a stateful environment. Described in .

Environments An environment-map may be used to represent a whole Attester, an Attesting Environment, or a Target Environment. The exact semantic depends on the context (triple) in which the environment is used. An environment is named after a class, instance or group identifier (or a combination thereof). An environment MUST be identified by a Collision-Resistant Name (see ). The combination of values within class-map MUST combine to form a Collision-Resistant Name. 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 .
instance (index 1): Contains an identifier of a module's instance. Described in .
group (index 2): identifier for a group of instances, e.g., if an anonymization scheme is used. Described in .

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. $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 () 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.

Environment Instance An instance-id identifies a Target Environment instance. The identifier is reliably bound to the Target Environment. For example, if an X.509 certificate's subject public key is unique for each instance of a target environment, the instance-id might be created from that subject public key. See . 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 . The key identifier is reliably bound to the subject public key because the identifier is a digest of the key. The types defined for an instance identifier are CBOR tagged expressions of UEID, UUID, variable-length opaque byte string (), cryptographic keys, or cryptographic key identifiers.

Environment Group A group carries an identifier that is reliably bound to a group of Attesters, for example when a number of Attesters are hidden in the same anonymity set. The types defined for a group identifier are UUID and variable-length opaque byte string ().

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. 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. $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 . A measurement-map without an mkey is said to be anonymous.
mval (index 1): The measurements associated with the environment. Described in .
authorized-by (index 2): Identifies the authority, an individual or organization, under whose control an entity asserts Claims. The authority is represented using $crypto-key-type-choice (see ), which binds the Claim to a specific cryptographic identity. The authorized-by element participates in the matching and augmentation process defined in , where it provides the conditions under which a Claim is applicable.

Measurement Keys A Measurement Key is an identifier for a measured element. It can be used to identify the type of measured element (see ), or to index an SPDM measurements block originating from a specific target environment, or to identify multiple measured element instances within the same environment. The initial types defined are OID, UUID, uint, and tstr.

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. version-map ? &(svn: 1) => svn-type-choice ? &(digests: 2) => digests-type ? &(flags: 3) => flags-map ? ( &(raw-value: 4) => $raw-value-type-choice, ? &(raw-value-mask-DEPRECATED: 5) => raw-value-mask-type ) ? &(mac-addr: 6) => mac-addr-type-choice ? &(ip-addr: 7) => ip-addr-type-choice ? &(serial-number: 8) => text ? &(ueid: 9) => ueid-type ? &(uuid: 10) => uuid-type ? &(name: 11) => text ? &(cryptokeys: 13) => [ + $crypto-key-type-choice ] ? &(integrity-registers: 14) => integrity-registers ? &(int-range: 15) => int-range-type-choice ? &(bool: 16) => bool-matcher ? &(integer: 17) => integer-matcher ? &(text: 18) => text-matcher ? &(bytes: 19) => bytes-matcher ? &(float: 20) => float-matcher * $$measurement-values-map-extension }> ]]> The following describes each member of the measurement-values-map.

version (index 0): Typically changes whenever the measured environment is updated. Described in .
svn (index 1): The security version number typically changes only when a security relevant change is made to the measured environment. Described in .
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 .
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 .
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 .
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 associated with the measured environment. Described in .
ip-addr (index 7): An IPv4 or IPv6 address associated with the measured environment. Described in .
serial-number (index 8): A text string representing the product serial number.
ueid (index 9): UEID associated with the measured environment. Described in .
uuid (index 10): UUID associated with the measured environment. Described in .
name (index 11): a name associated with the measured environment.
cryptokeys (index 13): identifies cryptographic keys that are protected by the Target Environment See 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 .
integrity-registers (index 14): A group of one or more named measurements associated with the environment. Described in .
int-range (index 15): An integer value or an inclusive integer range that can be compared with linear order. Described in . Comparison rules are defined in .
bool (index 16): A boolean value, compared for exact match. Described in . Comparison rules are defined in .
integer (index 17): An integer value with configurable matching semantics, including range and set matching. Described in . Comparison rules are defined in .
text (index 18): A text string with configurable matching semantics. Described in . Comparison rules are defined in .
bytes (index 19): A byte string with configurable matching semantics. Described in . Comparison rules are defined in .
float (index 20): A floating-point value with configurable matching semantics, including range and set matching. Described in . Comparison rules are defined in .

Version A version-map contains details about the versioning of a measured environment. 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 and extended with the binary scheme described in . When the value of the version-scheme is binary, the value of the version field is encoded as base64url (), without padding. The CDDL (including the new binary version scheme) is copied below for convenience.

Security Version Number The following details the security version number (svn) and the minimum security version number (min-svn) statements. A security version number is used to track changes to an object (e.g., a secure enclave, a boot loader executable, a configuration file, etc.) that are security relevant. Rollback of a security relevant change is considered to be an attack vector; as such, security version numbers cannot be decremented. If a security relevant flaw is discovered in the Target Environment and is subsequently fixed, the svn value is typically incremented. There may be several revisions to a Target Environment that are in use at the same time. If there are multiple revisions with different svn values, the revision with a lower svn value may or may not be in a security critical condition. The Endorser may provide a minimum security version number using min-svn to specify the lowest svn value that is acceptable. svn values that are equal to or greater than min-svn do not signal a security critical condition. svn values that are below min-svn are in a security critical condition that is unsafe for normal use. The svn-type-choice measurement consists of a tagged-svn or tagged-min-svn value. The tagged-svn and tagged-min-svn tags are CBOR tags with the values #6.552 and #6.553 respectively.

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. bool ? &(is-secure: 1) => bool ? &(is-recovery: 2) => bool ? &(is-debug: 3) => bool ? &(is-replay-protected: 4) => bool ? &(is-integrity-protected: 5) => bool ? &(is-runtime-meas: 6) => bool ? &(is-immutable: 7) => bool ? &(is-tcb: 8) => bool ? &(is-confidentiality-protected: 9) => bool ? &(is-runtime-updatable: 10) => bool * $$flags-map-extension }> ]]> The following describes each member of the flags-map:

is-configured (index 0): If the flag is true, the measured environment is fully configured for normal operation.
is-secure (index 1): If the flag is true, the measured environment's configurable security settings are fully enabled.
is-recovery (index 2): If the flag is true, the measured environment is in recovery mode.
is-debug (index 3): If the flag is true, the measured environment is in a debug enabled mode.
is-replay-protected (index 4): If the flag is true, the measured environment is protected from rollback to previous software images.
is-integrity-protected (index 5): If the flag is true, the measured environment is protected from unauthorized update.
is-runtime-meas (index 6): If the flag is true, the measured environment is measured after being loaded into memory.
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.

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 (). Additional value types can be added to $raw-value-type-choice. These additional values MUST be CBOR tagged bstrs. Constraining all raw value types to be bstr lets Verifiers compare raw values without understanding their contents. A raw value intended for comparison can include a mask value, which selects the bits to compare during appraisal. The mask is applied by the Verifier as part of appraisal. Only the raw value bits with corresponding TRUE mask bits are compared during appraisal. The raw-value-mask-DEPRECATED in measurement-values-map is deprecated, but retained for backwards compatibility. This code point may be removed in a future revision of this specification.

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 with the CBOR tag removed. All the types represent a single address.

Crypto Keys A cryptographic key can be one of the following formats:

tagged-pkix-base64-key-type: PEM encoded SubjectPublicKeyInfo. Defined in .
tagged-pkix-base64-cert-type: PEM encoded X.509 public key certificate. Defined in .
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 .
tagged-pkix-asn1der-cert-type: a bstr of ASN.1 DER encoded X.509 public key certificate. Defined in .

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.

Integrity Registers An Integrity Registers map groups together one or more measured "objects". Each measured object has an identifier and one or more associated digests. Identifiers are either unsigned integers or text strings and their type matters, e.g., unsigned integer 5 is distinct from the text string "5". The digests use digests-type semantics (). 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: then both and 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.

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. The signed integer range representation is an inclusive range. A min or max of null means that the range is effectively unbounded in that direction. At least one of min and max MUST be non-null; to match any value, the entry is omitted. If both min and max are integers, min MUST be less than or equal to max. An int-range that violates either requirement is malformed, and the tag that contains it MUST be discarded (see ).

Type Matchers The measurement-values-map entries at indices 16-20 support generic boolean, integer, text, byte-string, and floating-point measurements. For the integer, float, text and byte-string entries, matching semantics are configurable: rather than adding a separate codepoint for each desired matching criterion, these entries use CBOR-tagged wrappers to encode the matching logic alongside the value:

Bare (untagged) value means exact match: the target value must equal the entry's value.
CBOR tag 566 (tagged-*-set, integer, float, text and byte-string types only) means set match: the target value must equal one of the values in the array; at least two alternatives MUST be provided.
CBOR tag 565 (tagged-integer-range and tagged-float-range, numeric types only) means range match: the target value must lie within the inclusive [min, max] interval; null means unbounded.

If both min and max of a tagged-integer-range or tagged-float-range are non-null, min MUST be less than or equal to max. A tagged-integer-range or tagged-float-range that violates this requirement is malformed, and the tag that contains it MUST be discarded (see ). The boolean entry (index 16) supports only exact match; see for why this is the case. The numeric type of a value is determined by the codepoint at which it appears: integer (index 17) holds int values and float (index 20) holds float values. Values at different codepoints are never compared with each other, so an integer condition never matches a float ACS-ECT value, and vice versa, even when they denote the same number. An Evidence transformation algorithm, or the CoRIM profile that defines it, MUST specify the codepoint to which each numeric value it produces is assigned. The range and set forms are meaningful only as a condition, when the measurement-values-map entry appears in a C-ECT. measurement-values-map is also used, unmodified, for ACS-ECTs (the values asserted by Evidence, Reference Values and Endorsements); the CDDL does not by itself distinguish the two uses. An ACS-ECT entry at codepoints 16-20 MUST use the bare, untagged form. The range and set forms MUST NOT be used outside a condition. The comparison rules in , , , and are accordingly defined only for C-ECT values of these codepoints, compared against a bare ACS-ECT value. Because these entries carry no inherent meaning beyond their primitive type and matching criterion, a profile using them MUST define what measured attribute each entry represents, the unit or encoding of the value, and any constraints on acceptable values beyond what the matcher already expresses.

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:

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 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 . 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.

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 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 an endorsed-triple-record, its condition is compared with existing Evidence, corroborated Evidence, and Endorsements. If the search criterion is satisfied, the endorsement is added to the Attester's actual state under the Endorser's authority.

Conditional Endorsement Triple Conditional Endorsement Triples declare one or more conditions that, once matched, results in augmenting the Attester's actual state with the Endorsement Claims. The conditions are expressed via stateful-environment-records, which match Target Environments from Evidence in certain reference state. The Conditional Endorsement Triple has the following structure:

Conditional Endorsement Triple 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.

Conditional Endorsement Series Triple The Conditional Endorsement Series Triple is used when an Endorser wants to match Claims of the same type (for example version) but with differing values. If the conditions are met, new Claims are added as Endorsements. For example, if version 1.0 of a component has a Common Vulnerability and Exposure (CVE), but version 2.0 does not, a series condition might contain version = "1.0" and an addition cve = "CVE_PLACEHOLDER". Another series condition might contain version = "2.0" and an addition cve = "CVE_NONE". As soon as the condition value is matched the remaining conditions can be ignored. The Conditional Endorsement Series Triple has two forms of conditions, those that are common to all series list items and those that are specific to a particular item in the series. The common conditions are separated out of the series list for convenience. The Conditional Endorsement Series Triple has the following structure:

Conditional Endorsement Series Triple 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.

Matching Considerations For consistent results, every series item condition MUST use the same measurement types; differing only in terms of measurement values. This requirement also extends to use of mkey in measurement-map. Series entries are ordered such that the most precise match is evaluated first and least precise match is evaluated last. The first series condition that matches terminates series matching and the endorsement values are added to the Attester's actual state. These restrictions ensure that evaluation order does not change the meaning of the triple during the appraisal process. Note: authorized-by in common-condition takes precedence over the authorized-by in condition.

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 . 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.

Device Identity Triple Definition $measured-element-type-choice, ? &(authorized-by: 1) => [ + $crypto-key-type-choice ] }> ] ]]>

environment: An environment-map condition used to identify the target Evidence or Reference Value. See .
key-list: A list of $crypto-key-type-choice keys that identifies which keys are to be verified. See .
mkey: An optional $measured-element-type-choice condition used to identify the element within the target Evidence or Reference Value. See .
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.

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 . 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 . Each successful verification of a key in key-list SHALL produce Endorsement Claims that are added to the Attester's Claim set. Claims are asserted with the joint authority of the Endorser (CoRIM signer) and the Verifier. The Verifier MAY report key verification results as part of an error reporting function.

Attest Key Triple Definition $measured-element-type-choice, ? &(authorized-by: 1) => [ + $crypto-key-type-choice ] }> ] ]]> See for additional details.

Triples for domain definition Domain triples assert a graphical description of Attester composition in terms of its constituent Environments and their compositional relationships. The following CDDL describes domain type. Domain structure is defined in terms of directed acyclic graphs (DAG) describing membership and trust dependency using the following types of triples.

Domain Membership Triple A Domain Membership Triple (DMT) links a domain identifier to its member Environments. The triple's subject is the domain identifier while the triple's object lists all the member Environments within the domain. The Domain Membership Triple allows an Endorser (for example, an Integrator) to issue an authoritative statement about the composition of an Attester as a collection of Environments. This allows a topological description of an Attester to be expressed by linking a parent Environment (e.g., a lead Attester) to its child Environments (e.g., one or more sub-Attesters). If the Verifier Appraisal policy requires Domain Membership, the Domain Membership Triple is used to match an Attester's reference composition with the actual composition represented in Evidence. Representing members of a DMT as domains enables the recursive construction of an entity's topology, such as a Composite Device (see ), where multiple lower-level domains can be aggregated into a higher-level domain. The domain topology MUST be acyclic.

Domain Membership Triple Definition Domain membership triples are transformed into an internal representation (see ) then processed as described in .

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 ) might not determine whether a component is trustworthy. Subsequent Verifier stages or Relying Party processing might be needed to finalize trustworthiness. Therefore, the trustworthiness of trustee domains MUST be appraised before the trustworthiness of the subject domain can be finalized. Consequently, trust dependency semantics may need to be represented in Attestation Results if Relying Parties play a role in finalizing which components are trustworthy. There are a variety of use cases where trust dependency might exist. For example, trust in an operating system (OS) might depend on trustworthy loading of the OS loader image. Consequently, the OS loader is a trustee domain of the OS. Alternatively, trust in a peripheral device might depend on trustworthy operation of a peripheral device's bus controller. The bus controller is therefore a trustee domain of the peripheral device. TDTs cannot instantiate domains. Instead, TDT processing first verifies that a domain-id has already been accepted into the ACS before adding any trust-dependency triples. Environments that have been accepted into the ACS are automatically considered Domains. Consequently, TDTs may describe trust-dependency semantics for any Environment that has been accepted into the ACS. The trust dependency triple subject (domain-id) identifies the member domain (see ) 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 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.
A trustee is a component embedded within another component identified by domain-id.

Trust dependency triples are transformed into an internal representation (see ) then processed as described in .

CoMID-CoSWID Linking Triple A CoSWID triple relates reference measurements contained in one or more CoSWIDs to a Target Environment. The subject identifies a Target Environment, the object one or more tag identifiers of existing CoSWIDs, and the predicate asserts that these contain the expected (i.e., reference) measurements for the Target Environment.

CoMID-CoSWID Linking Triple Definition

Extensibility The base CoRIM document definition is described using CDDL that can be extended only at specific allowed points known as "extension points". The following types of extensions are supported in CoRIM.

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 . Non-negative integers are reserved for IANA to assign meaning globally.

Data Type Extensions Data type extensibility has the form ($NAME-type-choice) where "NAME" is the type name and '$' signifies type extensibility. New data type extensions SHOULD be documented to facilitate interoperability. CoRIM profiles are best used to document vendor or industry defined extensions.

CoTL A Concise Tag List (CoTL) object represents the signal for the Verifier to activate the listed tags. Verifier policy determines whether CoTLs are required. When CoTLs are required, each tag MUST be activated by a CoTL before being processed. All the tags listed in the CoTL MUST be activated atomically. If any tag activated by a CoTL is not available to the Verifier, the entire CoTL is rejected. The number of CoTLs required in a given supply chain ecosystem is dependent on Verifier Owner's Appraisal Policy for Evidence. Corresponding policies are often driven by the complexity and nature of the use case. If a Verifier Owner has a policy that does not require CoTL, tags within a CoRIM received by a Verifier are activated immediately and treated as valid for appraisal. There may be cases when the Verifier receives CoRIMs from multiple Reference Value providers and Endorsers. In such cases, a supplier (or other authorities, such as integrators) may be designated to issue a single CoTL to activate all the tags submitted to the Verifier in these CoRIMs. 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.

Structure The CDDL specification for the concise-tl-tag map is as follows, and this rule and the additional grammatical requirements specified in the text of this Section MUST be followed when creating or validating a CoTL tag: tag-identity-map &(tags-list: 1) => [ + tag-identity-map ], &(tl-validity: 2) => validity-map } ]]> The following describes each member of the concise-tl-tag map.

tag-identity (index 0): A tag-identity-map containing identification information for the CoTL. Described in .
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 .

Common Types The following CDDL types may be shared by CoRIM, CoMID, and CoTL.

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. = (M) .and ({ + any => any }) ]]>

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-name: 0) => $entity-name-type-choice ? &(reg-id: 1) => uri &(role: 2) => [ + role-type-choice ] * extension-socket } $entity-name-type-choice /= text ]]> The following describes each member of the entity-map.

entity-name (index 0): The name of entity which is responsible for the action(s) as defined by the role. $entity-name-type-choice can only be text. Other specifications can extend the $entity-name-type-choice. See .
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 () and ().

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 . 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

UUID Used to tag a byte string as a binary UUID. Defined in .

UEID Used to tag a byte string as Universal Entity ID Claim (UEID). Defined in .

OID Used to tag a byte string as the BER encoding of an absolute object identifier .

Digest A digest represents the value of a hashing operation together with the hash algorithm used. This specification reuses the digest type defined in . Only the CBOR serialization is used. 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.

Tagged Bytes Type An opaque, variable-length byte string. It can be used in different contexts: as an instance, class or group identifier in an environment-map; as a raw value measurement in a measurement-values-map. Its semantics are defined by the context in which it is found, and by the overarching CoRIM profile. When used as an identifier, the value MUST be a Collision-Resistant Name (see ); the responsible allocator entity is responsible for ensuring this property holds within the context in which the identifier is used.

Reference Verifier This section outlines the behavior of a "CoRIM processor" within the Evidence appraisal procedure carried out by the RATS Verifier (). 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 .

Pseudocode Notation The algorithms in pseudocode are meant for readability and not for execution. The following pseudocode notation is used throughout this document.

Comments A comment begins with "//" and extends to the end of the line.

Types Pseudocode Type names are taken directly from the CDDL . There is no separate type language; type annotations on function parameters, return values, and variable bindings reuse CDDL type expressions verbatim. A reader familiar with the CDDL schemas in this document can read the algorithms without any additional type translation. A bare name refers to a CDDL rule: The CDDL notation "[ + T ]" denotes a non-empty array of elements of type T: An extensible CDDL socket type is prefixed with "$": The CDDL "/" operator separates the alternatives of a union type:

Variables A variable is introduced and assigned a value using the ":=" operator: A previously introduced variable or a field of a structured value is updated using "=":

Functions A function is introduced by the FUNC keyword, followed by its name, a parenthesized parameter list with CDDL type annotations, and a return type: return-type { ... } ]]> A RETURN statement exits the enclosing function and yields the specified value to the caller: A FAIL statement immediately aborts the enclosing top-level FUNC without yielding a value, signaling to the caller that the operation did not complete successfully:

Expressions The TYPEOF operator yields the CDDL type of a value at runtime. Used with "==", it dispatches on the alternatives of a CDDL union type: The "~" prefix operator unwraps a CBOR-tagged value to its untagged content, corresponding to the CDDL unwrap idiom:

Conditionals An IF statement tests a condition and executes its body if the condition is true. One or more ELIF clauses test additional conditions in order. An optional ELSE clause provides a fallback:

Iteration A FOREACH statement iterates over the elements of a collection in order: A BREAK statement exits the innermost enclosing FOREACH immediately.

Primitive Operations The pseudocode uses a "Receiver::OPERATION(args)" calling convention to invoke well-known operations on typed values. All operation names are uppercase. Primitive Operations

Operation	Meaning
`T::NEW()`	Construct a new zero-value instance of CDDL type T
`collection::APPEND(item)`	Append item to a collection; when item is itself a list, all its elements are appended
`acs::MATCH(condition)`	Test whether condition matches any entry in the ACS; the matching rules are relation-specific and defined in
`acs::APPEND(addition)`	Attempt to atomically append addition to the ACS; returns TRUE on success, or FALSE (leaving the ACS unchanged) if the relation-specific pre-condition on addition or post-condition on the resulting ACS, both defined in , is not satisfied
`x::MEMBEROF(collection)`	Test whether x is a member of collection
`INDEXOF(x)`	Return the position of x within its enclosing sequence

Appraisal Logical Phases For clarity, the appraisal procedure is divided into several logical phases. Phase 1: Input Validation and Transformation. During this phase, all available Conceptual Messages are processed for validation. This involves checking digital signatures to verify their integrity and authenticity, ensuring they are not outdated and confirming their relevance to the current appraisal. If validation fails, the input Conceptual Message is discarded. If validation succeeds, the Conceptual Message is transformed from its external representation into an internal one. These internal representations are then collected in an implementation-specific "staging area", which acts as a database for subsequent appraisal processing. Phase 2: Evidence Augmentation. During this phase, Evidence Claims are added to a structure describing the Attester's actual state, known as the ACS. These Claims are added to the ACS with Attester Authority. Phase 3: Reference Values Corroboration and Augmentation. During this phase, Reference Value Claims are compared with Evidence Claims from the ACS. Reference Value Claims describe the possible states of the Attester. If the Attester's actual state, as described in the ACS, is one of these possible states, the Attester's actual state is said to be "corroborated". These Claims are added to the ACS with the Authority of the Reference Value Provider. Phase 4: Endorsed Values Augmentation. During this phase, Endorsed Values inputs containing conditions that describe the expected state of the Attester are processed. If the conditions are met, additional Claims about the Attester are added to the ACS. These Claims are added with the Endorser's Authority. Subsequent Phases: Before producing an Attestation Result, a Verifier may undergo subsequent phases of the appraisal procedure. For example, the Verifier may perform consistency, integrity or additional validity checks. These checks may result in additional Claims about the Attester being added to the ACS. These Claims are added with the Verifier's Authority. Typically, a Verifier applies Appraisal Policy for Evidence on the ACS that describes desirable or undesirable Attester states. If these conditions are met, the policy 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 ). 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 describes the handoff interface between Phase 4 and the subsequent phases in terms of the computed ACS.

The CoRIM Processor This document assumes that Verifier implementations will differ. In order to describe normative Verifier behavior, this section presents a reference Verifier and illustrates how the data is utilized within the appraisal phases detailed in . If the Verifier operates on CoRIM documents, it is RECOMMENDED that it follows this algorithm.

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. illustrates how the CoRIM processor fits into the wider RATS Verifier architecture.

CoRIM Processing Flow | | ECT | +---->| | | | | | | '-----' | | ACS | | | | | | ... | | Match & | | | | | | .-----. | | Augment | | | | | | | ECT | |<----+ | | | | | | '-----' | '---------' | | | | | ACS | | | | | '----+----' | | | | | | | | '------+-----------------------------' | .----------------. | v | | Appraisal | | .-----------------. .-------------. | | Policy for +---->| Subsequent Phases +--->| Attestation +-----> | Evidence | | '-----------------' | Results | | '----------------' | '-------------' | '------------------------------------------' Legend: .-------. .------. ACS = Appraisal Claims Set | Process | | Data | ECT = Environment-Claims Tuple '-------' '------' Int Rep = Internal Representation ]]> 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 . Before the appraisal can begin, all Conceptual Messages must be broken down and reshaped into a common internal representation. The internal representations of Reference Values and Endorsements are stored in a staging area prior to appraisal initiation. In contrast, the internal 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.

Data Structures This section describes the data structures used by the CoRIM processor.

ECT The Environment-Claim Tuple is a core internal construct of the CoRIM Verifier. It is used to describe a feature (or "Claim") of the appraised environment alongside relevant metadata. All ECTs, except those containing Evidence Claims, are typically obtained from CoMID triples. Claims in ECTs have both a name and a value. The value represents the state associated with the Claim. This specification does not assign any special meaning to Claim names; it only specifies the rules for determining whether two Claim names are the same. An ECT () can be one of the following specializations:

E-ECT (Element ECT): used to represent Evidence, Reference Value and Endorsement Claims, as detailed in ;
M-ECT (Domain Membership ECT): used to represent domain membership Claims, as detailed in ;
T-ECT (Trust Dependency ECT): used to represent trust dependency Claims, as detailed in ;
K-ECT (Key ECT): used to represent Identity and Attestation keys, as detailed in .

ECT definition While the internal representation of each specialization varies, all ECT specializations share the attributes captured in the ECT-common group ().

ECT common attributes

environment: Identifies the Environment that is the subject of the stated Claims. In an Element ECT, it is the target environment to which the elements belong. In a Domain ECT, it is the parent environment to which the child domains are related. In a Key ECT, it is the environment to which the keys belong. In all cases, Environments are identified using instance, class, or group identifiers.
authority: Identifies the entity that issued the tuple. The authority of a given ECT is typically established through a digital signature on the Claim. For instance, a signature of the authoritative supply chain entity over the CoRIM containing the triple from which the ECT was obtained, or the Attesting Environment that signed the Evidence from which the ECT is derived. It is represented as the key material by which the authority (and corresponding provenance) of the tuple can be determined. A typical example is the authority's PKIX certificate. This attribute is mandatory in an addition ECT, and therefore in every ECT held in the ACS. ECT-common () itself defines authority as optional because it is also the basis for condition ECTs, and not every relation uses authority as a matching criterion.
profile: The profile that defines the domain of interpretation of this tuple. This is the profile attribute of the CoRIM that contained the original triple from which this ECT was obtained. This is an optional attribute in an ECT. If no profile is used, the attribute is omitted, and the only comparison rules that apply are those specified in .

Element ECT An Element ECT (E-ECT) is used to represent Evidence, Reference Value and Endorsement Claims.

Element ECT The following describes the specialized members of the E-ECT.

element-list: Identifies the set of elements contained within a Target Environment and their trustworthiness Claims, each described by an element-map. An element-map is very similar to a measurement-map, with the element-id and element-claims corresponding to the mkey and mval, respectively. The pseudocode in 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).

Transform Measurement Map(s) into Element Map(s) 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 } ]]> 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.

Domain Membership ECT A Domain Membership ECT (M-ECT) is used to represent domain membership Claims between environments. It describes the direct relationship between a specific node in the membership (i.e., the parent environment) and the members nodes that comprise the domain.

Domain Membership ECT The following describes the specialized members of the M-ECT.

members: Identifies the set of members of the domain rooted in the parent environment.

A Domain Claim specifies the type of relationship that the parent domain is expected to have with its child environments. In a Domain ECT, the environment attribute encodes the name of the Claim. The value of the Claim is encoded in the members attribute. Merge Rules. If two Domain ECTs have the same environment, authority and profile then their members are merged. Any duplicates MUST be pruned.

Trust Dependency ECT A Trust Dependency ECT (T-ECT) is used to represent trust dependency Claims between environments. It describes the direct relationship between a specific node in the trust domain (i.e., the parent environment) and the trustees nodes that comprise the trust chain.

Trust Dependency ECT The following describes the specialized members of the T-ECT.

trustees: Identifies the set of environments that becomes a part of a trust chain to the parent environment.

A Trust Claim specifies the type of relationship that the parent domain is expected to have with its trustee environments. In a Trust ECT, the environment attribute encodes the name of the Claim. The value of the Claim is encoded in the trustees attribute. Merge Rules. If two Trust ECTs have the same environment, authority and profile then their trustees are merged. Any duplicates MUST be pruned.

Key ECT A Key ECT (K-ECT) is used to represent Identity and Attestation keys.

Key ECT The following describes the specialized members of the K-ECT.

key-id: Identifies a specific namespace within environment that the keys in key-list are associated with.
key-list: Identifies the set of keys associated with environment and (optionally) key-id.
key-type: Either attest-key or identity-key, depending on the triple that originated this K-ECT instance.

Claim Names. A Key Claim specifies one or more keys associated with the environment, as well as the semantics of these keys. In a Key ECT, the environment, key-type and optional key-id attributes encode the name of the Claim. The value of the Claim is encoded in the key-list attribute. Merge Rules. No merge rules are specified for a Key ECT.

Internal Representation This section describes how the relevant RATS Conceptual Messages are represented within the CoRIM processor. This internal representation is based on the concept of "relations", which in turn are based on ECTs. Typically, a relation is structured as a "condition" ECT that specifies the matching criteria used to compare entries in the ACS, along with an "addition" ECT that is appended to the ACS if the specified conditions are met. While this is the common structure, some relations may differ slightly from the condition/addition pattern. This is because they either do not require a condition (e.g., Evidence) or they require more sophisticated matching criteria that cannot be expressed solely via a condition (e.g., Conditional Endorsement Series).

Evidence The internal representation of Evidence uses the ae relation.

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. shows the profiled ECT for an ae item.

Profiled ECT for Evidence All E-ECT attributes are mandatory, except profile.

Reference Values The internal representation of Reference Values uses the rv relation where each rv-item corresponds to a reference-triple-record.

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 for how the rv entries are processed. shows the profiled Element ECT for a Reference Values condition.

Profiled ECT for Reference Values (condition) shows the profiled Element ECT for a Reference Values addition.

Profiled ECT for Reference Values (addition) As this is used to corroborate an Evidence ECT, its layout is identical to that of an Evidence-addition-ECT. The only differences are the values of the element-list, authority and cmtype attributes. 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.

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 () applies to Endorsed Values (EV) and Conditional Endorsement (CE) triples.

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 () applies to Conditional Endorsement Series (CES) Triples.

Endorsed Values Series Relation The evs relation contains a list of series items. Each series item contains a list of condition ECTs and a list of addition ECTs. The condition ECTs are compared with the ACS. If the condition criteria are satisfied, the addition ECTs are added to the ACS and the series evaluation ends. If the condition criteria are not satisfied, evaluation proceeds to the next series item. shows the profiled Element ECT for an Endorsed Value condition.

Profiled condition ECT for ev and evs relations shows the profiled Element ECT for an Endorsed Value addition.

Profiled addition ECT for ev and evs relations

Keys The internal representation of Attest Key and Device Identity triples uses the keys relation (), whereby each key-item corresponds to either an attest-key-triple-record or an identity-triple-record.

Keys Relation If key-item is used to transform Evidence, key-item.condition is omitted since Evidence addition is unconditional. Nevertheless, key-item.addition is merely staged for addition pending successful key verification checks.

Domain Memberships The internal representation of Domain Membership uses the dm relation (), whereby each domain-item corresponds to a domain-membership-triple-record.

Domain Membership Relation

Domain Item shows the profiled Domain ECT for Domain Membership conditions.

Profiled ECT for Domain Membership (condition) Only the members are used for matching, not the environment. Therefore, the environment attribute is excluded from the ECT condition. shows the profiled Domain ECT for Domain Membership additions.

Profiled ECT for Domain Membership (addition)

Trust Dependencies The internal representation of Trust Dependency uses the td relation (), whereby each td-item corresponds to a trust-dependency-triple-record.

Trust Dependency Relation

Trust Dependency Item shows the profiled T-ECT for Trust Dependency conditions.

Profiled ECT for Trust Dependency (condition) Both the trustees and environment are used for matching. shows the profiled T-ECT for Trust Dependency additions.

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 . Please note that a subsequent Appraisal Policy for Evidence may decide not to produce Attestation Results in this case. A trust dependency relation is added to the ACS if the environment and all trustees exist in the membership graph expressed by the dm relation () in the ACS.

ACS The ACS () 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 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 ) implemented by the CoRIM processor. Once the staging area has been drained by the CoRIM processor, processing stops and the computed ACS is handed over to subsequent phases. In this way, the ACS represents the CoRIM processor's output interface. The order of the ECTs in the ACS is not significant. Logically, as the ACS represents the conjunction of all claims, adding an ECT entry to the existing ACS at the end has the same effect as inserting it anywhere else.

Staging Area The staging area () is a list of the relations corresponding to the transformed triples.

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.

Input Validation and Transformation (Phase 1) This section provides a detailed description of Phase 1, which was outlined at a high level in , 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 ); CoSWID tags (see ); CoTL tags (see ); cryptographic validation key material (including raw public keys, root certificates and intermediate CA certificate chains); and Concise Trust Anchor Stores (CoTS) (see ) 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.

CoRIM Selection All available CoRIM tags are collected. CoRIM tags MUST be discarded if they have expired, or if they are not associated with an authenticated and authorized source, or if they have been revoked by an authorized source. Any CoRIM secured by a cryptographic mechanism that fails validation MUST be discarded. If the Verifier fetches a resource identified by a corim-locator-map () that includes a thumbprint, it MUST check the fetched resource against thumbprint following the rules in , with the digests computed over the fetched resource in place of the ACS-ECT digests. If that check fails, the Verifier MUST NOT use the fetched resource. Other selection criteria MAY be applied. For example, if the Evidence format is known in advance, CoRIMs using a profile that is not understood by a Verifier can be readily discarded. Further selection criteria may be applied to the CoRIM contents at later stages.

CoRIM Trust Anchors If CoRIM tags are signed, the signatures MUST be verified using the appropriate trust anchors available to the Verifier. The Verifier is expected to have a trust anchor store. The way in which these trust anchors are provisioned in the Verifier is beyond the scope of this specification. If the CoRIM is signed, it should include at least one certificate (e.g., as part of the x5chain in the COSE header) that corresponds to the key pair used for signing. This certificate MUST have a valid certification path to one of the Verifier's trust anchors. If the CoRIM is signed by multiple authorities, at least the signature from the CoRIM creator MUST be verified before the CoRIM can be accepted for further processing by the Verifier. A Verifier Appraisal Policy for Evidence may require more signatures to be verified before accepting the CoRIM. For each of these signers, it is expected that the corresponding trust anchors will be provisioned in the Verifier. The way in which these trust anchors are provisioned in the Verifier is beyond the scope of this specification.

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 .

CoTL Extraction (This section is not applicable if the Verifier appraisal policy does not require CoTLs.) CoTLs that are outside their validity period MUST be discarded. The Verifier processes all CoTLs that are valid at the time of Evidence appraisal and activates all referenced tags. Depending on any locally configured authorization policies, the Verifier MAY decide to discard some of the available and valid CoTLs. Such policies model the trust relationships between the Verifier Owner and the relevant suppliers, and are out of the scope of the present document. For example, a composite device (see ) 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.

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 ), making it suitable for appraisal processing. The exact protocol used to collect Evidence is out of scope of this specification.

Cryptographic Validation of Evidence If Evidence is cryptographically signed, it is validated before being transformed into an internal representation. If Evidence is not cryptographically signed, the conveyance protocol used to collect it MUST provide the required security. In such cases, the cryptographic validation of Evidence depends on the security offered by the conveyance protocol. 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 . If a trusted root certificate is found, X.509 certificate validation is performed. As a second example, the verification public key used to verify 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.

Input Transformation This section describes how the relevant RATS Conceptual Messages are transformed upon ingestion by the CoRIM processor.

Evidence Evidence transformation involves mapping Evidence into one or more Evidence-ECTs (see ), and adding them to the addition list of an ae relation. Evidence transformation algorithms may be well-known (e.g., ), defined by a CoRIM profile (see ), 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.

Reference Values Reference Values transformation involves mapping Reference Value triples into an rv relation (see ). Each reference-triple-record () is transformed into an rv-item () as described in . (The code reuses the mms_to_ems function from .)

Reference Value Triple Transformation 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 } ]]> Note that the ref-claims are not copied to the addition ECT. Since they may contain ranges rather than individual values (see, for example, ), 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.

Endorsed Values Endorsed Values transformation involves mapping EV, CE and CES triples into ev or evs relations (see ). An endorsed-triple-record () is transformed into an ev-item () as described in . (The code reuses the mms_to_ems function from .)

Endorsed Value Triple Transformation 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 } ]]> A conditional-endorsement-triple-record () is transformed into an ev-item () as described in . (The code reuses the mms_to_ems function from .)

Conditional Endorsement Triple Transformation 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 } ]]> Each conditional-endorsement-series-triple-record () is transformed into an evs-item () as described in . (The pseudocode reuses the mms_to_ems function defined in .) 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 ).

Conditional Endorsement Series Triple Transformation evs-item { evsitem := evs-item::NEW() FOREACH csr in T.series: // stage the condition sitem := series-item::NEW() sitem.condition.environment = T.condition.environment ems1 = mms_to_ems(T.condition.claims-list) sitem.condition.element-list = ems1 ems2 := mms_to_ems(csr.condition) sitem.condition.element-list::APPEND(ems2) IF T.condition.authorized-by: sitem.condition.authority = T.condition.authorized-by ELIF csr.series.condition.authorized-by: sitem.condition.authority = csr.series.condition.authorized-by // stage the addition sitem.addition.environment = T.condition.environment ems3 = mms_to_ems(csr.addition) sitem.addition.element-list = ems3 sitem.addition.cmtype = `endorsements` sitem.addition.authority = signer IF profile: sitem.addition.profile = profile evsitem[INDEXOF(sitem)] = sitem RETURN evsitem } ]]>

Keys Keys transformation involves mapping Attest Key and Device Identity triples into into a keys relation (see ). An attest-key-triple-record () or an identity-triple-record () is transformed into a key-item () as described in pseudocode.

Key Triples Transformation 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 } ]]> Note that keys are added under the authority of the Verifier because the key verification check is performed by the Verifier. After the keys relations are staged, processing commences as described in .

Domain Membership Transformation Domain membership transformation maps Domain Membership triples into dm relations (see ). Prior to adding a domain membership relation, a domain-membership-triple-record () is transformed into a domain-item () using the domain membership transformation algorithm .

Domain Membership Transformation 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 } ]]> Subsequent to transformation the domain membership relations are processed using the domain membership processing algorithm .

Trust Dependency Transformation Prior to adding a trust dependency relation, Trust Dependency triples trust-dependency-triple-record () are transformed into td relations (see ) using the trust dependency transformation algorithm .

Trust Dependency Transformation 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 } ]]> Subsequent to transformation, the trust dependency relations are processed using the trust dependency processing algorithm .

Appraisal Context Initialization At the end of Phase 1 all of the extracted and validated tags are loaded into an "appraisal context", consisting of the ACS and the staging area. The ACS is initialized with all the addition ECTs in the ae relation:

ACS Initialization ACS { FOREACH item IN ae: acs::APPEND(item.addition) RETURN acs } ]]> The staging area is loaded with rv, ev, evs, keys, dm and td relations, in that order.

Staging Area Initialization 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 } ]]>

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 ) 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.

Match and Augment Algorithm ACS { FOREACH rel IN sa: FOREACH item IN rel: IF acs::MATCH(item.condition): IF !acs::APPEND(item.addition): FAIL RETURN acs } ]]> The acs::MATCH operation depends on the type of relation. The matching logic for each type of relation is described in the following sections. The acs::APPEND operation is defined by a pre-condition and a post-condition:

Pre-condition: addition is eligible to be appended.
Post-condition: the ACS resulting from the append satisfies the required consistency invariants (e.g., that a graph encoded across ACS entries remains acyclic).

Both conditions are relation-specific; the concrete criteria for each relation are described in the following sections. If a relation's processing rules do not state a pre-condition or a post-condition, that condition is assumed to be a null operation (i.e., always satisfied) for that relation. acs::APPEND fails, leaving the ACS unchanged, if either the pre-condition or the post-condition does not hold. A failure of acs::APPEND MUST cause match_and_augment to terminate immediately, without processing any further relations or items: the appraisal that invoked it is thereby considered to have failed.

Ordering of Relations The order in which items within relations are processed is important. Processing a relation may result in ACS modifications that affect the matching behavior of other relations. The Verifier MUST ensure that any relation including a matching condition is processed after any other relation that modifies or adds an ACS entry with an environment matching the condition. This can be achieved by sorting the relations before processing, repeating the processing of some relations after ACS modifications, or using other algorithms. The "match and augment" algorithm described in assumes that relations have been topologically sorted prior to loading into the staging area ().

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.

Processing rv Relations Reference Values are matched with ACS entries by iterating through the rv list. For each rv entry, the condition ECT is compared against an ACS ECT with cmtype 2 (i.e., evidence). If the two match, the following two steps are performed:

The element-list of the matched ACS ECT is copied to the element-list of the addition ECT.
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.

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.

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.

Processing evs Relations The Conditional Endorsement Series relation is processed using a modified match_and_augment function (see ) where SERIES-MATCH() calls MATCH() (see ). The first series item that matches terminates processing of subsequent series items. The matched item is appended to the ACS.

Series Match and Augment Algorithm ACS { FOREACH rel IN sa: FOREACH item IN rel: IF ser-add = SERIES-MATCH(acs, item.series): IF !acs::APPEND(ser-add): FAIL RETURN acs } FUNC SERIES-MATCH(acs: ACS, series: SERIES) -> Endorsement-addition-ECT { FOREACH sitem IN series: IF acs::MATCH(sitem.condition): RETURN sitem.addition } ]]>

Processing keys Relations Keys relations identify cryptographic keys that require additional key verification steps before being appended to the ACS. Processing follows the algorithm as defined in . The keys list is iterated for each key-item where the acs::MATCH() function uses condition, if specified, to search the ACS for preexisting keys or to locate claims, where key verification is applied. Match conditions may return a variety of results including Evidence-addition-ECT, Reference-Value-addition-ECT, Endorsement-addition-ECT, and Key-addition-ECT ECTs. If Evidence-addition-ECT, Reference-Value-addition-ECT, or Endorsement-addition-ECT are matched, the element-list.element-map.measurement-values-map.cryptokeys list is appended to key-item.addition.key-list. If Key-addition-ECT ECTs are matched, its key-list is appended to key-item.addition.key-list. Key verification steps, such as , are applied to each key in key-item.addition.key-list. A key that is successfully verified is retained in key-item.addition.key-list; any other key is discarded. The pre-condition of acs::APPEND for keys relations is that key-item.addition.key-list contains at least one verified key. The post-condition of acs::APPEND for keys relations is null.

Processing dm Relations Domain Membership relations describe the expected topological arrangement of the Attester. Domains are matched with ACS entries by iterating through the dm list, in the staging area. For each dm entry (M-ECT), the condition ECT is compared with either an ACS Element ECT with cmtype 2 (i.e., evidence) or a Domain ECT (M-ECT). All other ECTs are ignored. If all the members environments in the condition ECT have a matching ECT in the ACS, the addition ECT is added to the ACS. The matching dm entry is pruned from the dm list. The post-condition of acs::APPEND for dm relations is that the domain-membership graph encoded by the ACS remains acyclic; the append does not take effect if this does not hold. If there is no match, processing moves to the next dm entry, till the list is exhausted; a single pass over the entire dm list constitutes one complete iteration. If there are additions to ACS, then the above algorithm is repeated until there are no more additions. The algorithm is terminated when there are no more additions to ACS. This algorithm can be optimized to complete in a single iteration, if the dm entries in the staging area and the ACS entries are topologically sorted (bottom up, from leaves to root). This specification does not mandate any specific topological sorting algorithm.

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 .

Process Trust Dependency Algorithm bool { FOREACH dm-item IN ACS.ECT(.cm==member): IF condition.environment == dm-item.environment: FOREACH trustee IN condition.trustees: IF !trustee::MEMBEROF(dm-item.members): BREAK # break inner loop, try another dm-item RETURN TRUE RETURN FALSE ]]> The pre-condition of acs::APPEND for td relations is that item.addition corresponds to a domain already present in the ACS. The post-condition of acs::APPEND for td relations is that the trust-dependency graph encoded by the ACS remains acyclic; the append does not take effect if this does not hold. Since TDGs need not be isomorphs of DMGs, this post-condition is independent of the one defined for dm relations in . Subsequent processing phases SHOULD evaluate the Trust Domain Graph against ACS corroborated Evidence to ensure trustee graphs are also trusted. For example, a Target Environment (TE-1) with corroborated Evidence that has another trustee Target Environment (TE-2), should ensure TE-2 also has corroborated Evidence before TE-1 is considered trustworthy. Additionally, a trust dependency might specify a strength of function requirement for TE-1. The trust dependency implies TE-2 should have at least the same strength of function as TE-1.

Rules of Comparison The matching component of the "match and augment" algorithm (see ) 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 (). See for an example of this, where the environments of M-ECTs and E-ECTs are compared. Conceptually, the processor creates a "matched entries" set and populates it with all ACS entries that match the C-ECT. If, after visiting all the entries in the ACS, the matched entries set is not empty, the C-ECT matches the ACS. Conversely, if the matched entries set is empty, the C-ECT does not match the ACS. If the C-ECT contains a profile and the profile defines an algorithm for a given codepoint, the processor MUST use the algorithm defined by the profile in comparisons involving that codepoint. If the condition ECT contains a profile, but the profile does not define an algorithm for a particular codepoint, the processor MUST use the standard algorithm described in this document for comparisons involving that codepoint. The specific comparisons performed depend on the type of relation being processed. In general, the processor will perform comparisons based on environment (see ) as well as more specialized comparisons based on the type of ECT matched. Element ECTs will match on element-list (see ), Key ECTs will match on key-list, Domain Membership ECTs will typically match on members (see ) and Trust Dependency ECTs will typically match on trustees (see ). [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.

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 . If all the attributes which are present in the C-ECT environment (e.g., instance or group) are also present in the ACS-ECT and are binary identical, the two environments match. Otherwise, the environments do not match. In other words, a match succeeds when the C-ECT's environment is contained in the ACS-ECT's environment as defined by Attribute Path Containment (see ) - i.e., for every Attribute Path defined in the C-ECT's environment, the ACS-ECT's environment defines the same path with an equal value. Any attribute that is present in the ACS-ECT but not in the C-ECT is ignored in the comparison.

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.

Element List Comparison A C-ECT's element-list matches an ACS-ECT's element-list if all the element-maps in the C-ECT's element-list match the element-maps in the ACS-ECT's element-list. Any element-map that is present in the ACS-ECT's element-list but not in the C-ECT's is ignored in the comparison. The rules for matching element-maps are described in .

Element Map Comparison The C-ECT's element-map matches an ACS-ECT's element-map if both the element-id and element-claims match. element-claims matching uses Attribute Path Containment (see ): every Attribute Path defined in the C-ECT's element-claims MUST be defined in the ACS-ECT's element-claims, and the ACS-ECT value at each such path MUST satisfy the corresponding C-ECT value according to the rules in ; additional attributes in the ACS-ECT are ignored. Two element-ids are considered the same if they are either both omitted, or both present with binary identical deterministic encodings. Before performing the binary comparison, the processor SHOULD convert the element-id attributes into a form that meets the CBOR core deterministic encoding requirements described in . The rules for matching element-claims are described in .

Measurement Values Map Comparison The C-ECT's element-claims match an ACS-ECT's element-claims when the C-ECT's element-claims is contained in the ACS-ECT's element-claims as defined by Attribute Path Containment (). At each Attribute Path present in both maps, the ACS-ECT value MUST satisfy the C-ECT value. For most attribute types, satisfaction means equality; for range and bound types (for example, int-range and tagged-min-svn), satisfaction means that the ACS-ECT value lies within the bounds expressed by the C-ECT value, as specified in . Otherwise, the element claims do not match. The rules for matching a single measurement-values-map attribute are described in .

Comparison of a Single Measurement Values Map Attribute The algorithm used to compare two values of a measurement-values-map attribute depends on the attribute's type. In Attribute Path Containment comparisons (), the C-ECT value at an Attribute Path plays the role of the condition and the ACS-ECT value at the same path plays the role of the entry. The comparison algorithms in this section define when an entry value satisfies a condition value at that path. The processor needs to select the appropriate algorithm for the given attribute, including any extensions defined by a supported profile. Non-negative codepoints represent standard data representations. The comparison algorithms for these are defined in this document (in the sections below) or in other specifications. Some attributes allow different types. These are designated by a CBOR tag that allows clear type disambiguation. Negative codepoints represent profile-defined data representations. The processor MUST use the attribute name, the profile associated with the condition ECT, and, if present, the CBOR tag value to select the comparison algorithm. An attribute defined by this specification that has no comparison subsection of its own is compared by binary comparison. Before performing the binary comparison, the processor MUST convert the C-ECT value and the ACS-ECT value into a form that meets the CBOR core deterministic encoding requirements described in . The comparison returns true if and only if the two encodings are binary identical. This applies to mac-addr (codepoint 6), ip-addr (codepoint 7), serial-number (codepoint 8), ueid (codepoint 9), uuid (codepoint 10) and name (codepoint 11). If the processor does not recognize an attribute, or is otherwise unable to determine the applicable comparison algorithm for it, it MUST behave as though the C-ECT does not match the ACS-ECT. The following subsections define the comparison algorithms for the other measurement-values-map attributes defined by this specification.

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.

Comparison for svn entries The value stored under measurement-values-map codepoint 1 is a security version number of type svn-type-choice. 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 .

SVN Comparison 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 } ]]>

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. 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.

Comparison for flags entries The value stored under measurement-values-map codepoint 3 is of type flags-map. Each flag is compared separately. For each flag present in the C-ECT flags-map, the comparison MUST return false if that flag is absent from the ACS-ECT flags-map or has a different value. Flags present in the ACS-ECT flags-map but absent from the C-ECT flags-map are ignored. A flag that is absent from the ACS-ECT flags-map is not treated as false. If every flag in the C-ECT flags-map matches, the same flag in the ACS-ECT flags-map, the comparison returns true.

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. If the C-ECT measurement-values-map codepoint 4 is of type tagged-bytes, and there is no value stored under codepoint 5, the processor treats it as if it were a tagged-masked-raw-value with the value field holding the same contents and a mask of the same length as the value, with all bits set. The standard comparison function defined in this document removes the CBOR tag before performing the comparison. For backwards compatibility, if the C-ECT measurement-values-map codepoint 4 is of type tagged-bytes, and there is a mask stored under codepoint 5, the processor treats it as a tagged-masked-raw-value with the value field holding the same contents and a mask holding the contents of codepoint 5. Codepoint 5 is used only as part of the codepoint 4 comparison and is not compared on its own, so it does not need to be present in the ACS-ECT. The comparison MUST return false if the lengths of the ACS-ECT entry value and the C-ECT value are different. The comparison MUST return false if the lengths of the C-ECT mask and value are different. The comparison MUST use the mask to determine which bits to compare. If a bit in the mask is 0 then this indicates that the corresponding bit in the ACS-ECT value is ignored. The comparison returns true if, for every bit position in the mask whose value is 1, the corresponding bits in both values are equal.

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.

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 after equivalence has been established according to . 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.

Comparison for int-range entries The ACS-ECT value stored under measurement-values-map codepoint 15 is an int range value of int-range-type-choice. Consider an int ACS-ECT value named ENTRY in a measurement-values-map codepoint (e.g., 15) that allows comparing int against either another int or an int-range named CONDITION.

If CONDITION is an int then an equality comparison is performed with ENTRY.
If CONDITION is an int-range (CBOR tag 564), then a range inclusion comparison is performed. The comparison MUST return true if and only if all the following conditions are true:
- CONDITION.min is null or ENTRY is greater than or equal to CONDITION.min.
- CONDITION.max is null or ENTRY is less than or equal to CONDITION.max.

Consider an int-range (CBOR tag 564) value named ENTRY in a measurement-values-map codepoint (e.g., 15) that allows comparing an int-range against either another int-range or an int named CONDITION.

If CONDITION is an int, then the comparison MUST return true if and only if ENTRY.min and ENTRY.max are both equal to CONDITION.
If CONDITION is an int-range (CBOR tag 564), then a range subsumption comparison is performed (i.e., the condition range includes all values of the entry range). The comparison MUST return true if and only if all the following conditions are true:
- 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.

Comparison for bool entries The value stored under measurement-values-map codepoint 16 is of type bool-matcher, which is a bare bool. An equality comparison is performed between the C-ECT value and the ACS-ECT value. Set match (CBOR tag 566) is not defined for bool since bool has only two possible values. A set of two or more elements represents the full domain, which can be already expressed by omitting the entry.

Comparison for integer entries The value stored under measurement-values-map codepoint 17 is of type integer-matcher. The ACS-ECT value at this codepoint is always a bare int (see ); the comparison rules below are defined against the form of the C-ECT value. If the C-ECT value is a bare int, an equality comparison is performed with the ACS-ECT value. If the C-ECT value is a tagged-integer-range (CBOR tag 565), null in the first element represents negative infinity (no lower bound) and null in the second element represents positive infinity (no upper bound). The comparison MUST return true if and only if both of the following conditions are met:

The C-ECT min is null or the ACS-ECT value is greater than or equal to min.
The C-ECT max is null or the ACS-ECT value is less than or equal to max.

At least one of min and max of a tagged-integer-range MUST be non-null. A tagged-integer-range whose min and max are both null is malformed and MUST be rejected; to match any value, the entry is omitted. If the C-ECT value is a tagged-integer-set (CBOR tag 566), the comparison MUST return true if and only if the ACS-ECT value equals any element of the set.

Comparison for float entries The value stored under measurement-values-map codepoint 20 is of type float-matcher. The ACS-ECT value at this codepoint is always a bare float (see ); the comparison rules below are defined against the form of the C-ECT value. Comparison is numeric, not byte-wise: it does not depend on the width (e.g., half, single or double precision) or on the preferred or non-preferred serialization used to encode a value.

+0.0 and -0.0 are equal.
+Infinity and -Infinity are equal only to themselves, and order above and below all finite values, respectively.

NaN MUST NOT appear in a float-matcher, whether as a bare value, as a range bound, or as a set element. A float-matcher that contains a NaN is malformed and MUST be rejected. An Evidence transformation MUST NOT produce a NaN as the ACS-ECT value; Evidence that would result in one MUST be rejected. If the C-ECT value is a bare float, an equality comparison is performed with the ACS-ECT value. If the C-ECT value is a tagged-float-range (CBOR tag 565), null in the first element represents negative infinity (no lower bound) and null in the second element represents positive infinity (no upper bound). The comparison MUST return true if and only if both of the following conditions are met:

The C-ECT min is null or the ACS-ECT value is greater than or equal to min.
The C-ECT max is null or the ACS-ECT value is less than or equal to max.

The min and max of a tagged-float-range MUST NOT be +Infinity or -Infinity; null is the only way to express an unbounded range. A tagged-float-range that violates this requirement is malformed and MUST be rejected. At least one of min and max of a tagged-float-range MUST be non-null. A tagged-float-range whose min and max are both null is malformed and MUST be rejected; to match any value, the entry is omitted. If the C-ECT value is a tagged-float-set (CBOR tag 566), the comparison MUST return true if and only if the ACS-ECT value equals any element of the set.

Comparison for text entries The value stored under measurement-values-map codepoint 18 is of type text-matcher. The ACS-ECT value at this codepoint is always a bare text (see ); the comparison rules below are defined against the form of the C-ECT value. If the C-ECT value is a bare text, an equality comparison is performed with the ACS-ECT value. If the C-ECT value is a tagged-text-set (CBOR tag 566), the comparison MUST return true if and only if the ACS-ECT value equals any element of the set.

Comparison for bytes entries The value stored under measurement-values-map codepoint 19 is of type bytes-matcher. The ACS-ECT value at this codepoint is always a bare bytes (see ); the comparison rules below are defined against the form of the C-ECT value. If the C-ECT value is a bare bytes, an equality comparison is performed with the ACS-ECT value. If the C-ECT value is a tagged-bytes-set (CBOR tag 566), the comparison MUST return true if and only if the ACS-ECT value equals any element of the set.

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.

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.

Example Appraisal The following example describes the appraisal of a PSA Attester from the fictitious vendor "Acme Inc.", which uses the CoRIM profile documented in .

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 ) 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.

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 ). 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.

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.

Input Evidence The Verifier obtains Evidence from a PSA Attester in the format described in and verifies its cryptographic integrity and validity.

Internal Representations As described in , once all the "raw" inputs have been validated, input transformations can start. The two Reference Values triples from the manufacturer's CoMID are mapped to their corresponding rv-items (, ) using the transformations defined in . The first triple:

First rv Relation Item The second triple:

Second rv Relation Item 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 () using the transformation defined in .

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 :

ae-item Note the authority in the ECT, which is set to MFkw..Lg==, and corresponds to the Attester's PEM-encoded SPKI.

Appraisal As described in , 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 can begin. The first relation to be processed is rv, according to the rules described in . The condition of the first rv-item () is matched against the ACS which, at this time, contains a single ECT obtained from the ae-item (). 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 ().

ACS State after Corroboration The algorithm then moves on to the second rv-item (), 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 . The condition of the first (and only) ev-item () 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 ().

ACS State after Endorsements Augmentation At this point, all the relations in the Staging Area have been processed, and the match_and_augment algorithm () terminates, returning the computed ACS.

Implementation Status This section is to be removed before publishing as an RFC. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . 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 , "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".

Veraison

Organization responsible for the implementation: Veraison Project, Linux Foundation
Implementation's web page: https://github.com/veraison/corim/README.md
Brief general description: There are three CoRIM libraries under project Veraison.
1. CoRIM golang library 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 provide a rust implementation of CoRIM specification.
3. CoRIM Processor provides a library for appraisal of Evidence by processing CoRIMs as outlined in of this specification.
In addition to the base CoRIM Libraries, the cocli package 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 for further details.
Implementation's level of maturity: alpha.
Coverage: the whole protocol is implemented, including PSA-specific extensions .
Version compatibility: Version -06 of the draft
Licensing: Apache 2.0 https://github.com/veraison/corim/blob/main/LICENSE
Implementation experience: n/a
Contact information: https://veraison.zulipchat.com
Last updated: https://github.com/veraison/corim/commits/main https://github.com/veraison/corim-rs/commits/master/ https://github.com/veraison/cover/commits/main/

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. 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 );
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 and of ; these considerations apply to this document as well.

IANA Considerations

New COSE Header Parameters

New CBOR Tags IANA is requested to allocate the following tags in the "CBOR Tags" registry , preferably with the specific CBOR tag value requested:

Tag	Data Item	Semantics	Reference
500	`tag`	Reserved for backward compatibility	RFCthis
501	`map`	A tagged-unsigned-corim-map, see	RFCthis
502-504	`any`	Earmarked for CoRIM	RFCthis
505	`bytes`	A tagged-concise-swid-tag, see	RFCthis
506	`bytes`	A tagged-concise-mid-tag, see	RFCthis
507	`any`	Earmarked for CoRIM	RFCthis
508	`bytes`	A tagged-concise-tl-tag, see	RFCthis
509-549	`any`	Earmarked for CoRIM	RFCthis
550	`bytes .size (7..33)`	tagged-ueid-type, see	RFCthis
551	`any`	Earmarked for CoRIM	RFCthis
552	`uint`	tagged-svn, see	RFCthis
553	`uint`	tagged-min-svn, see	RFCthis
554	`text`	tagged-pkix-base64-key-type, see	RFCthis
555	`text`	tagged-pkix-base64-cert-type, see	RFCthis
556	`text`	tagged-pkix-base64-cert-path-type, see	RFCthis
557	`[int/text, bytes]`	tagged-key-thumbprint-type, see	RFCthis
558	`COSE_Key`	tagged-cose-key-type, see	RFCthis
559	`digest`	tagged-cert-thumbprint-type, see	RFCthis
560	`bytes`	tagged-bytes, see	RFCthis
561	`digest`	tagged-cert-path-thumbprint-type, see	RFCthis
562	`bytes`	tagged-pkix-asn1der-cert-type, see	RFCthis
563	`tagged-masked-raw-value`	tagged-masked-raw-value, see	RFCthis
564	`array`	tagged-int-range, see	RFCthis
565	`array`	tagged-{integer,float}-range, see	RFCthis
566	`array`	tagged-{integer,float,text,bytes}-set, see	RFCthis
567-599	`any`	Earmarked for CoRIM	RFCthis

Tags designated as "Earmarked for CoRIM" can be reassigned by IANA based on advice from the designated expert for the CBOR Tags registry.

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 as follows: CoRIM Map Items Registration Procedures

Range	Registration Procedures
0-127	Standards Action
128-255	Specification Required

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. CoRIM Map Items Initial Registrations

Index	Item Name	Specification
0	id	RFCthis
1	tags	RFCthis
2	dependent-rims	RFCthis
3	profile	RFCthis
4	rim-validity	RFCthis
5	entities	RFCthis
6-255	Unassigned

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 as follows: CoRIM Entity Map Items Registration Procedures

Range	Registration Procedures
0-127	Standards Action
128-255	Specification Required

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. CoRIM Entity Map Items Initial Registrations

Index	Item Name	Value Type	Description	Specification
0	entity-name	`text`	Name of the entity responsible for the actions of the role.	RFCthis
1	reg-id	`uri`	A URI associated with the organization that owns the entity name.	RFCthis
2	role	`[ + role-type-choice ]`	A type choice defining the roles that the entity is claiming.	RFCthis
3-255	Unassigned

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 as follows: CoRIM Signer Map Items Registration Procedures

Range	Registration Procedures
0-127	Standards Action
128-255	Specification Required

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. CoRIM Signer Map Items Initial Registrations

Index	Item Name	Specification
0	signer-name	RFCthis
1	signer-uri	RFCthis
2-255	Unassigned

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 as follows: CoMID Map Items Registration Procedures

Range	Registration Procedures
0-127	Standards Action
128-255	Specification Required

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. CoMID Map Items Initial Registrations

Index	Item Name	Specification
0	language	RFCthis
1	tag-identity	RFCthis
2	entities	RFCthis
3	linked-tags	RFCthis
4	triples	RFCthis
5-255	Unassigned

CoMID Entity Map Registry This document defines a new registry titled "CoMID Entity Map". The registry uses integer values as index values for items in comid-entity-map CBOR maps. Future registrations for this registry are to be made based on as follows: CoMID Entity Map Items Registration Procedures

Range	Registration Procedures
0-127	Standards Action
128-255	Specification Required

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. CoMID Entity Map Items Initial Registrations

Index	Item Name	Value Type	Description	Specification
0	entity-name	`text`	Name of the entity responsible for the actions of the role.	RFCthis
1	reg-id	`uri`	A URI associated with the organization that owns the entity name.	RFCthis
2	role	`[ + role-type-choice ]`	A type choice defining the roles that the entity is claiming.	RFCthis
3-255	Unassigned

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 as follows: CoMID Triples Map Items Registration Procedures

Range	Registration Procedures
0-1023	Standards Action
1024-65535	Specification Required
65536-18446744073709551616	First come first served

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. CoMID Triples Map Items Initial Registrations

Index	Item Name	Specification
0	reference-triples	RFCthis
1	endorsed-triples	RFCthis
2	identity-triples	RFCthis
3	attest-key-triples	RFCthis
4	dependency-triples	RFCthis
5	membership-triples	RFCthis
6	coswid-triples	RFCthis
7	(reserved)	RFCthis
8	conditional-endorsement-series-triples	RFCthis
9	(reserved)	RFCthis
10	conditional-endorsement-triples	RFCthis
11-18446744073709551616	Unassigned

CoMID Measurement Values Map Registry This document defines a new registry titled "CoMID Measurement Values Map". The registry uses integer values as index values for items in measurement-values-map. Future registrations for this registry are to be made based on as follows: CoMID Measurement Values Map Items Registration Procedures

Range	Registration Procedures
0-1023	Standards Action
1024-65535	Specification Required
65536-18446744073709551616	First come first served

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. Measurement Values Map Items Initial Registrations

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	bool	RFCthis
17	integer	RFCthis
18	text	RFCthis
19	bytes	RFCthis
20	float	RFCthis
21-18446744073709551616	Unassigned

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 as follows: CoMID Flags Map Items Registration Procedures

Range	Registration Procedures
0-1023	Standards Action
1024-65535	Specification Required
65536-18446744073709551616	First come first served

All negative values are reserved for Private Use. Initial registrations for the "CoMID Flags Map" registry are provided below. Assignments consist of an integer index value, the item name, and a reference to the defining specification. Flags Map Items Initial Registrations

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

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 as follows: CoTL Map Items Registration Procedures

Range	Registration Procedures
0-127	Standards Action
128-255	Specification Required

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. CoTL Map Items Initial Registrations

Index	Item Name	Specification
0	tag-identity	RFCthis
1	tags-list	RFCthis
2	tl-validity	RFCthis
3-255	Unassigned

New Media Types IANA is requested to add the following media types to the "Media Types" registry . New Media Types

Name	Template	Reference
rim+cbor	application/rim+cbor	RFCthis, ()
rim+cose	application/rim+cose	RFCthis, ()

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:: of RFCthis
Interoperability considerations:: n/a
Published specification:: RFCthis
Applications that use this media type:: Attestation Verifiers, Endorsers and Reference-Value providers that need to transfer unprotected CoRIM payloads over HTTP(S), CoAP(S), and other transports.
Fragment identifier considerations:: n/a
Magic number(s):: D9 01 F5
File extension(s):: .corim
Macintosh file type code(s):: n/a
Person and email address to contact for further information:: RATS WG mailing list (rats@ietf.org)
Intended usage:: COMMON
Restrictions on usage:: none
Author/Change controller:: IETF
Provisional registration?: no

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:: of RFCthis
Interoperability considerations:: n/a
Published specification:: RFCthis
Applications that use this media type:: Attestation Verifiers, Endorsers and Reference-Value providers that need to transfer CoRIM payloads protected using COSE Sign1 over HTTP(S), CoAP(S), and other transports.
Fragment identifier considerations:: n/a
Magic number(s):: D2 84
File extension(s):: .corim
Macintosh file type code(s):: n/a
Person and email address to contact for further information:: RATS WG mailing list (rats@ietf.org)
Intended usage:: COMMON
Restrictions on usage:: none
Author/Change controller:: IETF
Provisional registration?: no

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 : New Content-Formats

Content-Type	Content Coding	ID	Reference
application/rim+cbor	-	TBD1	RFCthis
application/rim+cose	-	TBD2	RFCthis

New Software ID Version Scheme Value IANA is requested to register the following Version Scheme Name in the "Software ID Version Scheme Values" registry within the "Software ID Values" registry group.

Index	Version Scheme Name	Reference
5	binary	of RFCthis

References Normative References Universally Unique IDentifiers (UUIDs) This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Textual Encodings of PKIX, PKCS, and CMS Structures This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate. Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Concise Binary Object Representation (CBOR) Tags for Object Identifiers The Concise Binary Object Representation (CBOR), defined in RFC 8949, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined. Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes This specification defines two Concise Binary Object Representation (CBOR) tags for use with IPv6 and IPv4 addresses and prefixes. CBOR Object Signing and Encryption (COSE): Structures and Process Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Uniform Resource Identifier (URI): Generic Syntax A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Concise Software Identification Tags ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format. CBOR Web Token (CWT) Claims in COSE Headers This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. CBOR Web Token (CWT) CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. The Entity Attestation Token (EAT) An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. RATS Conceptual Messages Wrapper (CMW) Fraunhofer SIT Independent Linaro University of Applied Sciences Bonn-Rhein-Sieg Google LLC The Conceptual Messages introduced by the RATS architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, evolving message serialization formats without breaking compatibility, and avoiding the need to redefine how messages are handled within each protocol. Entity Attestation Token (EAT) Measured Component Arm Linaro University of Applied Sciences Bonn-Rhein-Sieg Fraunhofer SIT The term "measured component" refers to an object within the attester's target environment whose state can be sampled and typically digested using a cryptographic hash function. Examples of measured components include firmware stored in flash memory, software loaded into memory at start time, data stored in a file system, or values in a CPU register. This document provides the information model for the "measured component" and two associated data models. This separation is intentional: the JSON and CBOR serializations, coupled with the media types and associated Constrained Application Protocol (CoAP) Content-Formats, enable the immediate use of the semantics within the Entity Attestation Token (EAT) framework. Meanwhile, the information model can be reused in future specifications to provide additional serializations, for example, using ASN.1. Language Subtag Registry IANA ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER) International Telephone and Telegraph Consultative Committee CBOR Object Signing and Encryption (COSE) Hash Envelope This document defines new CBOR Object Signing and Encryption (COSE) header parameters for signaling a payload as an output of a hash function. This mechanism enables faster validation, as access to the original payload is not required for signature validation. Additionally, hints of the hashed payload's content format and availability are defined, providing references to optional discovery mechanisms that can help to find the original payload content. The Base16, Base32, and Base64 Data Encodings This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Concise Binary Object Representation (CBOR) Tags IANA Media Types IANA Constrained RESTful Environments (CoRE) Parameters IANA Software ID Values IANA Informative References JSON Web Token (JWT) JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. Improving Awareness of Running Code: The Implementation Status Section This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. 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. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Remote ATtestation procedureS (RATS) Architecture In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. A CoRIM Profile for Arm's Platform Security Architecture (PSA) Endorsements Linaro Arm Ltd Fraunhofer SIT PSA Endorsements comprise reference values, endorsed values, cryptographic key material and certification status information that a Verifier needs in order to appraise Attestation Evidence produced by a PSA device. This memo defines PSA Endorsements as a profile of the CoRIM data model. A CoRIM Profile for Arm's Confidential Computing Architecture (CCA) Endorsements Arm Ltd Linaro Arm Confidential Computing Architecture (CCA) Endorsements comprise reference values and cryptographic key material that a Verifier needs to appraise Attestation Evidence produced by an Arm CCA system. This memo defines CCA Endorsements as a profile of the CoRIM data model. 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/yogeshbdeshpande/draft-cca-rats-endorsements. Arm's Platform Security Architecture (PSA) Attestation Token Arm's Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, along with open-source reference implementations, aimed at helping device makers and chip manufacturers integrate best-practice security into their products. Devices that comply with PSA can generate attestation tokens as described in this document, which serve as the foundation for various protocols, including secure provisioning and network access control. This document specifies the structure and semantics of the PSA attestation token. The PSA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes the claims used in an attestation token generated by PSA-compliant systems, how these claims are serialized for transmission, and how they are cryptographically protected. This Informational document is published as an Independent Submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF. Remote Attestation Procedures (RATS) Endorsements Armidale Consulting Fraunhofer SIT NVIDIA In the IETF Remote Attestation Procedures (RATS) architecture (RFC 9334), a Verifier accepts Evidence and uses Appraisal Policy for Evidence, typically with additional input from Endorsements and Reference Values, to generate Attestation Results in formats that are useful for Relying Parties. This document illustrates the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements in the scope of the RATS architecture. This document does not aim to define a conceptual message format for Endorsements and Reference Values. Instead, it updates RFC 9334 by refining the description of Endorsements and Reference Values. Specifically, this document classifies the RATS conceptual messages as actual state, reference state, or appraisal policy, and adds considerations on conditionally endorsed values, endorsing verification keys, timeliness, and multiple Endorsements. Evidence Transformations AMD Independent Independent Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester to decide if continued interaction is warrented. Evidence structures can vary making appraisals challenging for Verifiers. Verifiers need to understand Evidence encoding formats and some of the Evidence semantics to appraise it. Consequently, Evidence may require format transformation to an internal representation that preserves original semantics. This document specifies Evidence transformation methods for DiceTcbInfo, concise evidence, and SPDM measurements block structures. These Evidence structures are converted to the CoRIM internal representation and follow CoRIM defined appraisal procedures. DICE Layering Architecture Trusted Computing Group Concise Software Identifier (CoSWID) IANA Concise TA Stores (CoTS) Red Hound Software Vigil Security, LLC arm arm Trust anchor (TA) stores may be used for several purposes in the Remote Attestation Procedures (RATS) architecture including verifying endorsements, reference values, digital letters of approval, attestations, or public key certificates. This document describes a Concise Reference Integrity Manifest (CoRIM) extension that may be used to convey optionally constrained trust anchor stores containing optionally constrained trust anchors in support of these purposes. DICE Certificate Profiles Trusted Computing Group DICE Endorsement Architecture for Devices Trusted Computing Group TCG Trusted Network Connect TNC Architecture for Interoperability Trusted Computing Group Trusted Platform Module Library, Part 1: Architecture Trusted Computing Group IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture IEEE Security Protocol and Data Model (SPDM) Specification Distributed Management Task Force RDF 1.1 Primer Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226.

Base CoRIM CDDL 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 corim-locator-map = { &(href: 0) => uri / [+ uri], ? &(thumbprint: 1) => eatmc.digest / [+ eatmc.digest], } corim-map = { &(id: 0) => $corim-id-type-choice, &(tags: 1) => [+ $concise-tag-type-choice], ? &(dependent-rims: 2) => [+ corim-locator-map], ? &(profile: 3) => $profile-type-choice, ? &(rim-validity: 4) => validity-map, ? &(entities: 5) => [+ corim-entity-map], * $$corim-map-extension, } unsigned-corim-map = corim-map corim-meta-map = { &(signer: 0) => corim-signer-map, ? &(signature-validity: 1) => validity-map, } $corim-role-type-choice /= &(manifest-creator: 1) / &(manifest-\ signer: 2) corim-signer-map = { &(signer-name: 0) => $entity-name-type-choice, ? &(signer-uri: 1) => uri, * $$corim-signer-map-extension, } COSE-Sign1-corim = [ protected: bstr .cbor protected-corim-header-map, unprotected: unprotected-corim-header-map, payload: bstr .cbor tagged-unsigned-corim-map / hash-envelope-\ digest / nil, signature: bstr, ] hash-envelope-digest = bstr COSE-Sign-corim = [ protected: bstr .cbor protected-corim-header-map, unprotected: unprotected-corim-header-map, payload: bstr .cbor tagged-unsigned-corim-map / hash-envelope-\ digest / nil, signature: [+ signature-structure], ] $profile-type-choice /= uri / tagged-oid-type cwt-claims = { &(iss: 1) => tstr, ? &(sub: 2) => tstr, ? &(exp: 4) => int / float, ? &(nbf: 5) => int / float, * int => any, } protected-corim-header-map = protected-corim-header-map-inline / \ protected-corim-header-map-hash-envelope protected-corim-header-map-inline = { &(alg: 1) => int, &(content-type: 3) => "application/rim+cbor", meta-group, * cose-label => cose-value, } protected-corim-header-map-hash-envelope = { &(alg: 1) => int, &(payload_hash_alg: 258) => int, &(payload_preimage_content_type: 259) => "application/rim+cbor", ? &(payload_location: 260) => tstr, meta-group, * cose-label => cose-value, } meta-group = (( corim-meta-identity, ? cwt-claims-identity, ) // cwt-claims-identity) corim-meta-identity = (&(corim-meta: 8) => bstr .cbor corim-meta-map) cwt-claims-identity = (&(CWT-Claims: 15) => cwt-claims) signed-corim = #6.18(COSE-Sign1-corim) / #6.98(COSE-Sign-corim) tagged-concise-swid-tag = #6.505(bytes .cbor coswid.concise-swid-tag) signature-structure = [ protected: bstr .cbor protected-corim-header-map, unprotected: unprotected-corim-header-map, signature: bstr, ] tagged-concise-mid-tag = #6.506(bytes .cbor concise-mid-tag) tagged-concise-tl-tag = #6.508(bytes .cbor concise-tl-tag) tagged-unsigned-corim-map = #6.501(unsigned-corim-map) unprotected-corim-header-map = {* cose-label => cose-value} validity-map = { ? &(not-before: 0) => time, &(not-after: 1) => time, } concise-mid-tag = { ? &(language: 0) => text, &(tag-identity: 1) => tag-identity-map, ? &(entities: 2) => [+ comid-entity-map], ? &(linked-tags: 3) => [+ linked-tag-map], &(triples: 4) => triples-map, * $$concise-mid-tag-extension, } attest-key-triple-record = [ environment: environment-map, key-list: [+ $crypto-key-type-choice], ? conditions: non-empty<{ ? &(mkey: 0) => $measured-element-type-choice, ? &(authorized-by: 1) => [+ $crypto-key-type-choice], }>, ] $class-id-type-choice /= tagged-oid-type / tagged-uuid-type / tagged\ -bytes class-map = non-empty<{ ? &(class-id: 0) => $class-id-type-choice, ? &(vendor: 1) => tstr, ? &(model: 2) => tstr, ? &(layer: 3) => uint, ? &(index: 4) => uint, }> comid-entity-map = entity-map<$comid-role-type-choice, $$comid-\ entity-map-extension> $comid-role-type-choice /= &(tag-creator: 0) / &(creator: 1) / &(\ maintainer: 2) conditional-endorsement-series-triple-record = [ common-condition: [ environment: environment-map, claims-list: [* measurement-map], ? authorized-by: [+ $crypto-key-type-choice], ], series: [+ conditional-series-record], ] conditional-series-record = [ condition: [+ measurement-map], addition: [+ measurement-map], ] COSE_Key = { 1 => tstr / int, ? 2 => bstr, ? 3 => tstr / int, ? 4 => [+ tstr / int], ? 5 => bstr, * cose-label => cose-value, } cose-label = int / tstr cose-value = any coswid-triple-record = [ environment-map, [+ coswid.tag-id], ] $crypto-key-type-choice /= tagged-pkix-base64-key-type / tagged-pkix\ -base64-cert-type / tagged-pkix-base64-cert-path-type / tagged-cose-\ key-type / tagged-pkix-asn1der-cert-type / tagged-key-thumbprint-\ type / tagged-cert-thumbprint-type / tagged-cert-path-thumbprint-\ type / tagged-bytes tagged-pkix-base64-key-type = #6.554(tstr) tagged-pkix-base64-cert-type = #6.555(tstr) tagged-pkix-base64-cert-path-type = #6.556(tstr) tagged-key-thumbprint-type = #6.557(eatmc.digest) tagged-cose-key-type = #6.558(COSE_Key) tagged-cert-thumbprint-type = #6.559(eatmc.digest) tagged-cert-path-thumbprint-type = #6.561(eatmc.digest) tagged-pkix-asn1der-cert-type = #6.562(bstr) trust-dependency-triple-record = [ domain-id: domain-type, trustees: [+ domain-type], ] domain-membership-triple-record = [ domain-id: domain-type, members: [+ domain-type], ] conditional-endorsement-triple-record = [ conditions: [+ stateful-environment-record], endorsements: [+ endorsed-triple-record], ] domain-type = environment-map endorsed-triple-record = [ condition: environment-map, endorsement: [+ measurement-map], ] entity-map = { &(entity-name: 0) => $entity-name-type-choice, ? &(reg-id: 1) => uri, &(role: 2) => [+ role-type-choice], * extension-socket, } $entity-name-type-choice /= text environment-map = non-empty<{ ? &(class: 0) => class-map, ? &(instance: 1) => $instance-id-type-choice, ? &(group: 2) => $group-id-type-choice, }> flags-map = non-empty<{ ? &(is-configured: 0) => bool, ? &(is-secure: 1) => bool, ? &(is-recovery: 2) => bool, ? &(is-debug: 3) => bool, ? &(is-replay-protected: 4) => bool, ? &(is-integrity-protected: 5) => bool, ? &(is-runtime-meas: 6) => bool, ? &(is-immutable: 7) => bool, ? &(is-tcb: 8) => bool, ? &(is-confidentiality-protected: 9) => bool, ? &(is-runtime-updatable: 10) => bool, * $$flags-map-extension, }> $group-id-type-choice /= tagged-uuid-type / tagged-bytes identity-triple-record = [ environment: environment-map, key-list: [+ $crypto-key-type-choice], ? conditions: non-empty<{ ? &(mkey: 0) => $measured-element-type-choice, ? &(authorized-by: 1) => [+ $crypto-key-type-choice], }>, ] $instance-id-type-choice /= tagged-ueid-type / tagged-uuid-type / \ tagged-bytes / tagged-pkix-base64-key-type / tagged-pkix-base64-cert\ -type / tagged-cose-key-type / tagged-key-thumbprint-type / tagged-\ cert-thumbprint-type / tagged-pkix-asn1der-cert-type ip-addr-type-choice /= cbor-ip.ipv4-address / cbor-ip.ipv6-address int-range-type-choice = int / tagged-int-range int-range = [ min: int / negative-inf, max: int / positive-inf, ] tagged-int-range = #6.564(int-range) positive-inf = null negative-inf = null tagged-integer-set = #6.566([2*int]) tagged-float-set = #6.566([2*float]) tagged-text-set = #6.566([2*text]) tagged-bytes-set = #6.566([2*bytes]) tagged-integer-range = #6.565([ int / null, int / null, ]) tagged-float-range = #6.565([ float / null, float / null, ]) bool-matcher = bool integer-matcher = int / tagged-integer-range / tagged-integer-set float-matcher = float / tagged-float-range / tagged-float-set text-matcher = text / tagged-text-set bytes-matcher = bytes / tagged-bytes-set linked-tag-map = { &(linked-tag-id: 0) => $tag-id-type-choice, &(tag-rel: 1) => $tag-rel-type-choice, } mac-addr-type-choice = eui48-addr-type / eui64-addr-type eui48-addr-type = bytes .size 6 eui64-addr-type = bytes .size 8 $measured-element-type-choice /= tagged-oid-type / tagged-uuid-type \ / uint / tstr measurement-map = { ? &(mkey: 0) => $measured-element-type-choice, &(mval: 1) => measurement-values-map, ? &(authorized-by: 2) => [+ $crypto-key-type-choice], } measurement-values-map = non-empty<{ ? &(version: 0) => version-map, ? &(svn: 1) => svn-type-choice, ? &(digests: 2) => digests-type, ? &(flags: 3) => flags-map, ? ( &(raw-value: 4) => $raw-value-type-choice, ? &(raw-value-mask-DEPRECATED: 5) => raw-value-\ mask-type, ), ? &(mac-addr: 6) => mac-addr-type-choice, ? &(ip-addr: 7) => ip-addr-type-choice, ? &(serial-number: 8) => text, ? &(ueid: 9) => ueid-type, ? &(uuid: 10) => uuid-type, ? &(name: 11) => text, ? &(cryptokeys: 13) => [+ $crypto-key-type-choice], ? &(integrity-registers: 14) => integrity-registers, ? &(int-range: 15) => int-range-type-choice, ? &(bool: 16) => bool-matcher, ? &(integer: 17) => integer-matcher, ? &(text: 18) => text-matcher, ? &(bytes: 19) => bytes-matcher, ? &(float: 20) => float-matcher, * $$measurement-values-map-extension, }> non-empty = M .and ({+ any => any}) oid-type = bytes tagged-oid-type = #6.111(oid-type) $raw-value-type-choice /= tagged-bytes / tagged-masked-raw-value raw-value-mask-type = bytes tagged-masked-raw-value = #6.563([ value: bytes, mask: bytes, ]) reference-triple-record = [ ref-env: environment-map, ref-claims: [+ measurement-map], ] stateful-environment-record = [ environment: environment-map, claims-list: [+ measurement-map], ] svn-type = uint svn = svn-type min-svn = svn-type tagged-svn = #6.552(svn) tagged-min-svn = #6.553(min-svn) svn-type-choice = svn / tagged-svn / tagged-min-svn $tag-id-type-choice /= tstr / uuid-type tag-identity-map = { &(tag-id: 0) => $tag-id-type-choice, ? &(tag-version: 1) => tag-version-type, } $tag-rel-type-choice /= &(supplements: 0) / &(replaces: 1) tag-version-type = uint tagged-bytes = #6.560(bytes) triples-map = non-empty<{ ? &(reference-triples: 0) => [+ reference-triple-record], ? &(endorsed-triples: 1) => [+ endorsed-triple-record], ? &(identity-triples: 2) => [+ identity-triple-record], ? &(attest-key-triples: 3) => [+ attest-key-triple-record], ? &(dependency-triples: 4) => [+ trust-dependency-triple-record], ? &(membership-triples: 5) => [+ domain-membership-triple-record\ ], ? &(coswid-triples: 6) => [+ coswid-triple-record], ? &(conditional-endorsement-series-triples: 8) => [+ conditional\ -endorsement-series-triple-record], ? &(conditional-endorsement-triples: 10) => [+ conditional-\ endorsement-triple-record], * $$triples-map-extension, }> ueid-type = bytes .size (7 .. 33) tagged-ueid-type = #6.550(ueid-type) uuid-type = bytes .size 16 tagged-uuid-type = #6.37(uuid-type) version-map = { &(version: 0) => text, ? &(version-scheme: 1) => coswid.$version-scheme, } digests-type = [+ eatmc.digest] integrity-register-id-type-choice = uint / text integrity-registers = {+ integrity-register-id-type-choice => \ digests-type} $$measurement-values-map-extension //= (&(psa-cert-num: 100) => psa-\ cert-num-type) psa-cert-num-type = text .regexp "[0-9]{13} - [0-9]{5}" eatmc.measured-component = { eatmc.component-id-label => eatmc.component-id, eatmc.measurement, ? eatmc.authorities-label => [+ eatmc.authority-id-type], ? eatmc.flags-label => eatmc.flags-type, } eatmc.measurement //= (eatmc.digested-measurement-label => eatmc.\ digest // eatmc.raw-measurement-label => bytes) eatmc.authority-id-type = eatmc.eat.JC eatmc.flags-type = eatmc.eat.JC eatmc.component-id = [ name: text, ? version: eatmc.version, ] eatmc.version = [ val: text, ? scheme: eatmc.coswid.$version-scheme, ] eatmc.digest = [ alg: int / text, val: eatmc.digest-value-type, ] eatmc.digest-value-type = eatmc.eat.JC eatmc.bytes-b64u = text .b64u bytes eatmc.bytes8 = bytes .size 8 eatmc.bytes8-b64u = text .b64u eatmc.bytes8 eatmc.component-id-label = eatmc.eat.JC<"id", 1> eatmc.digested-measurement-label = eatmc.eat.JC<"digested-\ measurement", 2> eatmc.raw-measurement-label = eatmc.eat.JC<"raw-measurement", 5> eatmc.authorities-label = eatmc.eat.JC<"authorities", 3> eatmc.flags-label = eatmc.eat.JC<"flags", 4> eatmc.mc-cbor = bytes .cbor eatmc.measured-component eatmc.mc-json = text .json eatmc.measured-component eatmc.$measurements-body-cbor /= eatmc.mc-cbor / eatmc.mc-json eatmc.$measurements-body-json /= eatmc.mc-json / text .b64u eatmc.mc\ -cbor eatmc.eat.JSON-ONLY = J .feature "json" eatmc.eat.CBOR-ONLY = C .feature "cbor" eatmc.eat.JC = eatmc.eat.JSON-ONLY / eatmc.eat.CBOR-ONLY eatmc.coswid.$version-scheme /= eatmc.coswid.multipartnumeric / \ eatmc.coswid.multipartnumeric-suffix / eatmc.coswid.alphanumeric / \ eatmc.coswid.decimal / eatmc.coswid.semver / int / text eatmc.coswid.multipartnumeric = 1 eatmc.coswid.multipartnumeric-suffix = 2 eatmc.coswid.alphanumeric = 3 eatmc.coswid.decimal = 4 eatmc.coswid.semver = 16384 coswid.concise-swid-tag = { coswid.tag-id => text / bstr .size 16, coswid.tag-version => integer, ? coswid.corpus => bool, ? coswid.patch => bool, ? coswid.supplemental => bool, coswid.software-name => text, ? coswid.software-version => text, ? coswid.version-scheme => coswid.$version-scheme, ? coswid.media => text, ? coswid.software-meta => coswid.one-or-more, coswid.entity => coswid.one-or-more, ? coswid.link => coswid.one-or-more, ? coswid.payload-or-evidence, * $$coswid-extension, coswid.global-attributes, } coswid.tag-id = 0 coswid.$version-scheme /= coswid.multipartnumeric / coswid.\ multipartnumeric-suffix / coswid.alphanumeric / coswid.decimal / \ coswid.semver / int / text coswid.one-or-more = T / [2*T] coswid.tag-version = 12 coswid.corpus = 8 coswid.patch = 9 coswid.supplemental = 11 coswid.software-name = 1 coswid.software-version = 13 coswid.version-scheme = 14 coswid.media = 10 coswid.software-meta = 5 coswid.software-meta-entry = { ? coswid.activation-status => text, ? coswid.channel-type => text, ? coswid.colloquial-version => text, ? coswid.description => text, ? coswid.edition => text, ? coswid.entitlement-data-required => bool, ? coswid.entitlement-key => text, ? coswid.generator => text / bstr .size 16, ? coswid.persistent-id => text, ? coswid.product => text, ? coswid.product-family => text, ? coswid.revision => text, ? coswid.summary => text, ? coswid.unspsc-code => text, ? coswid.unspsc-version => text, * $$software-meta-extension, coswid.global-attributes, } coswid.entity = 2 coswid.entity-entry = { coswid.entity-name => text, ? coswid.reg-id => coswid.any-uri, coswid.role => coswid.one-or-more, ? coswid.thumbprint => coswid.hash-entry, * $$entity-extension, coswid.global-attributes, } coswid.link = 4 coswid.link-entry = { ? coswid.artifact => text, coswid.href => coswid.any-uri, ? coswid.media => text, ? coswid.ownership => coswid.$ownership, coswid.rel => coswid.$rel, ? coswid.media-type => text, ? coswid.use => coswid.$use, * $$link-extension, coswid.global-attributes, } coswid.payload-or-evidence //= (coswid.payload => coswid.payload-\ entry // coswid.evidence => coswid.evidence-entry) coswid.global-attributes = ( ? coswid.lang => text, * coswid.any-attribute, ) coswid.multipartnumeric = 1 coswid.multipartnumeric-suffix = 2 coswid.alphanumeric = 3 coswid.decimal = 4 coswid.semver = 16384 coswid.activation-status = 43 coswid.channel-type = 44 coswid.colloquial-version = 45 coswid.description = 46 coswid.edition = 47 coswid.entitlement-data-required = 48 coswid.entitlement-key = 49 coswid.generator = 50 coswid.persistent-id = 51 coswid.product = 52 coswid.product-family = 53 coswid.revision = 54 coswid.summary = 55 coswid.unspsc-code = 56 coswid.unspsc-version = 57 coswid.entity-name = 31 coswid.reg-id = 32 coswid.any-uri = uri coswid.role = 33 coswid.$role /= coswid.tag-creator / coswid.software-creator / \ coswid.aggregator / coswid.distributor / coswid.licensor / coswid.\ maintainer / int / text coswid.thumbprint = 34 coswid.hash-entry = [ hash-alg-id: int, hash-value: bytes, ] coswid.artifact = 37 coswid.href = 38 coswid.ownership = 39 coswid.$ownership /= coswid.shared / coswid.private / coswid.\ abandon / int / text coswid.rel = 40 coswid.$rel /= coswid.ancestor / coswid.component / coswid.feature \ / coswid.installationmedia / coswid.packageinstaller / coswid.\ parent / coswid.patches / coswid.requires / coswid.see-also / coswid\ .supersedes / coswid.supplemental / -256 .. 65536 / text coswid.media-type = 41 coswid.use = 42 coswid.$use /= coswid.optional / coswid.required / coswid.\ recommended / int / text coswid.payload = 6 coswid.payload-entry = { coswid.resource-collection, * $$payload-extension, coswid.global-attributes, } coswid.evidence = 3 coswid.evidence-entry = { coswid.resource-collection, ? coswid.date => coswid.integer-time, ? coswid.device-id => text, ? coswid.location => text, * $$evidence-extension, coswid.global-attributes, } coswid.lang = 15 coswid.any-attribute = (coswid.label => coswid.one-or-more / \ coswid.one-or-more) coswid.tag-creator = 1 coswid.software-creator = 2 coswid.aggregator = 3 coswid.distributor = 4 coswid.licensor = 5 coswid.maintainer = 6 coswid.shared = 3 coswid.private = 2 coswid.abandon = 1 coswid.ancestor = 1 coswid.component = 2 coswid.feature = 3 coswid.installationmedia = 4 coswid.packageinstaller = 5 coswid.parent = 6 coswid.patches = 7 coswid.requires = 8 coswid.see-also = 9 coswid.supersedes = 10 coswid.optional = 1 coswid.required = 2 coswid.recommended = 3 coswid.resource-collection = ( coswid.path-elements-group, ? coswid.process => coswid.one-or-more, ? coswid.resource => coswid.one-or-more, * $$resource-collection-extension, ) coswid.date = 35 coswid.integer-time = #6.1(int) coswid.device-id = 36 coswid.location = 23 coswid.label = text / int coswid.path-elements-group = ( ? coswid.directory => coswid.one-or-more, ? coswid.file => coswid.one-or-more, ) coswid.process = 18 coswid.process-entry = { coswid.process-name => text, ? coswid.pid => integer, * $$process-extension, coswid.global-attributes, } coswid.resource = 19 coswid.resource-entry = { coswid.type => text, * $$resource-extension, coswid.global-attributes, } coswid.directory = 16 coswid.directory-entry = { coswid.filesystem-item, ? coswid.path-elements => {coswid.path-elements-group}, * $$directory-extension, coswid.global-attributes, } coswid.file = 17 coswid.file-entry = { coswid.filesystem-item, ? coswid.size => uint, ? coswid.file-version => text, ? coswid.hash => coswid.hash-entry, * $$file-extension, coswid.global-attributes, } coswid.process-name = 27 coswid.pid = 28 coswid.type = 29 coswid.filesystem-item = ( ? coswid.key => bool, ? coswid.location => text, coswid.fs-name => text, ? coswid.root => text, ) coswid.path-elements = 26 coswid.size = 20 coswid.file-version = 21 coswid.hash = 7 coswid.key = 22 coswid.fs-name = 24 coswid.root = 25 cbor-ip.ipv4-address = bytes .size 4 cbor-ip.ipv6-address = bytes .size 16 ]]>

Acknowledgments The authors would like to thank the following people for their review and comments on this document: , , , , , , , , , and .

Contributors Universität Bremen TZI

cabo@tzi.org

Carsten Bormann contributed to the CDDL specifications and the IANA considerations. Altera

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. Google LLC

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. NVIDIA

sbellock@nvidia.com

Steven contributed a thorough review of the specification, with many fixes and clarifications to the CDDL, IANA considerations, Reference Verifier pseudocode and normative text.