Concise Reference Integrity Manifest

Internet-Draft	CoRIM	July 2024
Birkholz, et al.	Expires 9 January 2025	[Page]

Abstract

Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether to engage in secure interactions with it - or not. 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.¶

Table 1: Conceptual Message Representation Requirements
CM Type	Structure	Description
Evidence	List of Evidence claims	If the Attester is authenticated, add Evidence claims to the ACS with Attester authority
Reference Values	List of Reference Values claims	If a reference value in a CoRIM matches claims in the ACS, then the authority of the CoRIM issuer is added to those claims.
Endorsements	List of expected actual state claims, List of Endorsed Values claims	If the list of expected claims are in the ACS, then add the list of Endorsed Values claims to the ACS with Endorser authority
Series Endorsements	List of expected actual state claims and a series of selection-addition tuples	If the expected claims are in the ACS, and if the series selection condition is satisfied, then add the additional claims to the ACS with Endorser authority. See Section 8.2.1.3
Verifier	List of expected actual state claims, List of Verifier-generated claims	If the list of expected claims are in the ACS, then add the list of Verifier-generated claims to the ACS with Verifier authority
Policy	List of expected actual state claims, List of Policy-generated claims	If the list of expected claims are in the ACS, then add the list of Policy-generated claims to the ACS with Policy Owner authority
Attestation Results	List of expected actual state claims, List of expected Attestation Results claims	If the list of expected claims are in the ACS, then copy the list of Attestation Results claims into the ARS. See Section 8.2.3

