Concise Reference Integrity Manifest

Concise Reference Integrity Manifest Fraunhofer SIT

henk.birkholz@ietf.contact

arm

Thomas.Fossati@arm.com

arm

yogesh.deshpande@arm.com

Intel

ned.smith@intel.com

Huawei Technologies

william.panwei@huawei.com

Security Remote ATtestation ProcedureS RIM, RATS, attestation, verifier, supply chain Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format.

Introduction In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements (e.g., test results or certification data) and Reference Values (e.g., the version or digest of a firmware component) associated with the Attester. Such Endorsements and Reference Values are obtained from the relevant supply chain actors, such as manufacturers, distributors, or device owners. In a complex supply chain, it is likely that multiple actors will produce these values at different points in time. Besides, one supply chain actor will only provide the subset of characteristics that they know about the Attester. Attesters vary from one vendor to another, and for a given vendor from one product to another. Not only Attesters can evolve and therefore new measurement types need to be expressed, but an Endorser may also want to provide new security relevant attributes about an Attester at a future point in time. This document specifies Concise Reference Integrity Manifests (CoRIM) a CBOR based data model addressing the above challenges by using an extensible format common to all supply chain actors and Verifiers. CoRIM enables Verifiers to reconcile a complex and scattered supply chain into a single homogeneous view.

Terminology and Requirements Language This document uses terms and concepts defined by the RATS architecture. For a complete glossary see . The terminology from CBOR , CDDL and COSE applies; in particular, CBOR diagnostic notation is defined in and . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