Table 2: Type Traits & 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`

4. Concise Reference Integrity Manifest (CoRIM)

A CoRIM is a collection of tags and related metadata in a concise CBOR [STD94] encoding. A CoRIM can be digitally signed with a COSE [STD96] signature. A tag identifies and describes properties of modules or components of a system.¶

Tags can be of different types:¶

Concise Module ID (CoMID) tags (Section 5) contain metadata and claims about the hardware and firmware modules.¶
Concise Software ID (CoSWID) tags [RFC9393] describe software components.¶
Concise Bill of Material (CoBOM) tags (Section 6) contain the list of CoMID and CoSWID tags that the Verifier should consider as "active" at a certain point in time.¶

The set of tags is extensible so that future specifications can add new kinds of information. For example, Concise Trust Anchor Stores (CoTS) [I-D.ietf-rats-concise-ta-stores] is currently being defined as a standard CoRIM extension.¶

Each CoRIM contains a unique identifier to distinguish a CoRIM from other CoRIMs. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/73¶

CoRIM can also carry the following optional metadata:¶

A locator, which allows discovery of possibly related RIMs¶
A profile identifier, which is used to interpret the information contained in the enclosed tags. A profile allows the base CoRIM CDDL definition to be customized to fit a specific Attester by augmenting the base CDDL data definition via the specified extension points or by constraining types defined. A profile MUST NOT change the base CoRIM CDDL definition's semantics, which includes not changing or overloading names and numbers registered at IANA registries used by this document. For more detail, see Section 4.1.4,¶
A validity period, which indicates the time period for which the CoRIM contents are valid.¶
Information about the supply chain entities responsible for the contents of the CoRIM and their associated roles.¶

A CoRIM can be signed (Section 4.2) using COSE Sign1 to provide end-to-end security to the CoRIM contents. When CoRIM is signed, the protected header carries further identifying information about the CoRIM signer. Alternatively, CoRIM can be encoded as a CBOR-tagged payload (Section 4.1) and transported over a secure channel.¶

The following CDDL describes the top-level CoRIM.¶

corim = tagged-concise-rim-type-choice

$concise-rim-type-choice /= tagged-corim-map
$concise-rim-type-choice /= tagged-signed-corim

4.1. CoRIM Map

The CDDL specification for the corim-map is as follows and this rule and its constraints must be followed when creating or validating a CoRIM map.¶

corim-map = {
  &(id: 0) => $corim-id-type-choice
  &(tags: 1) => [ + $concise-tag-type-choice ]
  ? &(dependent-rims: 2) => [ + corim-locator-map ]
  ? &(profile: 3) => $profile-type-choice
  ? &(rim-validity: 4) => validity-map
  ? &(entities: 5) => [ + corim-entity-map ]
  * $$corim-map-extension
}

The following describes each child item of this map.¶

id (index 0): A globally unique identifier to identify a CoRIM. Described in Section 4.1.1 ¶
tags (index 1): An array of one or more CoMID or CoSWID tags. Described in Section 4.1.2 ¶
dependent-rims (index 2): One or more services supplying additional, possibly dependent, manifests or related files. Described in Section 4.1.3 ¶
profile (index 3): An optional profile identifier for the tags contained in this CoRIM. The profile MUST be understood by the CoRIM processor. Failure to recognize the profile identifier MUST result in the rejection of the entire CoRIM. If missing, the profile defaults to DICE. Described in Section 4.1.4 ¶
rim-validity (index 4): Specifies the validity period of the CoRIM. Described in Section 7.3 ¶
entities (index 5): A list of entities involved in a CoRIM life-cycle. Described in Section 4.1.5 ¶
$$corim-map-extension: This CDDL socket is used to add new information structures to the corim-map. See Section 11.3.¶

tagged-corim-map = #6.501(corim-map)

4.1.1. Identity

A CoRIM Identifier uniquely identifies a CoRIM instance. The base schema allows UUID and text identifiers. Other types of identifiers could be defined as needed.¶

$corim-id-type-choice /= tstr
$corim-id-type-choice /= uuid-type

4.1.2. Tags

A $concise-tag-type-choice is a tagged CBOR payload that carries either a CoMID (Section 5), a CoSWID [RFC9393], or a CoBOM Section 6.¶

$concise-tag-type-choice /= tagged-concise-swid-tag
$concise-tag-type-choice /= tagged-concise-mid-tag
$concise-tag-type-choice /= tagged-concise-bom-tag

4.1.3. Locator Map

The locator map contains pointers to repositories where dependent manifests, certificates, or other relevant information can be retrieved by the Verifier.¶

corim-locator-map = {
  &(href: 0) => uri
  ? &(thumbprint: 1) => digest
}

The following describes each child element of this type.¶

href (index 0): URI identifying the additional resource that can be fetched¶
thumbprint (index 1): expected digest of the resource referenced by href. See Section 7.7.¶

4.1.4. Profile Types

Profiling is the mechanism that allows the base CoRIM schema to be customised 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 (see Section 5.2). Exercised extension points should preserve the intent of the original semantics.¶

CoRIM profiles SHOULD be specified in a publicly available document.¶

A CoRIM profile can use one of the base CoRIM media types defined in Section 11.6.1 and Section 11.6.2 with the profile parameter set to the appropriate value. Alternatively, it MAY define and register its own media type.¶

A profile identifier is either an OID [RFC9090] or a URL [STD66].¶

The profile identifier uniquely identifies a documented profile. Any changes to the profile, even the slightest deviation, is considered a different profile that MUST have a different identifier.¶

$profile-type-choice /= uri
$profile-type-choice /= tagged-oid-type

For an example profile definition, see [I-D.fdb-rats-psa-endorsements].¶

4.1.5. Entities

The CoRIM Entity is an instantiation of the Entity generic (Section 7.2) using a $corim-role-type-choice.¶

The only role defined in this specification for a CoRIM Entity is manifest-creator.¶

The $$corim-entity-map-extension extension socket is empty in this specification.¶

corim-entity-map =
  entity-map<$corim-role-type-choice, $$corim-entity-map-extension>

$corim-role-type-choice /= &(manifest-creator: 1)

4.2. Signed CoRIM

signed-corim = #6.18(COSE-Sign1-corim)

Signing a CoRIM follows the procedures defined in CBOR Object Signing and Encryption [STD96]. A CoRIM tag MUST be wrapped in a COSE_Sign1 structure. The CoRIM MUST be signed by the CoRIM creator.¶

The following CDDL specification defines a restrictive subset of COSE header parameters that MUST be used in the protected header alongside additional information about the CoRIM encoded in a corim-meta-map (Section 4.2.2).¶

COSE-Sign1-corim = [
  protected: bstr .cbor protected-corim-header-map
  unprotected: unprotected-corim-header-map
  payload: bstr .cbor tagged-corim-map
  signature: bstr
]

The following describes each child element of this type.¶

protected: A CBOR Encoded protected header which is protected by the COSE signature. Contains information as given by Protected Header Map below.¶
unprotected: A COSE header that is not protected by COSE signature.¶
payload: A CBOR encoded tagged CoRIM.¶
signature: A COSE signature block which is the signature over the protected and payload components of the signed CoRIM.¶

4.2.1. Protected Header Map

protected-corim-header-map = {
  &(alg: 1) => int
  &(content-type: 3) => "application/corim-unsigned+cbor"
  &(kid: 4) => bstr
  &(corim-meta: 8) => bstr .cbor corim-meta-map
  * cose-label => cose-value
}

The CoRIM protected header map uses some common COSE header parameters plus an additional corim-meta parameter. The following describes each child item of this map.¶

alg (index 1): An integer that identifies a signature algorithm.¶
content-type (index 3): A string that represents the "MIME Content type" carried in the CoRIM payload.¶
kid (index 4): A bit string which is a key identity pertaining to the CoRIM Issuer.¶
corim-meta (index 8): A map that contains metadata associated with a signed CoRIM. Described in Section 4.2.2.¶

Additional data can be included in the COSE header map as per Section 3 of [STD96].¶

4.2.2. Meta Map

The CoRIM meta map identifies the entity or entities that create and sign the CoRIM. This ensures the consumer is able to identify credentials used to authenticate its signer.¶

corim-meta-map = {
  &(signer: 0) => corim-signer-map
  ? &(signature-validity: 1) => validity-map
}

The following describes each child item of this group.¶

signer (index 0): Information about the entity that signs the CoRIM. Described in Section 4.2.2.1 ¶
signature-validity (index 1): Validity period for the CoRIM. Described in Section 7.3 ¶

4.2.2.1. Signer Map

corim-signer-map = {
  &(signer-name: 0) => $entity-name-type-choice
  ? &(signer-uri: 1) => uri
  * $$corim-signer-map-extension
}

signer-name (index 0): Name of the organization that performs the signer role¶
signer-uri (index 1): A URI identifying the same organization¶
$$corim-signer-map-extension: Extension point for future expansion of the Signer map.¶

4.2.3. Unprotected CoRIM Header Map

unprotected-corim-header-map = {
  * cose-label => cose-value
}

5. Concise Module Identifier (CoMID)

A CoMID tag contains information about hardware, firmware, or module composition.¶

Each CoMID has a unique ID that is used to unambigously identify CoMID instances when cross referencing CoMID tags, for example in typed link relations, or in a CoBOM 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.¶

The set of triples is extensible. The following triples are currently defined:¶

Reference Values triples: containing Reference Values that are expected to match Evidence for a given Target Environment (Section 5.1.4.2).¶
Endorsed Values triples: containing "Endorsed Values", i.e., features about an Environment that do not appear in Evidence. Specific examples include testing or certification data pertaining to a module (Section 5.1.4.3).¶
Device Identity triples: containing cryptographic credentials - for example, an IDevID - uniquely identifying a device (Section 5.1.4.4).¶
Attestation Key triples: containing cryptographic keys that are used to verify the integrity protection on the Evidence received from the Attester (Section 5.1.4.5).¶
Domain dependency triples: describing trust relationships between domains, i.e., collection of related environments and their measurements (Section 5.1.4.6).¶
Domain membership triples: describing topological relationships between (sub-)modules. For example, in a composite Attester comprising multiple sub-Attesters (sub-modules), this triple can be used to define the topological relationship between lead- and sub- Attester environments (Section 5.1.4.7).¶
CoMID-CoSWID linking triples: associating a Target Environment with existing CoSWID tags (Section 5.1.4.8).¶

5.1. Structure

The CDDL specification for the concise-mid-tag map is as follows and this rule and its constraints MUST be followed when creating or validating a CoMID tag:¶

concise-mid-tag = {
  ? &(language: 0) => text
  &(tag-identity: 1) => tag-identity-map
  ? &(entities: 2) => [ + comid-entity-map ]
  ? &(linked-tags: 3) => [ + linked-tag-map ]
  &(triples: 4) => triples-map
  * $$concise-mid-tag-extension
}

The following describes each member of the concise-mid-tag map.¶

lang (index 0): A textual language tag that conforms with IANA "Language Subtag Registry" [IANA.language-subtag-registry]. The context of the specified language applies to all sibling and descendant textual values, unless a descendant object has defined a different language tag. Thus, a new context is established when a descendant object redefines a new language tag. All textual values within a given context MUST be considered expressed in the specified language.¶
tag-identity (index 1): A tag-identity-map containing unique identification information for the CoMID. Described in Section 5.1.1.¶
entities (index 2): Provides information about one or more organizations responsible for producing the CoMID tag. Described in Section 5.1.2.¶
linked-tags (index 3): A list of one or more linked-tag-map (described in Section 5.1.3), providing typed relationships between this and other CoMIDs.¶
triples (index 4): One or more triples providing information specific to the described module, e.g.: reference or endorsed values, cryptographic material, or structural relationship between the described module and other modules. Described in (Section 5.1.4).¶

5.1.1. Tag Identity

tag-identity-map = {
  &(tag-id: 0) => $tag-id-type-choice
  ? &(tag-version: 1) => tag-version-type
}

The following describes each member of the tag-identity-map.¶

tag-id (index 0): A universally unique identifier for the CoMID. Described in Section 5.1.1.1.¶
tag-version (index 1): Optional versioning information for the tag-id . Described in Section 5.1.1.2.¶

5.1.1.1. Tag ID

$tag-id-type-choice /= tstr
$tag-id-type-choice /= uuid-type

A Tag ID is either a 16-byte binary string, or a textual identifier, uniquely referencing the CoMID. The tag identifier MUST be globally unique. Failure to ensure global uniqueness can create ambiguity in tag use since the tag-id serves as the global key for matching, lookups and linking. If represented as a 16-byte binary string, the identifier MUST be a valid universally unique identifier as defined by [RFC4122]. There are no strict guidelines on how the identifier is structured, but examples include a 16-byte GUID (e.g., class 4 UUID) [RFC4122], or a URI [STD66].¶

5.1.1.2. Tag Version

tag-version-type = uint .default 0

Tag Version is an integer value that indicates the specific release revision of the tag. Typically, the initial value of this field is set to 0 and the value is increased for subsequent tags produced for the same module release. This value allows a CoMID tag producer to correct an incorrect tag previously released without indicating a change to the underlying module the tag represents. For example, the tag version could be changed to add new metadata, to correct a broken link, to add a missing reference value, etc. When producing a revised tag, the new tag-version value MUST be greater than the old tag-version value.¶

5.1.2. Entities

comid-entity-map =
  entity-map<$comid-role-type-choice, $$comid-entity-map-extension>

The CoMID Entity is an instantiation of the Entity generic (Section 7.2) using a $comid-role-type-choice.¶

The $$comid-entity-map-extension extension socket is empty in this specification.¶

$comid-role-type-choice /= &(tag-creator: 0)
$comid-role-type-choice /= &(creator: 1)
$comid-role-type-choice /= &(maintainer: 2)

The roles defined for a CoMID entity are:¶

tag-creator (value 0): creator of the CoMID tag.¶
creator (value 1): original maker of the module described by the CoMID tag.¶
maintainer (value 2): an entity making changes to the module described by the CoMID tag.¶

5.1.3. Linked Tag

The linked tag map represents a typed relationship between the embedding CoMID tag (the source) and another CoMID tag (the target).¶

linked-tag-map = {
  &(linked-tag-id: 0) => $tag-id-type-choice
  &(tag-rel: 1) => $tag-rel-type-choice
}

The following describes each member of the tag-identity-map.¶

linked-tag-id (index 0): Unique identifier for the target tag. For the definition see Section 5.1.1.1.¶
tag-rel (index 1): the kind of relation linking the source tag to the target identified by linked-tag-id.¶

$tag-rel-type-choice /= &(supplements: 0)
$tag-rel-type-choice /= &(replaces: 1)

The relations defined in this specification are:¶

supplements (value 0): the source tag provides additional information about the module described in the target tag.¶
replaces (value 1): the source tag corrects erroneous information contained in the target tag. The information in the target MUST be disregarded.¶

5.1.4. Triples

The triples-map contains all the CoMID triples broken down per category. Not all category need to be present but at least one category MUST be present and contain at least one entry.¶

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) =>
    [ + domain-dependency-triple-record ]
  ? &(membership-triples: 5) =>
    [ + domain-membership-triple-record ]
  ? &(coswid-triples: 6) =>
    [ + coswid-triple-record ]
  ? &(conditional-endorsement-series-triples: 8) =>
    [ + conditional-endorsement-series-triple-record ]
  ? &(conditional-endorsement-triples: 10) =>
    [ + conditional-endorsement-triple-record ]
  * $$triples-map-extension
}>

The following describes each member of the triples-map:¶

reference-triples (index 0): Triples containing reference values. Described in Section 5.1.4.2.¶
endorsed-triples (index 1): Triples containing endorsed values. Described in Section 5.1.4.3.¶
identity-triples (index 2): Triples containing identity credentials. Described in Section 5.1.4.4.¶
attest-key-triples (index 3): Triples containing verification keys associated with attesting environments. Described in Section 5.1.4.5.¶
dependency-triples (index 4): Triples describing trust relationships between domains. Described in Section 5.1.4.6.¶
membership-triples (index 5): Triples describing topological relationships between (sub-)modules. Described in Section 5.1.4.7.¶
coswid-triples (index 6): Triples associating modules with existing CoSWID tags. Described in Section 5.1.4.8.¶
conditional-endorsement-series-triples (index 8) Triples describing a series of conditional Endorsements based on the acceptance of a stateful environment. Described in Section 5.1.4.9.¶
conditional-endorsement-triples (index 9) Triples describing a series of Endorsement that are applicable based on the acceptance of a series of stateful environment records. Described in Section 5.1.4.10.¶

5.1.4.1. Environments

An environment-map may be used to represent a whole Attester, an Attesting Environment, or a Target Environment. The exact semantic depends on the context (triple) in which the environment is used.¶

An environment is named after a class, instance or group identifier (or a combination thereof).¶

An environment MUST be globally unique. The combination of values within class-map must combine to form a globally unique identifier.¶

environment-map = non-empty<{
  ? &(class: 0) => class-map
  ? &(instance: 1) => $instance-id-type-choice
  ? &(group: 2) => $group-id-type-choice
}>

The following describes each member of the environment-map:¶

class (index 0): Contains "class" attributes associated with the module. Described in Section 5.1.4.1.1.¶
instance (index 1): Contains a unique identifier of a module's instance. See Section 5.1.4.1.2.¶
group (index 2): identifier for a group of instances, e.g., if an anonymization scheme is used.¶

5.1.4.1.1. 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-map = non-empty<{
  ? &(class-id: 0) => $class-id-type-choice
  ? &(vendor: 1) => tstr
  ? &(model: 2) => tstr
  ? &(layer: 3) => uint
  ? &(index: 4) => uint
}>

$class-id-type-choice /= tagged-oid-type
$class-id-type-choice /= tagged-uuid-type
$class-id-type-choice /= tagged-bytes

The following describes each member of the class-map:¶

class-id (index 0): Identifies the environment via a well-known identifier. Typically, class-id is an object identifier (OID) variable-length opaque byte string (Section 7.8) or universally unique identifier (UUID). Use of this attribute is preferred.¶
vendor (index 1): Identifies the entity responsible for choosing values for the other class attributes that do not already have naming authority.¶
model (index 2): Describes a product, generation, and family. If populated, vendor MUST also be populated.¶
layer (index 3): Is used to capture where in a sequence the environment exists. For example, the order in which bootstrap code is executed may have security relevance.¶
index (index 4): Is used when there are clones (i.e., multiple instances) of the same class of environment. Each clone is given a different index value to disambiguate it from the other clones. For example, given a chassis with several network interface controllers (NIC), each NIC can be given a different index value.¶

5.1.4.1.2. Environment Instance

An instance carries a unique identifier that is reliably bound to a Target Environment that is an instance of the Attester.¶

The types defined for an instance identifier are CBOR tagged expressions of UEID, UUID, variable-length opaque byte string (Section 7.8), or cryptographic key identifier.¶

$instance-id-type-choice /= tagged-ueid-type
$instance-id-type-choice /= tagged-uuid-type
$instance-id-type-choice /= $crypto-key-type-choice
$instance-id-type-choice /= tagged-bytes

5.1.4.1.3. Environment Group

A group carries a unique identifier that is reliably bound to a group of Attesters, for example when a number of Attester are hidden in the same anonymity set.¶

The types defined for a group identified are UUID and variable-length opaque byte string (Section 7.8).¶

$group-id-type-choice /= tagged-uuid-type
$group-id-type-choice /= tagged-bytes

5.1.4.1.4. 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 the 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.¶

The supply chain entity that is responsible for providing the the measurements (i.e. Reference Values or Endorsed Values) is by default the CoRIM signer. If a different entity is authorized to provide measurement values, the authorized-by statement can be supplied in the measurement-map.¶

measurement-map = {
  ? &(mkey: 0) => $measured-element-type-choice
  &(mval: 1) => measurement-values-map
  ? &(authorized-by: 2) => [ + $crypto-key-type-choice ]
}

The following describes each member of the measurement-map:¶

mkey (index 0): An optional unique identifier of the measured (sub-)environment. See Section 5.1.4.1.4.1.¶
mval (index 1): The measurements associated with the (sub-)environment. Described in Section 5.1.4.1.4.2.¶
authorized-by (index 2): The cryptographic identity of the individual or organization that is the designated authority for this measurement. For example, producer of the measurement or a delegated supplier.¶

5.1.4.1.4.1. Measurement Keys

The types defined for a measurement identifier are OID, UUID or uint.¶

$measured-element-type-choice /= tagged-oid-type
$measured-element-type-choice /= tagged-uuid-type
$measured-element-type-choice /= uint

5.1.4.1.4.2. Measurement Values

A measurement-values-map contains measurements associated with a certain environment. Depending on the context (triple) in which they are found, elements in a measurement-values-map can represent class or instance measurements. Note that some of the elements have instance scope only.¶

Measurement values may support use cases beyond Verifier appraisal. Typically, a Relying Party determines if additional processing is desirable and whether the processing is applied by the Verifier or the Relying Party.¶

measurement-values-map = non-empty<{
  ? &(version: 0) => version-map
  ? &(svn: 1) => svn-type-choice
  ? &(digests: 2) => digests-type
  ? &(flags: 3) => flags-map
  ? (
      &(raw-value: 4) => $raw-value-type-choice,
      ? &(raw-value-mask: 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
  * $$measurement-values-map-extension
}>

The following describes each member of the measurement-values-map.¶

version (index 0): Typically changes whenever the measured environment is updated. Described in Section 5.1.4.1.4.3.¶
svn (index 1): The security version number typically changes only when a security relevant change is made to the measured environment. Described in Section 5.1.4.1.4.4.¶
digests (index 2): Contains the digest(s) of the measured environment together with the respective hash algorithm used in the process. It uses the digests-type described in Section 7.7.¶
flags (index 3): Describes security relevant operational modes. For example, whether the environment is in a debug mode, recovery mode, not fully configured, not secure, not replay protected or not integrity protected. The flags field indicates which operational modes are currently associated with measured environment. Described in Section 5.1.4.1.4.5.¶
raw-value (index 4): Contains the actual (not hashed) value of the element. An optional raw-value-mask (index 5) indicates which bits in the raw-value field are relevant for verification. A mask of all ones ("1") means all bits in the raw-value field are relevant. Multiple values could be combined to create a single raw-value attribute. The vendor determines how to pack multiple values into a single raw-value structure. The same packing format is used when collecting Evidence so that Reference Values and collected values are bit-wise comparable. The vendor determines the encoding of raw-value and the corresponding raw-value-mask.¶
mac-addr (index 6): A EUI-48 or EUI-64 MAC address associated with the measured environment. Described in Section 5.1.4.1.4.7.¶
ip-addr (index 7): An IPv4 or IPv6 address associated with the measured environment. Described in Section 5.1.4.1.4.7.¶
serial-number (index 8): A text string representing the product serial number.¶
ueid (index 9): UEID associated with the measured environment. See Section 7.5.¶
uuid (index 10): UUID associated with the measured environment. See Section 7.4.¶
name (index 11): a name associated with the measured environment.¶
cryptokeys (index 13): identifies cryptographic keys that are protected by the Target Environment See Section 5.1.4.1.5 for the supported formats. An Attesting Environment determines that keys are protected as part of Claims collection. Appraisal verifies that, for each value in cryptokeys, there is a matching Reference Value entry. Matching is described in Section 8.11.2.1.4.¶
integrity-registers (index 14): A group of one or more named measurements associated with the environment. Described in Section 5.1.4.1.6.¶

5.1.4.1.4.3. Version

A version-map contains details about the versioning of a measured environment.¶

version-map = {
  &(version: 0) => text
  ? &(version-scheme: 1) => $version-scheme
}

The following describes each member of the version-map:¶

version (index 0): the version string¶
version-scheme (index 1): an optional indicator of the versioning convention used in the version attribute. Defined in Section 4.1 of [RFC9393]. The CDDL is copied below for convenience.¶

$version-scheme /= &(multipartnumeric: 1)
$version-scheme /= &(multipartnumeric-suffix: 2)
$version-scheme /= &(alphanumeric: 3)
$version-scheme /= &(decimal: 4)
$version-scheme /= &(semver: 16384)
$version-scheme /= int / text

5.1.4.1.4.4. Security Version Number

The following details the security version number (svn) and the minimum security version number (min-svn) statements. A security version number is used to track changes to an object (e.g., a secure enclave, a boot loader executable, a configuration file, etc.) that are security relevant. Rollback of a security relevant change is considered to be an attack vector, as such, security version numbers can't be decremented. If a security relevant flaw is discovered in the Target Environment and subsequently fiexed, the svn value is typically incremented.¶

There may be several revisions to a Target Environment that are in use at the same time. If there are multiple revisions with different svn values, the revision with a lower svn value may or may not be in a security critical condition. The Endorser may provide a minimum security version number using min-svn to specify the lowest svn value that is acceptable. svn values that are equal to or greater than min-svn do not signal a security critical condition. svn values that are below min-svn are in a security critical condition that is unsafe for normal use.¶

The svn-type-choice measurement consists of a tagged-svn or tagged-min-svn value. The tagged-svn and tagged-min-svn tags are CBOR tags with the values #6.552 and #6.553 respectively.¶

svn-type = uint
svn = svn-type
min-svn = svn-type
tagged-svn = #6.552(svn)
tagged-min-svn = #6.553(min-svn)
svn-type-choice = tagged-svn / tagged-min-svn

5.1.4.1.4.5. Flags

The flags-map measurement describes a number of boolean operational modes. If a flags-map value is not specified, then the operational mode is unknown.¶

flags-map = {
  ? &(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
  * $$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 replay by a previous image that differs from the current image.¶
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.¶

5.1.4.1.4.6. Raw Values Types

Raw value measurements are typically vendor defined values that are checked by Verifiers for consistency only, since the security relevance is opaque to Verifiers.¶

There are two parts to a raw-value-group, a measurement and an optional mask. The default raw value measurement is of type tagged-bytes (Section 7.8). Additional raw value types can be defined, but must be CBOR tagged so that parsers can distinguish between the various semantics of type values.¶

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

When a new raw value type is defined, the convention for applying the mask is also defined. Typically, a CoRIM profile is used to define new raw values and mask semantics.¶

$raw-value-type-choice /= tagged-bytes

raw-value-mask-type = bytes

5.1.4.1.4.7. Address Types

The types or associating addressing information to a measured environment are:¶

ip-addr-type-choice = ip4-addr-type / ip6-addr-type
ip4-addr-type = bytes .size 4
ip6-addr-type = bytes .size 16

mac-addr-type-choice = eui48-addr-type / eui64-addr-type
eui48-addr-type = bytes .size 6
eui64-addr-type = bytes .size 8

5.1.4.1.5. Crypto Keys

A cryptographic key can be one of the following formats:¶

tagged-pkix-base64-key-type: PEM encoded SubjectPublicKeyInfo. Defined in Section 13 of [RFC7468].¶
tagged-pkix-base64-cert-type: PEM encoded X.509 public key certificate. Defined in Section 5 of [RFC7468].¶
tagged-pkix-base64-cert-path-type: X.509 certificate chain created by the concatenation of as many PEM encoded X.509 certificates as needed. The certificates MUST be concatenated in order so that each directly certifies the one preceding.¶
tagged-cose-key-type: CBOR encoded COSE_Key or COSE_KeySet. Defined in Section 7 of [STD96]¶

A cryptographic key digest can be one of the following formats:¶

tagged-thumbprint-type: a digest of a raw public key. The digest value may be used to find the public key if contained in a lookup table.¶
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.¶

$crypto-key-type-choice /= tagged-pkix-base64-key-type
$crypto-key-type-choice /= tagged-pkix-base64-cert-type
$crypto-key-type-choice /= tagged-pkix-base64-cert-path-type
$crypto-key-type-choice /= tagged-cose-key-type
$crypto-key-type-choice /= tagged-thumbprint-type
$crypto-key-type-choice /= tagged-cert-thumbprint-type
$crypto-key-type-choice /= tagged-cert-path-thumbprint-type

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-thumbprint-type = #6.557(digest)
tagged-cose-key-type = #6.558(COSE_KeySet / COSE_Key)
tagged-cert-thumbprint-type = #6.559(digest)
tagged-cert-path-thumbprint-type = #6.561(digest)

5.1.4.1.6. Integrity Registers

An Integrity Registers map groups together one or more measured "objects". Each measured object has a unique identifier and one or more associated digests. Identifiers are either unsigned integers or text strings and their type matters, e.g., unsigned integer 5 is distinct from the text string "5". The digests use digests-type semantics (Section 7.7).¶

integrity-register-id-type-choice = uint / text

integrity-registers = {
  + integrity-register-id-type-choice => digests-type
}

All the measured objects in an Integrity Registers map are explicitly named and the order in which they appear in the map is irrelevant. Any digests associated with a measured object represent an acceptable state for the object. Therefore, if multiple digests are provided, the acceptable state is their cross-product. For example, given the following Integrity Registers:¶

{
  0: [ [ 0, h'00' ] ],
  1: [ [ 0, h'11' ], [ 1, h'12' ] ]
}

then both¶

{
  0: [ 0, h'00' ],
  1: [ 0, h'11' ]
}

and¶

{
  0: [ 0, h'00' ],
  1: [ 1, h'12' ]
}

are acceptable states.¶

Integrity Registers can be used to model the PCRs in a TPM or vTPM, in which case the identifier is the register index, or other kinds of vendor-specific measured objects.¶

5.1.4.1.7. Domain Types

A domain is a context for bundling a collection of related environments and their measurements.¶

The following CDDL describes domain type choices.¶

$domain-type-choice /= uint
$domain-type-choice /= text
$domain-type-choice /= tagged-uuid-type
$domain-type-choice /= tagged-oid-type

The uint and text types MUST NOT be interpreted in a global scope.¶

5.1.4.2. Reference Values Triple

A Reference Values triple relates reference measurements to a Target Environment. For Reference Value Claims, the subject identifies a Target Environment, the object contains measurements, and the predicate asserts that these are the expected (i.e., reference) measurements for the Target Environment.¶

reference-triple-record = [
  environment-map
  measurement-map
]

5.1.4.3. Endorsed Values Triple

An Endorsed Values triple declares additional measurements that are valid when a Target Environment has been verified against reference measurements. For Endorsed Value Claims, the subject is either a Target or Attesting Environment, the object contains measurements, and the predicate defines semantics for how the object relates to the subject.¶

endorsed-triple-record = [
  environment-map
  measurement-map
]

5.1.4.4. Device Identity Triple

A Device Identity triple record relates one or more cryptographic keys to a device identity. The cryptographic keys are bound to or associated with a Target Environment that is within the device. The device identifier may be part of the Target Environment's environment-map or may be part of some other device identity credential, such as a certificate. The cryptographic keys are expected to be used to authenticate the device.¶

Device Identity triples instruct a Verifier to perform key validation checks, such as revocation, certificate path construction & verification, or proof of possession. The Verifier SHOULD perform offline verification of keys contained in Device Identity triples.¶

A Device Identity triple endorses that the keys were securely provisioned to the named Target Environment. 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 limit its use to device identity challenges, Verifiers SHOULD check for key use that violates usage restrictions.¶

Offline verification of keys or verification of key use restrictions MAY produce Claims that are added to the ACS. Alternatively, Verifiers MAY report key verification results as part of an error reporting function.¶

identity-triple-record = [
  environment-map
  [ + $crypto-key-type-choice ]
]

5.1.4.5. Attest Key Triple

An Attest Key triple record relates one or more cryptographic keys to an Attesting Environment. The cryptographic keys are wielded by an Attesting Environment that collects measurements from a Target Environment. The cryptographic keys sign Evidence. Attest Key triples instruct a Verifier to perform key validation checks, such as revocation, certificate path construction & verification, or proof of possession. The Verifier SHOULD perform offline verification of keys contained in Attest Key triples.¶

Attest Key triples endorse that the keys were securely provisioned to the named (identified via an environment-map) Attesting Environment. 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, Verifiers SHOULD check for key use that violates usage restrictions.¶

attest-key-triple-record = [
  environment-map
  [ + $crypto-key-type-choice ]
]

5.1.4.6. Domain Dependency Triple

A Domain Dependency triple defines trust dependencies between measurement sources. The subject identifies a domain (Section 5.1.4.1.7) that has a predicate relationship to the object containing one or more dependent domains. Dependency means the subject domain's trustworthiness properties rely on the object domain(s) trustworthiness having been established before the trustworthiness properties of the subject domain exists.¶

domain-dependency-triple-record = [
  $domain-type-choice
  [ + $domain-type-choice ]
]

5.1.4.7. Domain Membership Triple

A Domain Membership triple assigns domain membership to environments. The subject identifies a domain (Section 5.1.4.1.7) that has a predicate relationship to the object containing one or more environments. Endorsed environments (Section 5.1.4.3) membership is conditional upon successful matching of Reference Values (Section 5.1.4.2) to Evidence.¶

domain-membership-triple-record = [
  $domain-type-choice
  [ + environment-map ]
]

5.1.4.8. CoMID-CoSWID Linking Triple

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

coswid-triple-record = [
  environment-map
  [ + concise-swid-tag-id ]
]

concise-swid-tag-id = text / bstr .size 16

5.1.4.9. Conditional Endorsement Series Triple

A Conditional Endorsement Series triple uses a stateful environment, (i.e., stateful-environment-record), that identifies a Target Environment based on an environment-map plus the measurement-map measurements that have matching Evidence.¶

The stateful Target Environment is a triple subject that MUST be satisfied before the series triple object is matched.¶

; an environment with a set of measurements that must match evidence
stateful-environment-record = [
  environment-map,
  measurement-map
]

The series object is an array of conditional-series-record that has both Reference and Endorsed Values. Each conditional-series-record record is evaluated in the order it appears in the series array. The Endorsed Values are accepted if the series condition in a conditional-series-record matches the ACS. The first conditional-series-record that successfully matches an ACS Entry terminates the matching and the corresponding Endorsed Values are accepted. If none of the series conditions match an ACS Entry, the triple is not matched, and no Endorsed values are accepted.¶

The authorized-by value in measurement-map in the stateful environment, if present, applies to all measurements in the triple, including conditional-series-record records.¶

conditional-endorsement-series-triple-record = [
  stateful-environment-record
  ; order matters: the first matching record wins and halts matching
  [ + conditional-series-record ]
]

conditional-series-record = [
  ; reference values to be matched against evidence
  refv: measurement-values-map
  ; endorsed values that apply in case revf matches
  endv: measurement-values-map
]

5.1.4.10. Conditional Endorsement Triple

The semantics of the Conditional Endorsement Triple is as follows:¶

"IF accepted state matches all conds values, THEN every entry in the endorsements is added to the accepted state"¶

conditional-endorsement-triple-record = [
  conditions: [ + stateful-environment-record ]
  endorsements: [ + endorsed-triple-record ]
]

A conditional-endorsement-triple-record has the following parameters:¶

conditions: all target environments, along with a specific state, that need to match state-triples entries in the ACS for the endorsement(s) to apply¶
endorsements: endorsements that are added to the ACS state-triples if all conds match.¶

The order in which Conditional Endorsement triples are evaluated is important: different sorting may produce different end-results in the computed ACS.¶

Therefore, the set of applicable Conditional Endorsement triples MUST be topologically sorted based on the criterion that a Conditional Endorsement triple is evaluated before another if its Target Environment and Endorsement pair is found in any of the stateful environments of the subsequent triple.¶

Notes:¶

In order to give the expected result, the condition must describe the expected context completely.¶
The scope of a single Conditional Endorsement triple encompasses an arbitrary amount of environments across all layers in an Attester.¶

There are scope-related questions that need to be answered. (Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/176)¶

5.2. Extensibility

The base CORIM schema is described using CDDL [RFC8610] that can be extended only at specific allowed points known as "extension points"¶

The following types of extensions are supported in CoRIM¶

5.2.1. Map Extensions

Map Extensions provides extensibility support to CoRIM Map structures. CDDL map extensibility enables a CoRIM profile to extend the base CoRIM definition. CDDL map extension points have the form ($$NAME-extension) where "NAME" is the name of the map and '$$' signifies map extensibility. Typically, map extension requires a convention for code point naming that avoids code-point reuse. Well-known code points may be in a registry, such as CoSWID [IANA.coswid]. Non-negative integers are reserved for IANA to assign meaning globally.¶

5.2.2. Data Type Extensions

Data type extensibility has the form ($NAME-type-choice) where "NAME" is the type name and '$' signifies type extensibility.¶

Schema extensions (Map or Data Type) should be documented to facilitate interoperability. CoRIM profiles are best used to document vendor or industry defined extensions.¶

8. Appraisal of CoRIM-based Inputs

Inputs to a Verifier are mapped from their external representation to an internal representation. CoRIM defines CBOR structures and content media types for Conceptual Messages that include Endorsements and Reference Values. CoRIM data structures may be used by Evidence and Attestation Results that wish to describe overlapping structure. CoRIM-based data structures define an external representation of Conceptual Messages that are mapped to an internal representation. Appraisal processing describes both mapping transformations and Verifier reconciliation Section 2. Non-CoRIM-based data structures require mapping transformation, but these are out of scope for this document.¶

If a CoRIM profile is specified, there are a few well-defined points in the procedure where Verifier behaviour depends on the profile. The CoRIM profile MUST provide a description of the expected Verifier behavior for each of those well-defined points.¶

Verifier implementations MUST exhibit the same externally visible behavior as described in this specification. They are not required to use the same internal representation or evaluation order described by this specification.¶

8.1. Appraisal Procedure

The appraisal procedure is divided into several logical phases for clarity.¶

Phase 1: Input Validation and Transformation¶

During Phase 1, Conceptual Message inputs are cryptographically validated, such as checking digital signatures. Inputs are transformed from their external representations to an internal representation. Internal representations are staged for appraisal processing, such as populating an input queue.¶

Phase 2: Evidence Augmentation¶

During Phase 2, Evidence inputs are added to a list that describes the Attester's actual state. These inputs are added with the Attester's authority.¶

Phase 3: Reference Values Corroboration and Augmentation¶

During Phase 3, Reference Values inputs are compared with Evidence inputs. Reference Values inputs describe possible states of Attesters. If the actual state of the Attester is described by the possible Attester states, then the overlapping (corroborated) actual states are added to the Attester's actual state. These inputs are added with the Reference Value Provider's authority.¶

Phase 4: Endorsed Values Augmentation¶

During Phase 4, Endorsed Values inputs containing conditions that describe expected Attester state are processed. If the comparison is satisfied, then additional Claims about the Attester are added to the ACS. These inputs are added with the Endorser's authority.¶

Phase 5: Verifier Augmentation¶

During Phase 5, the Verifier may perform consistency, integrity, or additional validity checks.¶

These checks may result in additional Claims about the Attester that are added to the ACS. These Claims are added with the Verifier's authority.¶

Phase 6: Policy Augmentation¶

During Phase 6, appraisal policies are processed that describe Attester states that are desirable or undesirable. If these conditions exist, the policy may add additional Claims about the Attester, to the ACS. These Claims are added with the policy author's authority.¶

Phase 7: Attestation Results Production and Transformation¶

During Phase 7, the outcome of Appraisal and the set of Attester Claims that are interesting 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 transformed into an external representation suitable for consumption by a Relying Party.¶

8.2. Verifier Abstraction

This document assumes that Verifier implementations may differ. To facilitate the description of normative Verifier behavior, this document uses an abstract representation of Verifier internals.¶

The following terms are used:¶

Claim:: A piece of information, in the form of a key-value pair.¶
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.¶

[Ned] Suggest we use Environment-Properties Tuple (EPT) since the use of claim here is more focused than what is possible given the definition above.¶

reference state:: Claims that describe various alternative states of a Target Environment. Reference Values Claims typically describe various possible states due to versioning, manufactruing practices, or supplier configuration options. See also Section 2 of [I-D.ietf-rats-endorsements].¶
actual state:: Claims that describe a Target Environment instance at a given point in time. Endorsed Values and Evidence typically are Claims about actual state. An Attester may be composed of multiple components, where each component may represent a scope of appraisal. See also Section 2 of [I-D.ietf-rats-endorsements].¶
Authority:: The entity asserting that a claim is true. 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.¶
Appraisal Claims Set (ACS):: A structure that holds ECTs 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 acceptance of Claims. Typically, the entity asserting a Claim should have knowledge, expertise, or context that gives credibility to the assertion. Appraisal Policy resolves which entities are credible and under what conditions. See also "Appraisal Policy for Evidence" in [RFC9334].¶
Attestation Results Set (ARS):: A structure that holds results of Appraisal and ECTs that are to be conveyed to a Relying Party.¶

8.2.1. Internal Representation of Conceptual Messages

Conceptual Messages are the inputs to a Verifier and may include Evidence, Reference Values, Endorsed Values, or Appraisal Policy. Internal representations of Conceptual Messages are defined by Section 8.2.1.1, Section 8.2.1.2, and Section 8.2.1.3. The internal representation of Conceptual Messages are constructed from a common building block structure called Environment-Claims Tuple (ECT). Additionally, ECTs define an internal representation of the ACS and ARS. See Section 8.2.2 and Section 8.2.3.¶

ECTs have six attributes:¶

The environment.¶
The properties of the environment.¶
The authority.¶
The name space.¶
The Conceptual Message type.¶
The profile.¶

Environment (label 1):: Identifies the Target Environment. Environments are identified using instance, class, or group identifiers. Typically, composite Attester's are composed of components, each having an environment identifier.¶
Properties (label 2):: Properties of the Target Environment.¶
Authority (label 3):: Identifies the entity that issued the tuple. A certain type of key material by which the authority (and corresponding provenance) of the tuple can be determined, such as the public key of an asymmetric key pair that is associated with an authority's PKIX certificate.¶
Name Space (label 4):: Identifies the name space from which the tuple was created.¶
CM Type (label 5):: Identifies the type of Conceptual Message that originated the tuple.¶
Profile (label 6):: The profile that defines this tuple. If no profile is used, this attribute is omitted.¶

ECT = {
  ? e: environment-map
  ? c: claims-map / [ + local-claim ]
  ? a: [ + $crypto-key-type-choice ]
  ? ns: text
  ? cm: cm-type
  ? p: $profile-type-choice
}
local-claim = {
  le: local-environment
  c: claims-map
}
local-environment =  bstr / tstr
cm-type =  &(
  reference-values: 0
  endorsements: 1
  evidence: 2
  attestation-results: 3
  verifier: 4
  policy: 5
)

Although all of the ECT attributes are optional, the Conceptual Message type implies certain attributes are mandatory. See Section 8.2.1.1, Section 8.2.1.2, and Section 8.2.1.3.¶

8.2.1.1. Internal Representation of Evidence

An internal representation of attestation Evidence uses the ae relation.¶

The addition is a list of ECTs with Evidence to be appraised.¶

A Verifier may maintain multiple simultaneous sessions to different Attesters. Each Attester has a different ACS. The Verifier ensures the Evidence inputs are associated with the correct ACS. The addition is added to the ACS for a specific Attester.¶

ae = [
  addition: [ + ECT ]
]

Table 3: Mandatory fields for Evidence tuples
Type	e	c	a	ns	cm	p
addition	T	T	T	F	T	F

'T' means mandatory.¶

8.2.1.2. Internal Representation of Reference Values

An internal representation of Reference Values uses the rv relation, which is a list of ECTs that contains possible states and a list of ECTs that contain actual states asserted with RVP authority.¶

The rv relation is a list of condition-addition pairings where each pairing is evaluated together. If the condition containing reference ECTs overlaps Evidence ECTs then the Evidence ECTs are re-asserted, but with RVP authority as contained in the addition.¶

The reference ECTs define the matching conditions that are applied to Evidence ECTs. If the matching condition is satisfied, then the re-asserted ECTs are added to the ACS.¶

rv = + {
  condition: ECT
  addition: ECT
}

Table 4: Mandatory fields for Reference Values tuples
Type	e	c	a	ns	cm	p
condition	T	T	F	F	F	F
addition	T	T	T	F	T	F

8.2.1.3. Internal Representation of Endorsed Values

An internal representation of Endorsed Values uses the ev and evs relations, which are lists of ECTs that describe matching conditions and the additions that are added if the conditions are satisfied.¶

The ev relation compares the condition ECTs to the ACS and if all of the ECTs are found in the ACS then the addition ECTs are added to the ACS.¶

The evs relation compares the condition ECTs to the ACS and if all of the ECTs are found in the ACS then each entry in the series list is evaluated. The selection ECTs are compared with the ACS and if the selection criteria is satisfied, then the addition ECTs are added to the ACS and evaluation of the series ends. If the selection criteria is not satisfied, then evaluation procedes to the next series list entry.¶

ev = [
  condition: [ + ECT ]
  addition: [ + ECT ]
]
evs = [
  condition: [ + ECT ]
  series: + {
    selection: [ + ECT ]
    addition: [ + ECT ]
  }
]

Table 5: Mandatory fields for Endorsed Values tuples
Type	e	c	a	ns	cm	p
condition	F	T	F	F	F	F
selection	F	T	F	F	F	F
addition	T	T	T	F	T	F

8.2.1.4. Internal Representation of Policy Statements

The policy relation compares the condition ECTs to the ACS. If all of the ECTs are found in the ACS then the addition ECTs are added to the ACS with the policy author's authority.¶

policy = [
    condition: [ + ECT ]
    addition: [ + ECT ]
]

Table 6: Mandatory fields for policy tuples
Type	e	c	a	ns	cm	p
condition	F	F	F	F	F	F
addition	T	T	T	F	T	F

8.2.1.5. Internal Representation of Attestation Results

The ar relation compares the acs-condition to the ACS. If the condition is satisfied, the ars-additions are copied from the ACS to the ARS. If any of the ars-additions are not found in the ACS then these ACS entries are not copied to the ARS.¶

ar = [
    acs-condition: [ + ECT ]
    ars-addition: [ + ECT ]
]

Table 7: Mandatory fields for Attestation Results tuples
Type	e	c	a	ns	cm	p
acs-condition	F	F	F	F	F	F
ars-addition	T	T	T	F	F	F

8.2.2. Internal Representation of ACS

An ACS is a list of ECTs that describe an Attester's actual state.¶

ACS = [ + ECT ]

8.2.3. Internal Representation of Attestation Results Set (ARS)

An ARS is a list of ECTs that describe ACS entries that are selected for use as Attestation Results.¶

ARS = [ + ECT ]

8.3. Input Validation and Transformationn (Phase 1)

During the initialization phase, the CoRIM Appraisal Context is loaded with various conceptual message inputs such as CoMID tags Section 5, CoSWID tags [RFC9393], CoBOM Section 6 and cryptographic validation key material (including raw public keys, root certificates, intermediate CA certificate chains, and Concise Trust Anchor Stores (CoTS, [I-D.ietf-rats-concise-ta-stores])). These objects will be utilized in the Evidence Appraisal phase that follows. The primary goal of this phase is to ensure that all necessary information is available for subsequent processing.¶

After context initialization, additional inputs are held back until appraisal processing has completed.¶

8.3.1. Input Validation

8.3.1.1. CoRIM Selection

All available CoRIMs are collected.¶

CoRIMs that are not within their validity period, or that cannot be associated with an authenticated and authorised source MUST be discarded.¶

Any CoRIM that has been secured by a cryptographic mechanism, such as a signature, that fails validation MUST be discarded.¶

Other selection criteria MAY be applied. For example, if the Evidence format is known in advance, CoRIMs using a profile that is not understood by a Verifier can be readily discarded.¶

The selection process MUST yield at least one usable tag.¶

Later stages will further select the CoRIMs appropriate to the Evidence Appraisal stage.¶

8.3.1.2. Tags Extraction and Validation

The Verifier chooses tags from the selected CoRIMs - including CoMID, CoSWID, CoBOM, and CoTS.¶

The Verifier MUST discard all tags which are not syntactically and semantically valid. In particular, any cross-referenced triples (e.g., CoMID-CoSWID linking triples) MUST be successfully resolved.¶

8.3.1.3. CoBOM Extraction

This section is not applicable if the Verifier appraisal policy does not require CoBOMs.¶

CoBOMs which are not within their validity period are discarded.¶

The Verifier processes all CoBOMs that are valid at the point in time of Evidence Appraisal and activates all tags referenced therein.¶

A Verifier MAY decide to discard some of the available and valid CoBOMs depending on any locally configured authorization policies. (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 (Section 3.3 of [RFC9334]) is likely to be fully described by multiple CoRIMs, each signed by a different supplier. In such case, the Verifier Owner may instruct the Verifier to discard tags activated by supplier CoBOMs that are not also activated by the trusted integrator.¶

After the Verifier has processed all CoBOMs it MUST discard any tags which have not been activated by a CoBOM.¶

8.3.2. Evidence Collection

During the Evidence collection phase, the Verifier communicates with Attesters to gather Evidence. The first part of this phase does not require any cryptographic validation. This means that Verifiers can use untrusted code to discover Evidence sources. Attesters are Evidence sources.¶

Verifiers may rely on conveyance protocol specific context to identify an Evidence source, which is the Evidence input oracle for appraisal.¶

The collected Evidence is then transformed to an internal representation, making it suitable for appraisal processing.¶

8.3.2.1. Cryptographic Validation of Evidence

If Evidence is cryptographically signed, its validation is applied before transforming Evidence to an internal representation.¶

If Evidence is not cryptographically signed, the security context of the conveyance protocol that collected it is used to cryptographically validate Evidence.¶

The way cryptographic signature validation works depends on the specific Evidence collection method used. For instance, in DICE, a proof of liveness is carried out on the final key in the certificate chain (a.k.a., the alias certificate). If this is successful, a suitable certification path is looked up in the Appraisal Context, based on linking information obtained from the DeviceID certificate (see Section 9.2.1 of [DICE.Layer]). If a trusted root certificate is found, the usual X.509 certificate validation is performed.¶

As a second example, in PSA [I-D.tschofenig-rats-psa-token] the verification public key is looked up in the appraisal context using the ueid claim found in the PSA claims-set. If found, COSE Sign1 verification is performed accordingly.¶

Regardless of the specific integrity protection method used, the Evidence's integrity MUST be validated successfully.¶

If a CoRIM profile is supplied, it MUST describe:¶
- How cryptographic verification key material is represented (e.g., using Attestation Keys triples, or CoTS tags)¶
- How key material is associated with the Attesting Environment¶
- How the Attesting Environment is identified in Evidence¶

8.3.3. Input Transformation

Inputs, whether Endorsements, Reference Values, Evidence, or Policies, are transformed to an internal representation that is based on ECTs.¶

The following mapping conventions apply to all forms of input transformation: The e field is populated with a Target Environment identifier. The c field is populated with the measurements collected by an Attesting Environment. The a field is populated with the identity of the entity that asserted (e.g., signed) the Evidence. The ns field is populated with the namespace context if supplied. For example, the Attester's manufacturer may have a URI that identifies the manufacturing series, family or architecture. The cm field is set based on the type of Conceptual Message inputted or to be outputed.¶

8.3.3.1. Appraisal Context Construction

All of the extracted and validated tags are loaded into an appraisal context. The Appraisal Context contains an internal representation of the inputted Conceptual Messages. The selected tags are mapped to the internal representation, making them suitable for appraisal processing.¶

Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/96¶

8.3.3.2. Reference and Endorsed Values Tranformation

The Reference Values ECT fields are populated as described above Section 8.3.3 and {#sec-ir-ref-val}.¶

The Endorsement Values ECT fields are populated as described above Section 8.3.3 and {#sec-ir-end-val}.¶

8.3.3.3. Evidence Tranformation

Evidence is divided up into one or more ev relations where the condition ECT identifies the Attester from which Evidence was collected. If the Verifier maintains multiple Attester sessions, the Verifier session may be identified using an ECT.¶

Evidence information is mapped to an addition ECT that populates each of the ECT fields. If the Evidence doesn't have a value for the mandatory fields, the Verifier MUST NOT process the Evidence.¶

The Evidence ECT fields are populated as described above Section 8.3.3 and Section 8.2.1.1.¶

Evidence transformation algorithms may be well-known; may be defined by a CoRIM profile (Section 4.1.4); or may be supplied dynamically. The handling of dynamic Evidence transformation algorithms is out of scope for this document.¶

8.4. Evidence Augmentation (Phase 2)

8.4.1. Appraisal Claims Set Initialization

The ACS is initialized by copying the internal representation of Evidence claims to the ACS. See Section 8.10.¶

8.4.1.1. The authorized-by field in Appraisal Claims Set

The a field in an ECT in the ACS indicates the entity whose authority backs the claim.¶

An entity is authoritative when it makes Claims that are inside its area of competence. The Verifier keeps track of the authorities that assert Claims so that it can filter out claims from entities that do not satisfy appraisal policies.¶

When adding an Evidence Claim to the ACS, the Verifier SHALL set the authorized-by field in that Claim to the trusted authority keys at the head of each key chain which signed that Evidence. This key is often the subject of a self-signed certificate. The Verifier has already verified the certificate chain (see Section 8.3.2.1).¶

If multiple authorities approve the same Claim, for example if multiple key chains are available, then the authorized-by field SHALL be set to include the trusted authority keys used by each of those authorities.¶

When adding Endorsement Claims to the ACS that resulted from CoRIM processing (see Section 8.10) the Verifier SHALL set the authorized-by field in that Evidence to the trusted authority key that is at the head of the key chain that signed the CoRIM.¶

When searching the ACS for an entry which matches a Reference Value containing an authorized-by field, the Verifier SHALL ignore ACS entries if none of the keys present in the Reference Value authorized-by field are also present in the ACS authorized-by field.¶

The Verifier SHOULD set the authorized-by field in ACS entries to a format which contains only a key, for example the tagged-cose-key-type format. Using a common format makes it easier to compare the field.¶

8.4.1.2. Appraisal Claims Set augmentation using CoMID triples

In the ACS augmentation phase, a CoRIM Appraisal Context and an Evidence Appraisal Policy are used by the Verifier to find CoMID triples which match the ACS. Triples that specify an ACS matching condition will augment the ACS with Endorsements if the condition is met.¶

Each triple is processed independently of other triples. However, the ACS state may change as a result of processing a triple. If a triple condition does not match, then the Verifier continues to process other triples.¶

8.4.1.3. Ordering of triple processing

Triples interface with the ACS by either adding new ACS entries or by matching existing ACS entries before updating the ACS. Most triples use an environment-map field to select the AES entries to match or modify. This field may be contained in an explicit matching condition, such as stateful-environment-record.¶

The order of triples processing is important. Processing a triple may result in ACS modifications that affect matching behavior of other triples.¶

The Verifier MUST ensure that a triple including a matching condition is processed after any other triple that modifies or adds an ACS entry with an environment-map that is in the matching condition.¶

This can be acheived by sorting the triples before processing, by repeating processing of some triples after ACS modifications or by other algorithms.¶

8.5. Reference Values Corroboration and Augmentation (Phase 3)

Reference Value Providers (RVP) publish Reference Values triples that are matched against ACS entries. Reference Values may describe multiple acceptable states for Attesters; hence "matching" determines that Evidence (contained in the ACS) satisfies an appropriate subset of the available Reference Values. If the appropriate subset matches, the authority of the RVP is added to the appropriate ACS entries.¶

The Verifier compares each reference-triple-record against ACS entries as described in Section 8.6.1.3, where the reference-triple-record takes the place of a stateful-environment-record. If all fields of the reference-triple-record match the ACS, then the Verifier MUST add the RVP authority to each matching ACS field.¶

If any reference-triple-record in the Reference Value triple does not match the ACS then the entire triple is ignored.¶

8.6. Endorsed Values Augmentation (Phase 4)

Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/179¶

[Ned] The following sections should describe augmentation in the context of the ev and evs relations containing ECTs staged for ACS augmentation¶

8.6.1. Processing triples representing Conditional Endorsements

An Endorser may use CoMID tags to publish Conditional Endorsements, which are added to the ACS only if specified conditions are satisfied. This section describes the process performed by the Verifier to determine which Conditional Endorsements from the candidate CoMIDs should be added to the ACS.¶

The verifier checks whether Conditional Endorsements are applicable by comparing ACS entries against expected values provided in stateful-environment-record object which are part of the triple.¶

8.6.1.1. Processing Conditional Endorsement Triple

For each Conditional Endorsement Triple the Verifier compares each of the stateful-environment-record fields from the cond field in the triple against the ACS (see Section 8.6.1.3).¶

If every stateful environment matches a corresponding ACS entry, then the Verifier MUST add an Endorsement entry to the ACS (see Section 8.10) for each endorsed-triple-record in the endorsements field. Each Endorsement from the endorsed-triple-record includes the authority which signed the Conditional Endorsement Triple.¶

8.6.1.2. Processing Conditional Endorsement Series Triple

For each Conditional Endorsement Series Triple the Verifier iterates over the conditional-series-records within the triple, stopping if it finds a match.¶

For each iteration, the Verifier creates a temporary stateful-environment-record by merging the stateful-environment-record in the triple with the refv field in the conditional-series-record. It compares this temporary record against the ACS (see Section 8.6.1.3).¶

If one of the temporary records matches then the Verifier MUST add the endv Endorsement entry to the ACS. This Endorsement includes the authority which signed the Conditional Endorsement Series Triple.¶

8.6.1.3. Processing a stateful environment against the Appraisal Claims Set

This section describes how a stateful environment is matched against an ACS entry. If any part of the processing indicates that the stateful environment does not match then the remaining steps in this section are skipped for that stateful environment.¶

The Verifier initializes a temporary "candidate entries" variable with all entries in the ACS where the stateful enviromnment environment-map is a subset of the ACS environment-map.¶

A stateful environment environment-map is a subset of an ACS entry environment-map if each field (for example class, instance etc.) which is present in the stateful environment environment-map is also present in the ACS entry, and the CBOR encoded field values in the stateful environment and ACS entry are binary identical. If a field is not present in the stateful environment environment-map then the presence of, and value of, the corresponding ACS entry field does not affect whether the environment-maps are subsets.¶

Before performing the binary comparison, a Verifier SHOULD convert environment-map fields into a form which meets CBOR Core Deterministic Encoding Requirements [STD94].¶

If the stateful environment contains an authorized-by field then the Verifier SHALL remove all candidate entries whose authorized-by field does not contain one of the keys listed in the stateful environment authorized-by field (see Section 8.4.1.1 for more details).¶

If there are no candidate entries then the triple containing the stateful environment does not match.¶

The stateful environment entry is compared against each of the candidate entries.¶

For each of the candidate entries, the Verifier SHALL iterate over the codepoints which are present in the measurement-values-map field within the stateful environment measurement-map. Each of the codepoints present in the stateful environment is compared against the candidate entry.¶

If any codepoint present in the stateful environment measurement-values-map does not match the same codepoint within the candidate entry measurement-values-map then the stateful environment does not match.¶

If all checks above have been performed successfully then the stateful environment matches. If none of the candidate entries match the stateful environment entry then the stateful environment does not match.¶

8.7. Verifier Augmentation (Phase 5)

8.8. Policy Augmentation (Phase 6)

8.9. Attestation Results Production and Transformationn (Phase 7)

8.10. Adding to the Appraisal Claims Set

8.10.1. Appraisal Claims Set Requirements

At the end of the Evidence collection process Evidence has been converted into an internal represenetation suitable for appraisal. See Section 8.2.1.¶

Verifiers are not required to use this as their internal representation. For the purposes of this document, appraisal is described in terms of the above cited internal representation.¶

Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/232¶

The ACS contains the actual state of Attester's Target Environments (TEs). The state-triples field contains Evidence (from Attesters) and Endorsements (e.g. from endorsed-triple-record).¶

CoMID Reference Values will be matched against the ACS, as per the appraisal policy of the Verifier. This document describes an example evidence structure which can be easily matched against these Reference Values.¶

Each entry within state-triples uses the syntax of endorsed-triple-record. When an endorsed-triple-record appears within state-triples it indicates that the authority named by measurement-map/authorized-by asserts that the actual state of one or more Claims within the Target Environment, as identified by environment-map, have the measurement values in measurement-map/mval.¶

ECT authority is represented by cryptographic keys. Authority is asserted by digitally signing a Claim using the key. Hence, Claims are added to the ACS under the authority of a cryptographic key.¶

Each Claim is encoded as an ECT. The environment-map and a key within measurement-values-map encode the name of the Claim. The value matching that key within measurement-values-map is the actual state of the Claim.¶

This specification does not assign special meanings to any Claim name, it only specifies rules for determining when two Claim names are the same.¶

If two Claims have the same environment-map encoding then this does not trigger special encoding in the Verifier. The Verifier follows instructions in the CoRIM file which tell it how claims are related.¶

If Evidence or Endorsements from different sources has the same environment-map and authorized-by then the measurement-values-maps are merged.¶

The ACS must maintain the authority information for each ECT. There can be multiple entries in state-triples which have the same environment-map and a different authority (see Section 8.4.1.1).¶

If the merged measurement-values-map contains duplicate codepoints and the measurement values are equivalent, then duplicate claims SHOULD be omitted. Equivalence typically means values MUST be binary identical.¶

If the merged measurement-values-map contains duplicate codepoints and the measurement values are not equivalent then the verifier SHALL report an error and stop validation processing.¶

8.10.2. ACS Augmentation

The ordering of ECTs in the ACS is not significant. Logically, new ECT entries are appended to the existing ACS. But implementations may optimize ECT order to achieve better performance. Additions to the ACS MUST be atomic.¶

8.11. ECT Comparison

Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/71¶

This specification defines the comparison algorithm for the codepoints and CBOR tagged values described in sub-sections below. A CoRIM profile may define additional tags and their matching algorithms. Specifications that extend CoMID MUST also define comparison algorithms for the extended values. Any new codepoints requiring non-default comparison MUST add a CBOR tag to the extension that describs the desired behaviour.¶

8.11.1. Environment Comparison

8.11.2. Claims Comparison

8.11.2.1. Comparison of measurement-values-map

This section describes the algorithm used to compare the measurement-values-map codepoints of an ECT with another ECT. The comparison algorithm performed depends on the value of the codepoint being compared.¶

Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/203¶

If the measurement-values-map value has an associated CBOR tag. The comparison algorithm should comprehend the structure identified by the CBOR tag.¶

If the stateful environment measurement-values-map value is tagged with a CBOR tag [STD94] then the Verifier MUST use the comparison algorithm associated with that tag.¶

If the value is not tagged then the Verifier MUST use the comparison algorithm associated with the measurement-values-map codepoint for the entry.¶

If the Verifier does not recognize the stateful environment CBOR tag value then the stateful environment does not match.¶

If the stateful environment is not tagged and the measurement-values-map key is a value with handling described in the sub-sections below, then the algorithm appropriate to that key is used to match the entries.¶

If the stateful environment is not tagged, and the measurement-values-map key is not a value described below, then the entries are compared using binary comparison of their CBOR encoded values. If the values are not binary identical then the stateful environment does not match.¶

8.11.2.1.1. Comparison for svn entries

The value stored under measurement-values-map key 1 is an SVN, which must have type UINT.¶

If the Reference value for measurement-values-map key 1 is an untagged UINT or a UINT tagged with #6.552 then an equality comparison is performed. If the value of the SVN in ACS is not equal to the value in the Reference Value then the Reference Value does not match.¶

If the Reference value for measurement-values-map key 1 is a UINT tagged with #6.553 then a minimum comparison is performed. If the value of the SVN in ACS less than the value in the Reference Value then the Reference Value does not match.¶

8.11.2.1.2. Comparison for digests entries

The value stored under measurement-values-map key 2, or a value tagged with #6.TBD is a digest entry. It contains one or more digests, each measuring the same object. A Reference Value may contain multiple digests, each with a different algorithm acceptable to the Reference Value provider. If the digest in Evidence contains a single value with an algorithm and value matching one of the algorithms and values in the Reference Value then it matches.¶

To prevent downgrade attacks, if there are multiple algorithms which are in both the Evidence and Reference Value then the digests calculated using all shared algorithms must match.¶

If the CBOR encoding of the digests entry in the Reference Value or the ACS value with the same key is incorrect (for example if fields are missing or the wrong type) then the Reference Value does not match.¶

The Verifier MUST iterate over the Reference Value digests array, locating hash algorithm identifiers that are present in the Reference Value and in the ACS entry.¶

If the hash algorithm identifier which is present in the Reference Value differs from the hash algorithm identifier in the ACS entry then the Reference Value does not match.¶

If a hash algorithm identifier is present in both the Reference Value and the ACS, but the value of the hash is not binary identical between the Reference Value and the ACS entry then the Reference Value does not match.¶

8.11.2.1.3. Comparison for raw-value entries

[Andy] I think this comparison method only works if the entry is at key 4 (because there needs to be a mask at key 5). Should we have a Reference Value of this which stores [expect-raw-value raw-value-mask] in an array?¶

Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/71¶

8.11.2.1.4. Comparison for cryptokeys entries

The value stored under measurement-values-map key 12 is an array of $crypto-key-type-choice entries. $crypto-key-type-choice entries are CBOR tagged values. The array contains one or more entries in sequence.¶

The CBOR tag of the first entry of the Reference Value cryptokeys array is compared with the CBOR tag of the first entry of the ACS cryptokeys value. If the CBOR tags match, then the bytes following the CBOR tag from the Reference Value entry are compared with the bytes following the CBOR tag from the ACS entry. If the byte strings match, and there is another array entry, then the next entry from the Reference Values array is likewise compared with the next entry of the ACS array. If all entries of the Reference Values array match a corresponding entry in the ACS array, then the cryptokeys Reference Value matches. Otherwise, cryptokeys does not match.¶

8.11.2.1.5. Comparison for Integrity Registers

For each Integrity Register entry in the Reference Value, the Verifier will use the associated identifier (i.e., integrity-register-id-type-choice) to look up the matching Integrity Register entry in Evidence. If no entry is found, the Reference Value does not match. Instead, if an entry is found, the digest comparison proceeds as defined in Section 8.11.2.1.2 after equivalence has been found according to Section 5.1.4.1.6. Note that it is not required for all the entries in Evidence to be used during matching: the Reference Value could consist of a subset of the device's register space. In TPM parlance, a TPM "quote" may report all PCRs in Evidence, while a Reference Value could describe a subset of PCRs.¶

Table 8
Tag	Data Item	Semantics	Reference
500	`tag`	A tagged-concise-rim-type-choice, see Section 4.1.2	RFCthis
501	`map`	A tagged-corim-map, see Section 4.1	RFCthis
502	`tag`	A tagged-signed-corim, see Section 4.2	RFCthis
503-504	`any`	Earmarked for CoRIM	RFCthis
505	`bytes`	A tagged-concise-swid-tag, see Section 4.1.2	RFCthis
506	`bytes`	A tagged-concise-mid-tag, see Section 4.1.2	RFCthis
507	`any`	Earmarked for CoRIM	RFCthis
508	`bytes`	A tagged-concise-bom-tag, see Section 4.1.2	RFCthis
509-549	`any`	Earmarked for CoRIM	RFCthis
550	`bytes .size 33`	tagged-ueid-type, see Section 7.5	RFCthis
552	`uint`	tagged-svn, see Section 5.1.4.1.4.4	RFCthis
553	`uint`	tagged-min-svn, see Section 5.1.4.1.4.4	RFCthis
554	`text`	tagged-pkix-base64-key-type, see Section 5.1.4.1.5	RFCthis
555	`text`	tagged-pkix-base64-cert-type, see Section 5.1.4.1.5	RFCthis
556	`text`	tagged-pkix-base64-cert-path-type, see Section 5.1.4.1.5	RFCthis
557	`[int/text, bytes]`	tagged-thumbprint-type, see Section 7.7	RFCthis
558	`COSE_Key/ COSE_KeySet`	tagged-cose-key-type, see Section 5.1.4.1.5	RFCthis
559	`digest`	tagged-cert-thumbprint-type, see Section 5.1.4.1.5	RFCthis
560	`bytes`	tagged-bytes, see Section 7.8	RFCthis
561	`digest`	tagged-cert-path-thumbprint-type, see Section 5.1.4.1.5	RFCthis
562-599	`any`	Earmarked for CoRIM	RFCthis

Table 9: New Media Types
Name	Template	Reference
corim-signed+cbor	application/corim-signed+cbor	RFCthis, Section 11.6.1
corim-unsigned+cbor	application/corim-unsigned+cbor	RFCthis, Section 11.6.2

Table 10: New Content-Formats
Content-Type	Content Coding	ID	Reference
application/corim-signed+cbor	-	TBD1	RFCthis
application/corim-unsigned+cbor	-	TBD2	RFCthis

corim = tagged-concise-rim-type-choice

$concise-rim-type-choice /= tagged-corim-map
$concise-rim-type-choice /= tagged-signed-corim

concise-bom-tag = {
  &(tag-identity: 0) => tag-identity-map
  &(tags-list: 1) => [ + tag-identity-map ],
  &(bom-validity: 2) => validity-map
  * $$concise-bom-tag-extension
}

$concise-tag-type-choice /= tagged-concise-swid-tag
$concise-tag-type-choice /= tagged-concise-mid-tag
$concise-tag-type-choice /= tagged-concise-bom-tag

corim-entity-map =
  entity-map<$corim-role-type-choice, $$corim-entity-map-extension>

$corim-id-type-choice /= tstr
$corim-id-type-choice /= uuid-type

corim-locator-map = {
  &(href: 0) => uri
  ? &(thumbprint: 1) => 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
}

corim-meta-map = {
  &(signer: 0) => corim-signer-map
  ? &(signature-validity: 1) => validity-map
}

$corim-role-type-choice /= &(manifest-creator: 1)

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-corim-map
  signature: bstr
]

$profile-type-choice /= uri
$profile-type-choice /= tagged-oid-type

protected-corim-header-map = {
  &(alg: 1) => int
  &(content-type: 3) => "application/corim-unsigned+cbor"
  &(kid: 4) => bstr
  &(corim-meta: 8) => bstr .cbor corim-meta-map
  * cose-label => cose-value
}

signed-corim = #6.18(COSE-Sign1-corim)

tagged-corim-map = #6.501(corim-map)


tagged-concise-rim-type-choice = #6.500($concise-rim-type-choice)

tagged-signed-corim = #6.502(signed-corim)

tagged-concise-swid-tag = #6.505(bytes .cbor concise-swid-tag)

tagged-concise-mid-tag = #6.506(bytes .cbor concise-mid-tag)

tagged-concise-bom-tag = #6.508(bytes .cbor concise-bom-tag)

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
}

accepted-claims-set = {
  &(state-triples: 0) => [ + endorsed-triple-record ]
  ? &(identity-triples: 1) => [ + identity-triple-record ]
  ? &(coswid-triples: 2) => [ + ev-coswid-triple-record ]
  * $$accepted-claims-set-extension
}

attest-key-triple-record = [
  environment-map
  [ + $crypto-key-type-choice ]
]

$class-id-type-choice /= tagged-oid-type
$class-id-type-choice /= tagged-uuid-type
$class-id-type-choice /= 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)
$comid-role-type-choice /= &(creator: 1)
$comid-role-type-choice /= &(maintainer: 2)

conditional-endorsement-series-triple-record = [
  stateful-environment-record
  ; order matters: the first matching record wins and halts matching
  [ + conditional-series-record ]
]

conditional-series-record = [
  ; reference values to be matched against evidence
  refv: measurement-values-map
  ; endorsed values that apply in case revf matches
  endv: measurement-values-map
]

COSE_KeySet = [ + COSE_Key ]

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
  [ + concise-swid-tag-id ]
]

concise-swid-tag-id = text / bstr .size 16

$crypto-key-type-choice /= tagged-pkix-base64-key-type
$crypto-key-type-choice /= tagged-pkix-base64-cert-type
$crypto-key-type-choice /= tagged-pkix-base64-cert-path-type
$crypto-key-type-choice /= tagged-cose-key-type
$crypto-key-type-choice /= tagged-thumbprint-type
$crypto-key-type-choice /= tagged-cert-thumbprint-type
$crypto-key-type-choice /= tagged-cert-path-thumbprint-type

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-thumbprint-type = #6.557(digest)
tagged-cose-key-type = #6.558(COSE_KeySet / COSE_Key)
tagged-cert-thumbprint-type = #6.559(digest)
tagged-cert-path-thumbprint-type = #6.561(digest)

domain-dependency-triple-record = [
  $domain-type-choice
  [ + $domain-type-choice ]
]

domain-membership-triple-record = [
  $domain-type-choice
  [ + environment-map ]
]

conditional-endorsement-triple-record = [
  conditions: [ + stateful-environment-record ]
  endorsements: [ + endorsed-triple-record ]
]

$domain-type-choice /= uint
$domain-type-choice /= text
$domain-type-choice /= tagged-uuid-type
$domain-type-choice /= tagged-oid-type

endorsed-triple-record = [
  environment-map
  measurement-map
]

entity-map<role-type-choice, extension-socket> = {
  &(entity-name: 0) => $entity-name-type-choice
  ? &(reg-id: 1) => uri
  &(role: 2) => [ + role-type-choice ]
  * extension-socket
}

$entity-name-type-choice /= text

environment-map = non-empty<{
  ? &(class: 0) => class-map
  ? &(instance: 1) => $instance-id-type-choice
  ? &(group: 2) => $group-id-type-choice
}>

flags-map = {
  ? &(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
  * $$flags-map-extension
}

$group-id-type-choice /= tagged-uuid-type
$group-id-type-choice /= tagged-bytes

identity-triple-record = [
  environment-map
  [ + $crypto-key-type-choice ]
]

$instance-id-type-choice /= tagged-ueid-type
$instance-id-type-choice /= tagged-uuid-type
$instance-id-type-choice /= $crypto-key-type-choice
$instance-id-type-choice /= tagged-bytes

ip-addr-type-choice = ip4-addr-type / ip6-addr-type
ip4-addr-type = bytes .size 4
ip6-addr-type = bytes .size 16

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
$measured-element-type-choice /= tagged-uuid-type
$measured-element-type-choice /= uint

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: 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
  * $$measurement-values-map-extension
}>

non-empty<M> = (M) .and ({ + any => any })

oid-type = bytes
tagged-oid-type = #6.111(oid-type)

$raw-value-type-choice /= tagged-bytes

raw-value-mask-type = bytes

reference-triple-record = [
  environment-map
  measurement-map
]

stateful-environment-record = [
  environment-map,
  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 = tagged-svn / tagged-min-svn

$tag-id-type-choice /= tstr
$tag-id-type-choice /= uuid-type

tag-identity-map = {
  &(tag-id: 0) => $tag-id-type-choice
  ? &(tag-version: 1) => tag-version-type
}

$tag-rel-type-choice /= &(supplements: 0)
$tag-rel-type-choice /= &(replaces: 1)

tag-version-type = uint .default 0

tagged-bytes = #6.560(bytes)

triples-map = non-empty<{
  ? &(reference-triples: 0) =>
    [ + reference-triple-record ]
  ? &(endorsed-triples: 1) =>
    [ + endorsed-triple-record ]
  ? &(identity-triples: 2) =>
    [ + identity-triple-record ]
  ? &(attest-key-triples: 3) =>
    [ + attest-key-triple-record ]
  ? &(dependency-triples: 4) =>
    [ + domain-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 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) => $version-scheme
}

digest = [
  alg: (int / text),
  val: bytes
]

digests-type = [ + digest ]

integrity-register-id-type-choice = uint / text

integrity-registers = {
  + integrity-register-id-type-choice => digests-type
}

concise-swid-tag = {
  tag-id => text / bstr .size 16,
  tag-version => integer,
  ? corpus => bool,
  ? patch => bool,
  ? supplemental => bool,
  software-name => text,
  ? software-version => text,
  ? version-scheme => $version-scheme,
  ? media => text,
  ? software-meta => one-or-more<software-meta-entry>,
  entity => one-or-more<entity-entry>,
  ? link => one-or-more<link-entry>,
  ? payload-or-evidence,
  * $$coswid-extension,
  global-attributes,
}

payload-or-evidence //= ( payload => payload-entry )
payload-or-evidence //= ( evidence => evidence-entry )

any-uri = uri
label = text / int

$version-scheme /= multipartnumeric
$version-scheme /= multipartnumeric-suffix
$version-scheme /= alphanumeric
$version-scheme /= decimal
$version-scheme /= semver
$version-scheme /= int / text

any-attribute = (
  label => one-or-more<text> / one-or-more<int>
)

one-or-more<T> = T / [ 2* T ]

global-attributes = (
  ? lang => text,
  * any-attribute,
)

hash-entry = [
  hash-alg-id: int,
  hash-value: bytes,
]

entity-entry = {
  entity-name => text,
  ? reg-id => any-uri,
  role => one-or-more<$role>,
  ? thumbprint => hash-entry,
  * $$entity-extension,
  global-attributes,
}

$role /= tag-creator
$role /= software-creator
$role /= aggregator
$role /= distributor
$role /= licensor
$role /= maintainer
$role /= int / text

link-entry = {
  ? artifact => text,
  href => any-uri,
  ? media => text,
  ? ownership => $ownership,
  rel => $rel,
  ? media-type => text,
  ? use => $use,
  * $$link-extension,
  global-attributes,
}

$ownership /= shared
$ownership /= private
$ownership /= abandon
$ownership /= int / text

$rel /= ancestor
$rel /= component
$rel /= feature
$rel /= installationmedia
$rel /= packageinstaller
$rel /= parent
$rel /= patches
$rel /= requires
$rel /= see-also
$rel /= supersedes
$rel /= supplemental
$rel /= -256..64436 / text

$use /= optional
$use /= required
$use /= recommended
$use /= int / text

software-meta-entry = {
  ? activation-status => text,
  ? channel-type => text,
  ? colloquial-version => text,
  ? description => text,
  ? edition => text,
  ? entitlement-data-required => bool,
  ? entitlement-key => text,
  ? generator =>  text / bstr .size 16,
  ? persistent-id => text,
  ? product => text,
  ? product-family => text,
  ? revision => text,
  ? summary => text,
  ? unspsc-code => text,
  ? unspsc-version => text,
  * $$software-meta-extension,
  global-attributes,
}

path-elements-group = ( ? directory => one-or-more<directory-entry>,
                        ? file => one-or-more<file-entry>,
                      )

resource-collection = (
  path-elements-group,
  ? process => one-or-more<process-entry>,
  ? resource => one-or-more<resource-entry>,
  * $$resource-collection-extension,
)

file-entry = {
  filesystem-item,
  ? size => uint,
  ? file-version => text,
  ? hash => hash-entry,
  * $$file-extension,
  global-attributes,
}

directory-entry = {
  filesystem-item,
  ? path-elements => { path-elements-group },
  * $$directory-extension,
  global-attributes,
}

process-entry = {
  process-name => text,
  ? pid => integer,
  * $$process-extension,
  global-attributes,
}

resource-entry = {
  type => text,
  * $$resource-extension,
  global-attributes,
}

filesystem-item = (
  ? key => bool,
  ? location => text,
  fs-name => text,
  ? root => text,
)

payload-entry = {
  resource-collection,
  * $$payload-extension,
  global-attributes,
}

evidence-entry = {
  resource-collection,
  ? date => integer-time,
  ? device-id => text,
  ? location => text,
  * $$evidence-extension,
  global-attributes,
}

integer-time = #6.1(int)

tag-id = 0
software-name = 1
entity = 2
evidence = 3
link = 4
software-meta = 5
payload = 6
hash = 7
corpus = 8
patch = 9
media = 10
supplemental = 11
tag-version = 12
software-version = 13
version-scheme = 14
lang = 15
directory = 16
file = 17
process = 18
resource = 19
size = 20
file-version = 21
key = 22
location = 23
fs-name = 24
root = 25
path-elements = 26
process-name = 27
pid = 28
type = 29
entity-name = 31
reg-id = 32
role = 33
thumbprint = 34
date = 35
device-id = 36
artifact = 37
href = 38
ownership = 39
rel = 40
media-type = 41
use = 42
activation-status = 43
channel-type = 44
colloquial-version = 45
description = 46
edition = 47
entitlement-data-required = 48
entitlement-key = 49
generator = 50
persistent-id = 51
product = 52
product-family = 53
revision = 54
summary = 55
unspsc-code = 56
unspsc-version = 57

multipartnumeric = 1
multipartnumeric-suffix = 2
alphanumeric = 3
decimal = 4
semver = 16384

tag-creator=1
software-creator=2
aggregator=3
distributor=4
licensor=5
maintainer=6

abandon=1
private=2
shared=3

ancestor=1
component=2
feature=3
installationmedia=4
packageinstaller=5
parent=6
patches=7
requires=8
see-also=9
supersedes=10

optional=1
required=2
recommended=3

# Contributors The authors would like to thank the following members for their valuable contributions to the specification.¶

Andrew Draper¶

Email: andrew.draper@intel.com¶

Dionna Glaze¶

Email: dionnaglaze@google.com¶