CDDL Typographical Conventions The CDDL definitions in this document follow the naming conventions illustrated in . 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`

Common Types The following CDDL types are used in both CoRIM and CoMID.

Non-Empty The non-empty generic type is used to express that a map with only optional members MUST at least include one of the members. = (M) .and ({ + any => any }) ]]>

Entity The entity-map is a generic type describing an organization responsible for the contents of a manifest. It is instantiated by supplying two parameters:

A role-type-choice, i.e., a selection of roles that entities of the instantiated type can claim
An extension-socket, i.e., a CDDL socket that can be used to extend the attributes associated with entities of the instantiated type

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

entity-name (index 0): The name of entity which is responsible for the action(s) as defined by the role. $entity-name-type-choice can only be text. Other specifications can extend the $entity-name-type-choice (see ).
reg-id (index 1): A URI associated with the organization that owns the entity name
role (index 2): A type choice defining the roles that the entity is claiming. The role is supplied as a parameter at the time the entity-map generic is instantiated.
extension-socket: A CDDL socket used to add new information structures to the entity-map.

Examples of how the entity-map generic is instantiated can be found in and .

Validity A validity-map represents the time interval during which the signer warrants that it will maintain information about the status of the signed object (e.g., a manifest). In a validity-map, both ends of the interval are encoded as epoch-based date/time as per . time &(not-after: 1) => time } ]]>

not-before (index 0): the date on which the signed manifest validity period begins
not-after (index 1): the date on which the signed manifest validity period ends

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

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

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

Tagged Integer Type Used as a class identifier for the environment. It is expected that the integer value is vendor specific rather than globally meaningful. Therefore, the sibling vendor field in the class-map MUST be populated to define the namespace under which the value must be understood.

Digest A digest represents the value of a hashing operation together with the hash algorithm used. The type of the digest algorithm identifier can be either int or text. When carried as an integer value, it is interpreted according to the "Named Information Hash Algorithm Registry" . When it is carried as text, there are no requirements with regards to its format. In general, the int encoding is RECOMMENDED. The text encoding should only be used when the digest type conveys reference value measurements that are matched verbatim with Evidence that uses the same convention - e.g., ).

Tagged Bytes Type An opaque, variable-length byte string. It can be used in different contexts: as an instance, class or group identifier in an environment-map; as a raw value measurement in a measurement-values-map. Its semantics are defined by the context in which it is found, and by the overarching CoRIM profile. When used as an identifier the responsible allocator entity SHOULD ensure uniqueness within the context that it is used.

Concise Reference Integrity Manifest (CoRIM) A CoRIM is a collection of tags and related metadata as described below. Tags can be of different types:

Concise Module ID (CoMID) tags () contain metadata and claims about the hardware and firmware modules.
Concise Software ID (CoSWID) tags describe software components.
Concise Bill of Material (CoBOM) tags () 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) 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 schema to be customised to fit a specific Attester. For example, see .
A validity period, which indicates the time period for which the CoRIM contents are valid.
Information about the supply chain entities responsible for the contents of the CoRIM and their associated roles.

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

CoRIM Map The CDDL specification for the corim-map is as follows and this rule and its constraints must be followed when creating or validating a CoRIM map. $corim-id-type-choice &(tags: 1) => [ + $concise-tag-type-choice ] ? &(dependent-rims: 2) => [ + corim-locator-map ] ? &(profile: 3) => $profile-type-choice ? &(rim-validity: 4) => validity-map ? &(entities: 5) => [ + corim-entity-map ] * $$corim-map-extension } ]]> The following describes each child item of this map.

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

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.

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

Locator Map The locator map contains pointers to repositories where dependent manifests, certificates, or other relevant information can be retrieved by the Verifier. 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 .

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 a standard CoRIM type. 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 ). Exercised extension points should preserve the intent of the original semantics. CoRIM profiles SHOULD be specified in a publicly available document. A CoRIM profile can use one of the base CoRIM media types defined in and with the profile parameter set to the appropriate value. Alternatively, it MAY define and register its own media type. A profile identifier is either an OID or a URL . The profile identifier 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.

Entities The CoRIM Entity is an instantiation of the Entity generic () using a $corim-role-type-choice. The only role defined in this specification for a CoRIM Entity is manifest-creator. The $$corim-entity-map-extension extension socket is empty in this specification. $corim-role-type-choice /= &(manifest-creator: 1) ]]>

Signed CoRIM Signing a CoRIM follows the procedures defined in CBOR Object Signing and Encryption . 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 (). 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.

Protected Header Map int &(content-type: 3) => "application/corim-unsigned+cbor" &(issuer-key-id: 4) => bstr &(corim-meta: 8) => bstr .cbor corim-meta-map * cose-label => cose-value } ]]> The following describes each child item of this map.

alg-id (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.
issuer-key-id (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 .

Additional data can be included in the COSE header map as per .

Meta Map The CoRIM meta map identifies the entity or entities that create and sign the CoRIM. This ensures the consumer is able to identify credentials used to authenticate its signer. corim-signer-map ? &(signature-validity: 1) => validity-map } ]]> The following describes each child item of this group.

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

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

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

Unprotected CoRIM Header Map cose-value } ]]>

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 ().
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 ().
Device Identity triples: containing cryptographic credentials - for example, an IDevID - uniquely identifying a device ().
Attestation Key triples: containing cryptographic keys that are used to verify the integrity protection on the Evidence received from the Attester ().
Domain dependency triples: describing trust relationships between domains, i.e., collection of related environments and their measurements ().
Domain membership triples: describing topological relationships between (sub-)modules. For example, in a composite Attester comprising multiple sub-Attesters (sub-modules), this triple can be used to define the topological relationship between lead- and sub- Attester environments ().
CoMID-CoSWID linking triples: associating a Target Environment with existing CoSWID tags ().

Structure The CDDL specification for the concise-mid-tag map is as follows and this rule and its constraints MUST be followed when creating or validating a CoMID tag: text &(tag-identity: 1) => tag-identity-map ? &(entities: 2) => [ + comid-entity-map ] ? &(linked-tags: 3) => [ + linked-tag-map ] &(triples: 4) => triples-map * $$concise-mid-tag-extension } ]]> The following describes each member of the concise-mid-tag map.

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

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

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

Tag ID A Tag ID is either a 16-byte binary string, or a textual identifier, 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 . There are no strict guidelines on how the identifier is structured, but examples include a 16-byte GUID (e.g., class 4 UUID) , or a URI .

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

Entities ]]> The CoMID Entity is an instantiation of the Entity generic () using a $comid-role-type-choice. The $$comid-entity-map-extension extension socket is empty in this specification. The roles defined for a CoMID entity are:

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

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

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

The relations defined in this specification are:

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

Triples The triples-map contains all the CoMID triples broken down per category. Not all category need to be present but at least one category MUST be present and contain at least one entry. [ + 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: 9) => [ + conditional-endorsement-triple-record ] ? &(mec-endorsement-triples: 10) => [ + mec-endorsement-triple-record ] * $$triples-map-extension }> ]]> The following describes each member of the triples-map:

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

Common Types

Environment 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). class-map ? &(instance: 1) => $instance-id-type-choice ? &(group: 2) => $group-id-type-choice }> ]]> The following describes each member of the environment-map:

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

Class The Class name consists of class attributes that distinguish the class of environment from other classes. The class attributes include class-id, vendor, model, layer, and index. The CoMID author determines which attributes are needed. $class-id-type-choice ? &(vendor: 1) => tstr ? &(model: 2) => tstr ? &(layer: 3) => uint ? &(index: 4) => uint }> $class-id-type-choice /= tagged-oid-type $class-id-type-choice /= tagged-uuid-type $class-id-type-choice /= tagged-int-type $class-id-type-choice /= tagged-bytes ]]> The following describes each member of the class-map:

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

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 (), or cryptographic key identifier.

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

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. $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 .
mval (index 1): The measurements associated with the (sub-)environment. Described in .
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.

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

Measurement Values A measurement-values-map contains measurements associated with a certain environment. Depending on the context (triple) in which they are found, elements in a measurement-values-map can represent class or instance measurements. Note that some of the elements have instance scope only. Measurement values may support use cases beyond Verifier appraisal. Typically, a Relying Party determines if additional processing is desirable and whether the processing is applied by the Verifier or the Relying Party. version-map ? &(svn: 1) => svn-type-choice ? &(digests: 2) => [ + digest ] ? &(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 .
svn (index 1): The security version number typically changes only when a security relevant change is made to the measured environment. Described in .
digests (index 2): Contains the digest(s) of the measured environment together with the respective hash algorithm used in the process. See .
flags (index 3): Describes security relevant operational modes. For example, whether the environment is in a debug mode, recovery mode, not fully configured, not secure, not replay protected or not integrity protected. The flags field indicates which operational modes are currently associated with measured environment. Described in .
raw-value (index 4): Contains the actual (not hashed) value of the element. 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 .
ip-addr (index 7): An IPv4 or IPv6 address associated with the measured environment. Described in .
serial-number (index 8): A text string representing the product serial number.
ueid (index 9): UEID associated with the measured environment. See .
uuid (index 10): UUID associated with the measured environment. See .
name (index 11): a name associated with the measured environment.
cryptokeys (index 13): identifies cryptographic keys that are protected by the Target Environment See for the supported formats. An Attesting Environment determines that keys are protected as part of Claims collection. Appraisal verifies that, for each value in cryptokeys, there is a matching Reference Value entry. Matching is described in .
integrity-registers (index 14): A group of one or more named measurements associated with the environment. Described in .

Version A version-map contains details about the versioning of a measured environment. 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 . The CDDL is copied below for convenience.

Security Version Number The following details the security version number (svn) and the minimum security version number (min-svn) statements. A security version number is used to track changes to an object (e.g., a secure enclave, a boot loader executable, a configuration file, etc.) that are security relevant. Rollback of a security relevant change is considered to be an attack vector, as such, security version numbers 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.

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

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

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

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

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

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.

In a split Verifier scenario, a first Verifier may verify the signature of a cryptographic key then compute a digest of the key that is forwarded to a second Verifier. The second Verifier completes the signature verification by performing certificate path validation, revocation checks, and trust anchor checks.

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". [ + digest ] } ]]> All the measured objects in an Integrity Registers map are explicitly named and the order in which they appear in the map is irrelevant. Any digests associated with a measured object represent an acceptable state for the object. Therefore, if multiple digests are provided, the acceptable state is their cross-product. For example, given the following Integrity Registers: then both and are acceptable states. Integrity Registers can be used to model the PCRs in a TPM or vTPM, in which case the identifier is the register index, or other kinds of vendor-specific measured objects.

Domain Types A domain is a context for bundling a collection of related environments and their measurements. Three types are defined: uint and text for local scope, UUID for global scope.

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.

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.

Device Identity Triple A Device Identity triple relates one or more cryptographic keys to a device. The subject of an Identity triple uses an instance or class identifier to refer to a device, and a cryptographic key is the object. The predicate asserts that the identity is authenticated by the key. A common application for this triple is device identity.

Attestation Keys Triple An Attestation Keys triple relates one or more cryptographic keys to an Attesting Environment. The Attestation Key triple subject is an Attesting Environment whose object is a cryptographic key. The predicate asserts that the Attesting Environment signs Evidence that can be verified using the key.

Domain Dependency Triple A Domain Dependency triple defines trust dependencies between measurement sources. The subject identifies a domain () 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 Membership Triple A Domain Membership triple assigns domain membership to environments. The subject identifies a domain () that has a predicate relationship to the object containing one or more environments. Endorsed environments () membership is conditional upon successful matching of Reference Values () to Evidence.

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.

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. 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 Triple A Conditional Endorsement 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 Endorsed Values in the triple object are accepted. The authorized-by value in measurement-map in the stateful environment, if present, applies to all measurements in the triple, including those in measurement-values-map.

Multi-Environment Conditional (MEC) Endorsement Triple The semantics of the Multi-Environment Conditional (MEC) Endorsement Triple is as follows:

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

A mec-endorsement-triple-record has the following parameters:

conds: 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 MEC Endorsement triples are evaluated is important: different sorting may produce different end-results in the computed ACS. Therefore, the set of applicable MEC Endorsement triple MUST be topologically sorted based on the criterion that a MEC Endorsement triple is evaluated before another if its Target Environment and Endorsement pair is found in any of the stateful environments of the second triple. Notes:

In order to give the expected result, the condition must describe the expected context completely.
The scope of a single MEC 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)

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

Map Extensions Map Extensions 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 . Additionally, a range of code points may be reserved for vendor-specific use such as negative integers.

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.

CoBOM A Concise Bill of Material (CoBOM) object represents the signal for the Verifier to activate the listed tags. Verifier policy determines whether CoBOMs are required. When CoBOMs are required, each tag MUST be activated by a CoBOM before being processed. All the tags listed in the CoBOM MUST be activated atomically. If any tag activated by a CoBOM is not available to the Verifier, the entire CoBOM is rejected. The number of CoBOMs required in a given supply chain ecosystem is dependent on Verifier Owner's Appraisal Policy for Evidence. Corresponding policies are often driven by the complexity and nature of the use case. If a Verifier Owner has a policy that does not require CoBOM, tags within a CoRIM received by a Verifier are activated immediately and treated valid for appraisal. There may be cases when Verifier receives CoRIMs from multiple Reference Value providers and Endorsers. In such cases, a supplier (or other authorities, such as integrators) may be designated to issue a single CoBOM to activate all the tags submitted to the Verifier in these CoRIMs. In a more complex case, there may be multiple authorities that issue CoBOMs at different points in time. An Appraisal Policy for Evidence may dictate how multiple CoBOMs are to be processed within the Verifier.

Structure The CDDL specification for the concise-bom-tag map is as follows and this rule and its constraints MUST be followed when creating or validating a CoBOM tag: tag-identity-map &(tags-list: 1) => [ + tag-identity-map ], &(bom-validity: 2) => validity-map * $$concise-bom-tag-extension } ]]> The following describes each member of the concise-bom-tag map.

tag-identity (index 0): A tag-identity-map containing unique identification information for the CoBOM. Described in .
tags-list (index 1): A list of one or more tag-identity-maps identifying the CoMID and CoSWID tags that constitute the "bill of material", i.e., a complete set of verification-related information. The tags-list behaves like a signaling mechanism from the supply chain (e.g., a product vendor) to a Verifier that activates the tags in tags-list for use in the Evidence appraisal process. The activation is atomic: all tags listed in tags-list MUST be activated or no tags are activated.
bom-validity (index 2): Specifies the validity period of the CoBOM. Described in
$$concise-bom-tag-extension: This CDDL socket is used to add new information structures to the concise-bom-tag. See . The $$concise-bom-tag-extension extension socket is empty in this specification.

CoRIM-based Appraisal of Evidence The verification procedure is divided into three separate phases:

Appraisal Context initialisation
Evidence collection
Accepted Claims Set Augmentation

At a few well-defined points in the procedure, the Verifier behaviour will depend on the specific CoRIM profile. Each CoRIM profile MUST provide a description of the expected Verifier behavior for each of those well-defined points. Note that what follows describes a simplified and standard algorithm. Verifiers claiming compliance with this specification MUST exhibit the same externally visible behavior as described here, they are not required to use the same internal data structures. For example, it is expected that the resources used during the initialisation phase can be amortised across multiple appraisals.

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

Claim: A piece of information, in the form of a key-value pair.
Environment Measurement Tuple (EMT): A structure containing a set of environment Claims that describe a Target Environment and a set of measurement Claims that describe attributes of the Target Environment.
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.
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.
Group: A set of Evidence, Reference Values, Endorsed Values and Appraisal Policies which are processed together. An Attester may be composed of multiple components, where each component may represent a scope of appraisal.
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.
Accepted Claims Set (ACS): A structure that holds EMT Claims that have been vetted following the appraisal process. The ACS describes the actual state of an Attester that has been vetted by Appraisal Policy. The ACS also keeps track of a Claim's authority.
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.

Appraisal Context initialisation The goal of the initialisation phase is to load the CoRIM Appraisal Context with objects such as tags (CoMID, CoSWID, etc.) from CoRIM files, cryptographic validation key material (e.g., raw public keys, root certificates, intermediate CA certificate chains), etc. that will be used in the subsequent Evidence Appraisal phase.

CoRIM Selection All available CoRIMs are collected. A Verifier may be pre-configured with a large number of CoRIMs describing many types of device. All CoRIMs are loaded at this stage, later stages will select the CoRIMs appropriate to the Evidence Appraisal step. CoRIMs that are not within their validity period, or that cannot be associated with an authenticated and authorised source MUST be discarded. CoRIM that are secured by a cryptographic mechanism such as a signature which does not pass 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.

CoBOM Extraction This section is not applicable if the Verifier policy does not require CoBOMs. All the available Concise Bill Of Material (CoBOMs) tags are then collected from the selected CoRIMs. CoBOMs which are not within their validity period, or which reference tags not available to the verifier, 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 scope of the present document.) For example, a composite device () 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 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.

Tags Identification and Validation The Verifier chooses tags -- including Concise Module ID Tags (CoMID, ), Concise Software ID Tags (CoSWID, ), and/or Concise Trust Anchor Stores (CoTS, ) -- from the selected CoRIMs. 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.

Appraisal Context Construction All of the validated and potentially useful tags are loaded into the Appraisal Context. This concludes the initialisation phase.

Evidence Collection In the Evidence collection phase the Verifier communicates with attesters to collect Evidence. The first part of the Evidence collection phase does not perform any cryptographic validation. This allows Verifiers to use untrusted code for their initial Evidence collection. The results of the evidence collection are protocol specific data and transcripts which are used as input to appraisal by the Verifier.

Cryptographic validation of Evidence If the authenticity of Evidence is secured by a cryptographic mechanism such as a signature, the first step in the Evidence Appraisal is to perform cryptographic validation of the Evidence. The exact cryptographic signature validation mechanics depend on the specific Evidence collection protocol. For example: In DICE, a proof of liveness is performed on the final key in the certificate chain. If this passes then a suitable certification path anchored on a trusted root certificate is looked up -- e.g., based on linking information obtained from the DeviceID certificate (see Section 9.2.1 of ) -- in the Appraisal Context. If found, then usual X.509 certificate validation is performed. In PSA, the verification public key is looked up in the appraisal context using the ueid claim found in the PSA claims-set (see ). If found, COSE Sign1 verification is performed accordingly. Independent of the specific integrity protection method used, the integrity of Evidence MUST be successfully verified.

A CoRIM profile 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

The Accepted Claims Set At the end of the Evidence collection process Evidence has been converted into a format suitable for appraisal. To this end, this document describes an accepted-claims-set format and the algorithms used to compare it against CoMID Reference Values. [ + endorsed-triple-record ] ? &(identity-triples: 1) => [ + identity-triple-record ] ? &(coswid-triples: 2) => [ + ev-coswid-triple-record ] * $$accepted-claims-set-extension } ]]> Verifiers are not required to use this as their internal state, for the purposes of this document a sample Verifier is discussed which uses this format. The Accepted Claims Set (ACS) contains the actual state of 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 Accepted Claims Set, 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. In authorized-by, 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 key. Each Claim is encoded as an Environment Measurement Tuple (a contraction of environment-map, measurement-map tuple). 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 EMT. There can be multiple entries in state-triples which have the same environment-map and a different authorized-by field (see ). If the merged measurement-value-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-value-map contains duplicate codepoints and the measurement values are not equivalent then the verifier SHALL report an error and stop validation processing.

Accepted Claims Set Initialization The Accepted Claims Set is initialized by copying Evidence claims describing authenticated Attester's Target Environments into the Verifier's Accepted Claims Set. Evidence formats may require format translation before being added to the Accepted Claims Set. If format translation is required, a CoRIM profile, see , defines an Evidence translation function. provides information on how DICE and SPDM Evidence is reformatted into CoMID schema compliant expressions before being added to the Accepted Claims Set.

The authorized-by field in Accepted Claims Set The authorized-by field in an Accepted Claims Set entry 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 Accepted Claims Set, 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 ). 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 Accepted Claims Set that resulted from CoRIM processing (see ) 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 Accepted Claims Set 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 Accepted Claims Set 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.

Accepted Claims Set augmentation using CoMID triples In the Accepted Claims Set augmentation phase, a CoRIM Appraisal Context and an Evidence Appraisal Policy are used by the Verifier to find CoMID triples which match the Accepted Claims Set (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.

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.

Processing Reference Values Triple 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 , 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.

Processing Endorsed Value Triple

Processing triples representing Conditional Endorsements An Endorser may use CoMID tags to publish Conditional Endorsements, which are added to the Accepted Claims Set 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 Accepted Claims Set entries against expected values provided in stateful-environment-record object which are part of the triple.

Processing Conditional Endorsement Triple For each Conditional Endorsement Triple the Verifier compares the stateful-environment-record field in the triple against the ACS (see ). If the stateful environment matches, then the Verifier MUST add an Endorsement entry to the ACS (see ). The Endorsement consists of the measurement-values-map field in the triple, plus the authority of the entity that signed the Conditional Endorsement Triple.

Processing Multi-Environment Conditional (MEC) Endorsement Triple For each MEC Endorsement Triple the Verifier compares each of the stateful-environment-record fields from the cond field in the triple against the ACS (see ). If every stateful environment matches a corresponding ACS entry, then the Verifier MUST add an Endorsement entry to the ACS (see ) for each endorsed-triple-record in the endorsements field. Each Endorsement from the endorsed-triple-record includes the authority which signed the MEC Endorsement Triple.

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

Matching a stateful environment against the Accepted Claims Set This section describes how a stateful environment is matched against an Accepted Claims Set 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 Accepted Claims Set (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 . 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 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.

Matching a single measurement-values-map codepoint The algorithm used to match the measurement-values-map codepoints is described in this section. The comparison performed depends on the value of the codepoint being compared and whether the measurement-values-map value associated with that codepoint is tagged. If the stateful environment measurement-values-map value is tagged with a CBOR tag 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. This specification defines the matching algorithm for some codepoints and CBOR tagged values, which are described in sub-sections below. A CoRIM profile may define additional tags and their matching algorithms. 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-value-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. Note that while specifications may extend the matching semantics using CBOR tags, there is no way to extend the matching semantics of codepoints. Any new codepoints requiring non-default comparison must add a CBOR tag to the Reference Value describing the desired behaviour.

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 Accepted Claims Set 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 Accepted Claims Set less than the value in the Reference Value then the Reference Value does not match.

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 Accepted Claim Set 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 Accepted Claims Set entry. If the hash algorithm identifier which is present in the Reference Value differs from the hash algorithm identifier in the Accepted Claims Set entry then the Reference Value does not match. If a hash algorithm identifier is present in both the Reference Value and the Accepted Claims Set, but the value of the hash is not binary identical between the Reference Value and the Accepted Claims Set entry then the Reference Value does not match.

Comparison for raw-value entries

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?

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 Accepted Claims Set 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 Accepted Claims Set 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 Accepted Claims Set array. If all entries of the Reference Values array match a corresponding entry in the Accepted Claims Set array, then the cryptokeys Reference Value matches. Otherwise, cryptokeys does not match.

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

Handling of new tags A profile may specify handling for new CBOR tagged Reference Values. The profile must specify how to compare the CBOR tagged Reference Value against the Accepted Claims Set. Note that the verifier may compare Reference Values in any order, so the comparison should not be stateful.

Adding CoMID Endorsed Values to the Accepted Claims Set

Adding DICE/SPDM Evidence to the Accepted Claims Set This section defines how Evidence from DICE and/or SPDM is transformed into a format where it can be added to an accepted claims set. A Verifier supporting DICE/SPDM format Evidence should implement this section.

Transforming SPDM Evidence to a format usable for matching The TCG DICE Concise Evidence Binding for SPDM specification describes the process by which measurements in an SPDM Measurement Block are converted to Evidence suitable for matching using the rules below. The SPDM measurements are converted to concise-evidence which has a format that is similar to CoRIM triples-map (their semantics follows the matching rules described above).

Transforming DICE Evidence to a format usable for matching DICE Evidence appears in certificates in the TcbInfo or MultiTcbInfo extension. Each TcbInfo, and each entry in the MultiTcbInfo, is converted to an endorsed-triple-record using the rules in this section. In a MultiTcbInfo each entry in the sequence is treated as independent and translated into a separate Evidence object. The Verifier SHALL translate each field in the TcbInfo into a field in the created endorsed-triple-record

The TcbInfo type field SHALL be copied to the field named environment-map / class / class-id and tagged with tag #6.111
The TcbInfo vendor field SHALL be copied to the field named environment-map / class / vendor
The TcbInfo model field SHALL be copied to the field named environment-map / class / model
The TcbInfo layer field SHALL be copied to the field named environment-map / class / layer
The TcbInfo index field SHALL be copied to the field named environment-map / class / index
The TcbInfo version field SHALL be translated to the field named measurement-map / mval / version / version
The TcbInfo svn field SHALL be copied to the field named measurement-map / mval / svn
The TcbInfo fwids field SHALL be translated to the field named measurement-map / mval / digests
- Each digest within fwids is translated to a CoMID digest object, with an appropriate algorithm identifier
The TcbInfo flags field SHALL be translated to the field named measurement-map / mval / flags
- Each flag is translated independently
The TcbInfo vendorInfo SHALL shall be copied to the field named measurement-map / mval / raw-value

If there are multiple endorsed-triple-records with the same environment-map then they MUST be merged into a single entry. If the measurement-values-map fields in Evidence triples have conflicting values then the Verifier MUST fail validation.

Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalogue of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as Evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Veraison

Organization responsible for the implementation: Veraison Project, Linux Foundation
Implementation's web page: https://github.com/veraison/corim/README.md
Brief general description: The corim/corim and corim/comid packages provide a golang API for low-level manipulation of Concise Reference Integrity Manifest (CoRIM) and Concise Module Identifier (CoMID) tags respectively. The corim/cocli package uses the API above (as well as the API from the veraison/swid package) to provide a user command line interface for working with CoRIM, CoMID and CoSWID. Specifically, it allows creating, signing, verifying, displaying, uploading, and more. See https://github.com/cocli/README.md for further details.
Implementation's level of maturity: alpha.
Coverage: the whole protocol is implemented, including PSA-specific extensions .
Version compatibility: Version -02 of the draft
Licensing: Apache 2.0 https://github.com/veraison/corim/blob/main/LICENSE
Implementation experience: n/a
Contact information: https://veraison.zulipchat.com
Last updated: https://github.com/veraison/corim/commits/main

Security and Privacy Considerations Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/11

IANA Considerations

New COSE Header Parameters Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/12

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

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

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

New CoRIM Registries Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/14

New CoMID Registries Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/15

New CoBOM Registries Content missing. Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/45

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

Name	Template	Reference
corim-signed+cbor	application/corim-signed+cbor	RFCthis,
corim-unsigned+cbor	application/corim-unsigned+cbor	RFCthis,

corim-signed+cbor

Type name:: application
Subtype name:: corim-signed+cbor
Required parameters:: n/a
Optional parameters:: "profile" (CoRIM profile in string format. OIDs MUST use the dotted-decimal notation.)
Encoding considerations:: binary
Security considerations:: of RFCthis
Interoperability considerations:: n/a
Published specification:: RFCthis
Applications that use this media type:: Attestation Verifiers, Endorsers and Reference-Value providers that need to transfer COSE Sign1 wrapped CoRIM payloads over HTTP(S), CoAP(S), and other transports.
Fragment identifier considerations:: n/a
Magic number(s):: D9 01 F6 D2, D9 01 F4 D9 01 F6 D2
File extension(s):: n/a
Macintosh file type code(s):: n/a
Person & email address to contact for further information:: RATS WG mailing list (rats@ietf.org)
Intended usage:: COMMON
Restrictions on usage:: none
Author/Change controller:: IETF
Provisional registration?: Maybe

corim-unsigned+cbor

Type name:: application
Subtype name:: corim-unsigned+cbor
Required parameters:: n/a
Optional parameters:: "profile" (CoRIM profile in string format. OIDs MUST use the dotted-decimal notation.)
Encoding considerations:: binary
Security considerations:: of RFCthis
Interoperability considerations:: n/a
Published specification:: RFCthis
Applications that use this media type:: Attestation Verifiers, Endorsers and Reference-Value providers that need to transfer unprotected CoRIM payloads over HTTP(S), CoAP(S), and other transports.
Fragment identifier considerations:: n/a
Magic number(s):: D9 01 F5, D9 01 F4 D9 01 F5
File extension(s):: n/a
Macintosh file type code(s):: n/a
Person & email address to contact for further information:: RATS WG mailing list (rats@ietf.org)
Intended usage:: COMMON
Restrictions on usage:: none
Author/Change controller:: IETF
Provisional registration?: Maybe

CoAP Content-Formats Registration IANA is requested to register the two following Content-Format numbers in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry : New Content-Formats

Content-Type	Content Coding	ID	Reference
application/corim-signed+cbor	-	TBD1	RFCthis
application/corim-unsigned+cbor	-	TBD2	RFCthis

References Normative References A Universally Unique IDentifier (UUID) URN Namespace This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK] Textual Encodings of PKIX, PKCS, and CMS Structures This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate. Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Concise Binary Object Representation (CBOR) Tags for Object Identifiers The Concise Binary Object Representation (CBOR), defined in RFC 8949, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined. CBOR Object Signing and Encryption (COSE): Structures and Process Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Uniform Resource Identifier (URI): Generic Syntax A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Concise Software Identification Tags Fraunhofer SIT National Security Agency The MITRE Corporation National Institute of Standards and Technology ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format. Remote ATtestation procedureS (RATS) Architecture In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. The Entity Attestation Token (EAT) Security Theory LLC Qualcomm Technologies Inc. Red Hound Software, Inc. An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. Concise TA Stores (CoTS) Red Hound Software Vigil Security, LLC arm arm Trust anchor (TA) stores may be used for several purposes in the Remote Attestation Procedures (RATS) architecture including verifying endorsements, reference values, digital letters of approval, attestations, or public key certificates. This document describes a Concise Reference Integrity Manifest (CoRIM) extension that may be used to convey optionally constrained trust anchor stores containing optionally constrained trust anchors in support of these purposes. Language Subtag Registry IANA Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) International Telecommunications Union Named Information IANA Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Concise Binary Object Representation (CBOR) Tags IANA Media Types IANA Constrained RESTful Environments (CoRE) Parameters IANA Informative References Improving Awareness of Running Code: The Implementation Status Section This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Arm's Platform Security Architecture (PSA) Attestation Verifier Endorsements Linaro Arm Ltd Fraunhofer SIT PSA Endorsements include reference values, cryptographic key material and certification status information that a Verifier needs in order to appraise attestation Evidence produced by a PSA device. This memo defines such PSA Endorsements as a profile of the CoRIM data model. Arm's Platform Security Architecture (PSA) Attestation Token Arm Limited Arm Limited HP Labs Linaro The Arm Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, as well as open-source reference implementations, to help device makers and chip manufacturers build best-practice security into products. Devices that are PSA compliant can produce attestation tokens as described in this memo, which are the basis for many different protocols, including secure provisioning and network access control. This document specifies the PSA attestation token structure and semantics. The PSA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by PSA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected. This informational document is published as an independent submission to improve interoperability with ARM's architecture. It is not a standard nor a product of the IETF. DICE Layering Architecture Trusted Computing Group Concise Software Identifier (CoSWID) IANA Security Protocol and Data Model (SPDM) Distributed Management Task Force TCG DICE Concise Evidence Binding for SPDM Trusted Computing Group DICE Attestation Architecture Trusted Computing Group

Full CoRIM CDDL 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-id: 1) => int &(content-type: 3) => "application/corim-unsigned+cbor" &(issuer-key-id: 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-int-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-endorsement-triple-record = [ stateful-environment-record, ; endorsed values measurement-values-map ] 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 ] ] mec-endorsement-triple-record = [ conds: [ + 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 = { &(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) => [ + digest ] ? &(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) .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-int-type = #6.551(int) 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: 9) => [ + conditional-endorsement-triple-record ] ? &(mec-endorsement-triples: 10) => [ + mec-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 ] integrity-register-id-type-choice = uint / text integrity-registers = { + integrity-register-id-type-choice => [ + digest ] } 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, entity => one-or-more, ? link => one-or-more, ? 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 / one-or-more ) one-or-more = 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, ? file => one-or-more, ) resource-collection = ( path-elements-group, ? process => one-or-more, ? resource => one-or-more, * $$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 ]]>

Acknowledgments for review and comments on this document.

Contributors Universität Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

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