From d0d2e31fd6fa159aab2b23dab64967e7059af4dc Mon Sep 17 00:00:00 2001 From: ID Bot Date: Wed, 16 Oct 2024 20:21:04 +0000 Subject: [PATCH] Script updating gh-pages from 67ec31c. [ci skip] --- .../draft-ietf-rats-corim.html | 7219 +++++++++++++++++ .../draft-ietf-rats-corim.txt | 4606 +++++++++++ Section-restructuring/index.html | 45 + index.html | 8 + 4 files changed, 11878 insertions(+) create mode 100644 Section-restructuring/draft-ietf-rats-corim.html create mode 100644 Section-restructuring/draft-ietf-rats-corim.txt create mode 100644 Section-restructuring/index.html diff --git a/Section-restructuring/draft-ietf-rats-corim.html b/Section-restructuring/draft-ietf-rats-corim.html new file mode 100644 index 00000000..2caf6f5a --- /dev/null +++ b/Section-restructuring/draft-ietf-rats-corim.html @@ -0,0 +1,7219 @@ + + + + + + +Concise Reference Integrity Manifest + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Internet-DraftCoRIMOctober 2024
Birkholz, et al.Expires 19 April 2025[Page]
+
+
+
+
Workgroup:
+
Remote ATtestation ProcedureS
+
Internet-Draft:
+
draft-ietf-rats-corim-latest
+
Published:
+
+ +
+
Intended Status:
+
Standards Track
+
Expires:
+
+
Authors:
+
+
+
H. Birkholz
+
Fraunhofer SIT
+
+
+
T. Fossati
+
Linaro
+
+
+
Y. Deshpande
+
arm
+
+
+
N. Smith
+
Intel
+
+
+
W. Pan
+
Huawei Technologies
+
+
+
+
+

Concise Reference Integrity Manifest

+
+

Abstract

+

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

+
+
+

+Discussion Venues +

+

This note is to be removed before publishing as an RFC.

+

Source for this draft and an issue tracker can be found at + https://github.com/ietf-rats-wg/draft-ietf-rats-corim.

+
+
+
+

+Status of This Memo +

+

+ This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79.

+

+ Internet-Drafts are working documents of the Internet Engineering Task + Force (IETF). Note that other groups may also distribute working + documents as Internet-Drafts. The list of current Internet-Drafts is + at https://datatracker.ietf.org/drafts/current/.

+

+ Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress."

+

+ This Internet-Draft will expire on 19 April 2025.

+
+
+ +
+
+ ▲

+Table of Contents +

+ +
+
+
+
+

+1. 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. +Endorsements and Reference Values are obtained from relevant supply chain actors, such as manufacturers, distributors, or device owners. +In a complex supply chain, multiple actors will likely produce these values over several points in time. +As such, one supply chain actor will only provide the subset of characteristics that they know about the Attester. A proper subset is typical because a certain supply chain actor will be the responsible authority for only a system component/module that is measured amongst a long chain of measurements. +Attesters vary across vendors and even across products from a single vendor. +Not only Attesters can evolve and therefore new measurement types need to be expressed, but an Endorser may also want to provide new security relevant attributes about an Attester at a future point in time.

+

This document specifies Concise Reference Integrity Manifests (CoRIM) - a CBOR [STD94] 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 distributed supply chain into a single homogeneous view. +See Section 2.

+
+
+

+1.1. Terminology and Requirements Language +

+

This document uses terms and concepts defined by the RATS architecture. +For a complete glossary, see Section 4 of [RFC9334].

+

In this document, the term CoRIM message and CoRIM documents are used as synonyms. A CoRIM data structure can be at rest (e.g., residing in a file system as a document) or can be in flight (e.g., conveyed as a message in a protocol exchange). The bytes composing the CoRIM data structure are the same either way.

+

The terminology from CBOR [STD94], CDDL [RFC8610] and COSE [STD96] applies; +in particular, CBOR diagnostic notation is defined in Section 8 of [STD94] +and Appendix G of [RFC8610]. Terms and concepts are always referenced as proper nouns, i.e., with Capital Letters.

+

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL +NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", +"MAY", and "OPTIONAL" in this document are to be interpreted as +described in BCP 14 [RFC2119] [RFC8174] when, and only when, they +appear in all capitals, as shown here.

+
+
+
+
+
+
+

+2. Verifier Reconciliation +

+

This specification describes the CoRIM format and documents how a Verifier must process the CoRIM. +This ensures that the behaviour of the CoRIM-based appraisal is predictable and consistent, in a word deterministic.

+

A Verifier needs to reconcile its various inputs, with CoRIM being one of them. +In addition to the external CoRIM documents, the Verifier is expected to create an internal representation for each input and map each external representation to an internal one. +By using the internal representation, the Verifier processes inputs as if they are part of a conversation, keeping track of who said what. +The origin of the inputs is tracked as authority. +The authority for the Claims in a CoRIM is the CoRIM issuer. +To this effect, this specification defines one possible internal representation of the attester's actual state for use during the appraisal procedure, known as Appraisal Claims Set (ACS).

+

Effectively, Attesters, Reference Value Providers, Endorsers, Verifier Owners, Relying Parties, and even the Verifier potentially all contribute to the conversation. +Each producer of corresponding RATS Conceptual Messages can assert Claims about an Attester's actual or allowed state. +The Verifier's objective is to produce a list of Claims that describe the Attester's presumed actual state. +Producers of RATS Conceptual Messages can assert contradictory assertions. +For example, a compromised Attester may produce false claims that conflict with the Reference Values provided by a Reference Value Provider (RVP). +In essence, if Evidence is not corroborated by an RVP's Claims, then the RVP's Claims are not included in the ACS.

+

A Verifier relies on input from appraisal policy to identify relevant assertions included in the ACS. +For example, if a policy requires corroborated assertions issued by a particular RVP, then those assertions may be conveyed as Attestation Results. +The Verifier may produce new assertions as a result of an applied appraisal policy. +For example, if an appraisal procedure finds all of the components of a subsystem are configured correctly, the policy may direct the Verifier to produce new assertions, "Subsystem=X" has the Claim "TRUSTED=TRUE". +Consequently, the internal ACS structure is a reconciled conversation between several producers of RATS Conceptual Messages that has mapped each message into a consistent internal representation, has associated the identity of the corresponding RATS role with each assertion (the authority), and has applied Conceptual Message constraints to the assertion.

+

The CoRIM data model specified in this document covers the RATS Conceptual Message types, "Reference Values" and "Endorsements". +Reference values and Endorsements are required for Verifier reconciliation, and Evidence is required for corresponding internal ACS creation as illustrated in Section 2.2.

+
+
+

+2.1. Internal Representation +

+

In this document CDDL is used to specify both the CoRIM structure and to specify an internal representation for use in the appraisal procedure. +The actual internal representation of a Verifier is implementation-specific and out-of-scope of this document. +Requirements for an internal representation of Conceptual Messages are defined in Table 1, where each Conceptual Message type has a structure as depicted by the Structure column. +The internal representations used by this document are defined in Section 8.2.1.

+
+
+
+
+

+2.2. Interacting with an ACS +

+

Conceptual Messages interact with an ACS by specifying criteria that should be met by the ACS and by presenting the assertions that should be added to the ACS if the criteria are satisfied. +Internal representations of Conceptual Messages, ACS, and Attestation Results Set (ARS) should satisfy the following requirements for Verifier reconciliation and appraisal processing:

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

+2.3. Quantizing Inputs +

+

Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/242

+
+
+
+
+
+
+

+3. Typographical Conventions for CDDL +

+

The CDDL definitions in this document follows the naming conventions illustrated in Table 2.

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Table 2: +Type Traits and Typographical Conventions +
Type traitExampleTypographical convention
extensible type choice + int / text / ... + + $NAME-type-choice +
closed type choice + int / text +NAME-type-choice +
group choice + ( 1 => int // 2 => text ) + + $$NAME-group-choice +
group + ( 1 => int, 2 => text ) +NAME-group +
type + int +NAME-type +
tagged type + #6.123(int) + + tagged-NAME-type +
map + { 1 => int, 2 => text } +NAME-map +
flags + &( a: 1, b: 2 ) +NAME-flags +
+
+
+
+
+
+

+4. Concise Reference Integrity Manifest (CoRIM) +

+

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

+

Tags can be of different types:

+
    +
  • +

    Concise Module ID (CoMID) tags (Section 5) contain metadata and claims about the hardware and firmware modules.

    +
    • +
  • +

    Concise Software ID (CoSWID) tags ([RFC9393]) describe software components.

    +
    • +
  • +

    Concise Bill of Material (CoBOM) tags (Section 6) contain the list of CoMID and CoSWID tags that the Verifier should consider as "active" at a certain point in time.

    +
    • +
+

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

+

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

+

CoRIM can also carry the following optional metadata:

+
    +
  • +

    A locator, which allows discovery of possibly related RIMs.

    +
    • +
  • +

    A profile identifier, which is used to interpret the information contained in the enclosed tags. +A profile allows the base CoRIM CDDL definition to be customized to fit a specific Attester by augmenting the base CDDL data definition via the specified extension points or by constraining types defined. +A profile MUST NOT change the base CoRIM CDDL definition's semantics, which includes not changing or overloading names and numbers registered at IANA registries used by this document. +For more detail, see Section 4.1.4.

    +
    • +
  • +

    A validity period, which indicates the time period for which the CoRIM contents are valid.

    +
    • +
  • +

    Information about the supply chain entities responsible for the contents of the CoRIM and their associated roles.

    +
    • +
+

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

+

The following CDDL describes the top-level CoRIM.

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

+4.1. CoRIM Map +

+

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

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

The following describes each child item of this map.

+
    +
  • +

    id (index 0): A globally unique identifier to identify a CoRIM. Described +in Section 4.1.1.

    +
    • +
  • +

    tags (index 1): An array of one or more CoMID or CoSWID tags. Described +in Section 4.1.2.

    +
    • +
  • +

    dependent-rims (index 2): One or more services supplying additional, +possibly dependent, manifests or related files. +Described in Section 4.1.3.

    +
    • +
  • +

    profile (index 3): An optional profile identifier for the tags contained in +this CoRIM. The profile MUST be understood by the CoRIM processor. Failure +to recognize the profile identifier MUST result in the rejection of the +entire CoRIM. +See Section 4.1.4

    +
    • +
  • +

    rim-validity (index 4): Specifies the validity period of the CoRIM. +Described in Section 7.3.

    +
    • +
  • +

    entities (index 5): A list of entities involved in a CoRIM life-cycle. +Described in Section 4.1.5.

    +
    • +
  • +

    $$corim-map-extension: This CDDL socket is used to add new information +structures to the corim-map. +Described in Section 11.3.

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

+4.1.1. Identity +

+

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

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

+4.1.2. Tags +

+

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

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

+4.1.3. Locator Map +

+

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

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

The following describes each child element of this type.

+
    +
  • +

    href (index 0): URI identifying the additional resource that can be fetched

    +
    • +
  • +

    thumbprint (index 1): expected digest of the resource referenced by href. +See sec-common-hash-entry}}.

    +
    • +
+
+
+
+
+

+4.1.4. Profile Types +

+

Profiling is the mechanism that allows the base CoRIM CDDL definition to be customized to fit a specific Attester.

+

A profile defines which of the optional parts of a CoRIM are required, which are prohibited and which extension points are exercised and how. +A profile MUST NOT alter the syntax or semantics of CoRIM types defined in this document.

+

A profile MAY constrain the values of a given CoRIM type to a subset of the values. +A profile MAY extend the set of a given CoRIM type using the defined extension points (Section 5.2). +Exercised extension points should preserve the intent of the original semantics.

+

CoRIM profiles SHOULD be specified in a publicly available document.

+

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

+

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

+

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

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

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

+
+
+
+
+

+4.1.5. Entities +

+

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

+

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

+

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

+
+
+corim-entity-map =
+  entity-map<$corim-role-type-choice, $$corim-entity-map-extension>
+
+$corim-role-type-choice /= &(manifest-creator: 1)
+
+
+
+
+
+
+
+
+

+4.2. Signed CoRIM +

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

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

+

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

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

The following describes each child element of this type.

+
    +
  • +

    protected: A CBOR Encoded protected header which is protected by the COSE +signature. Contains information as given by Protected Header Map below.

    +
    • +
  • +

    unprotected: A COSE header that is not protected by COSE signature.

    +
    • +
  • +

    payload: A CBOR encoded tagged CoRIM.

    +
    • +
  • +

    signature: A COSE signature block which is the signature over the protected +and payload components of the signed CoRIM.

    +
    • +
+
+
+

+4.2.1. Protected Header Map +

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

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

+
    +
  • +

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

    +
    • +
  • +

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

    +
    • +
  • +

    kid (index 4): A bit string which is a key identity pertaining to the CoRIM Issuer.

    +
    • +
  • +

    corim-meta (index 8): A map that contains metadata associated with a signed CoRIM. +Described in Section 4.2.2.

    +
    • +
+

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

+
+
+
+
+

+4.2.2. Meta Map +

+

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

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

The following describes each child item of this group.

+
    +
  • +

    signer (index 0): Information about the entity that signs the CoRIM. +Described in Section 4.2.2.1.

    +
    • +
  • +

    signature-validity (index 1): Validity period for the CoRIM. +Described in Section 7.3.

    +
    • +
+
+
+
+4.2.2.1. Signer Map +
+
+
+corim-signer-map = {
+  &(signer-name: 0) => $entity-name-type-choice
+  ? &(signer-uri: 1) => uri
+  * $$corim-signer-map-extension
+}
+
+
+
    +
  • +

    signer-name (index 0): Name of the organization that performs the signer +role

    +
    • +
  • +

    signer-uri (index 1): A URI identifying the same organization

    +
    • +
  • +

    $$corim-signer-map-extension: Extension point for future expansion of the +Signer map.

    +
    • +
+
+
+
+
+
+
+

+4.2.3. Unprotected CoRIM Header Map +

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

+5. Concise Module Identifier (CoMID) +

+

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

+

Each CoMID has a unique ID that is used to unambiguously identify CoMID instances when cross referencing CoMID tags, for example in typed link relations, or in a CoBOM tag.

+

A CoMID defines several types of Claims, using "triples" semantics.

+

At a high level, a triple is a statement that links a subject to an object via a predicate. +CoMID triples typically encode assertions made by the CoRIM author about Attesting or Target Environments and their security features, for example measurements, cryptographic key material, etc.

+

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

+
    +
  • +

    Reference Values triples: containing Reference Values that are expected to match Evidence for a given Target Environment (Section 5.1.4.2).

    +
    • +
  • +

    Endorsed Values triples: containing "Endorsed Values", i.e., features about an Environment that do not appear in Evidence. Specific examples include testing or certification data pertaining to a module (Section 5.1.4.3).

    +
    • +
  • +

    Device Identity triples: containing cryptographic credentials - for example, an IDevID - uniquely identifying a device (Section 5.1.4.6).

    +
    • +
  • +

    Attestation Key triples: containing cryptographic keys that are used to verify the integrity protection on the Evidence received from the Attester (Section 5.1.4.7).

    +
    • +
  • +

    Domain dependency triples: describing trust relationships between domains, i.e., collection of related environments and their measurements (Section 5.1.4.8).

    +
    • +
  • +

    Domain membership triples: describing topological relationships between (sub-)modules. For example, in a composite Attester comprising multiple sub-Attesters (sub-modules), this triple can be used to define the topological relationship between lead- and sub- Attester environments (Section 5.1.4.9).

    +
    • +
  • +

    CoMID-CoSWID linking triples: associating a Target Environment with existing CoSWID tags (Section 5.1.4.10).

    +
    • +
+
+
+

+5.1. Structure +

+

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

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

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

+
    +
  • +

    lang (index 0): A textual language tag that conforms with IANA "Language +Subtag Registry" [IANA.language-subtag-registry]. The context of the specified language +applies to all sibling and descendant textual values, unless a descendant +object has defined a different language tag. Thus, a new context is +established when a descendant object redefines a new language tag. All +textual values within a given context MUST be considered expressed in the +specified language.

    +
    • +
  • +

    tag-identity (index 1): A tag-identity-map containing unique +identification information for the CoMID. +Described in Section 5.1.1.

    +
    • +
  • +

    entities (index 2): Provides information about one or more organizations +responsible for producing the CoMID tag. +Described in Section 5.1.2.

    +
    • +
  • +

    linked-tags (index 3): A list of one or more linked-tag-map providing typed relationships between this and +other CoMIDs. +Described in Section 5.1.3).

    +
    • +
  • +

    triples (index 4): One or more triples providing information specific to +the described module, e.g.: reference or endorsed values, cryptographic +material, or structural relationship between the described module and other +modules. +Described in Section 5.1.4.

    +
    • +
+
+
+

+5.1.1. Tag Identity +

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

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

+
    +
  • +

    tag-id (index 0): A universally unique identifier for the CoMID. +Described in Section 5.1.1.1.

    +
    • +
  • +

    tag-version (index 1): Optional versioning information for the tag-id. +Described in Section 5.1.1.2.

    +
    • +
+
+
+
+5.1.1.1. Tag ID +
+
+
+$tag-id-type-choice /= tstr
+$tag-id-type-choice /= uuid-type
+
+
+

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

+
+
+
+
+
+5.1.1.2. Tag Version +
+
+
+tag-version-type = uint .default 0
+
+
+

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

+
+
+
+
+
+
+

+5.1.2. Entities +

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

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

+

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

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

The roles defined for a CoMID entity are:

+
    +
  • +

    tag-creator (value 0): creator of the CoMID tag.

    +
    • +
  • +

    creator (value 1): original maker of the module described by the CoMID tag.

    +
    • +
  • +

    maintainer (value 2): an entity making changes to the module described by the CoMID tag.

    +
    • +
+
+
+
+
+

+5.1.3. Linked Tag +

+

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

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

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

+
    +
  • +

    linked-tag-id (index 0): Unique identifier for the target tag. +See Section 5.1.1.1.

    +
    • +
  • +

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

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

The relations defined in this specification are:

+
    +
  • +

    supplements (value 0): the source tag provides additional information about +the module described in the target tag.

    +
    • +
  • +

    replaces (value 1): the source tag corrects erroneous information +contained in the target tag. The information in the target MUST be +disregarded.

    +
    • +
+
+
+
+
+

+5.1.4. Triples +

+

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

+
+
+triples-map = non-empty<{
+  ? &(reference-triples: 0) =>
+    [ + reference-triple-record ]
+  ? &(endorsed-triples: 1) =>
+    [ + endorsed-triple-record ]
+  ? &(identity-triples: 2) =>
+    [ + identity-triple-record ]
+  ? &(attest-key-triples: 3) =>
+    [ + attest-key-triple-record ]
+  ? &(dependency-triples: 4) =>
+    [ + domain-dependency-triple-record ]
+  ? &(membership-triples: 5) =>
+    [ + domain-membership-triple-record ]
+  ? &(coswid-triples: 6) =>
+    [ + coswid-triple-record ]
+  ? &(conditional-endorsement-series-triples: 8) =>
+    [ + conditional-endorsement-series-triple-record ]
+  ? &(conditional-endorsement-triples: 10) =>
+    [ + conditional-endorsement-triple-record ]
+  * $$triples-map-extension
+}>
+
+
+

The following describes each member of the triples-map:

+
    +
  • +

    reference-triples (index 0): Triples containing reference values. +Described in Section 5.1.4.2.

    +
    • +
  • +

    endorsed-triples (index 1): Triples containing endorsed values. +Described in Section 5.1.4.3.

    +
    • +
  • +

    identity-triples (index 2): Triples containing identity credentials. +Described in Section 5.1.4.6.

    +
    • +
  • +

    attest-key-triples (index 3): Triples containing verification keys associated with attesting environments. +Described in Section 5.1.4.7.

    +
    • +
  • +

    dependency-triples (index 4): Triples describing trust relationships between domains. +Described in Section 5.1.4.8.

    +
    • +
  • +

    membership-triples (index 5): Triples describing topological relationships between (sub-)modules. +Described in Section 5.1.4.9.

    +
    • +
  • +

    coswid-triples (index 6): Triples associating modules with existing CoSWID tags. +Described in Section 5.1.4.10.

    +
    • +
  • +

    conditional-endorsement-series-triples (index 8): Triples describing a series of +conditional Endorsements based on the acceptance of a stateful environment. +Described in Section 5.1.4.5.

    +
    • +
  • +

    conditional-endorsement-triples (index 10): Triples describing a series of +Endorsement that are applicable based on the acceptance of a series of +stateful environment records. +Described in Section 5.1.4.4.

    +
    • +
+
+
+
+5.1.4.1. Environments +
+

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

+

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

+

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

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

The following describes each member of the environment-map:

+
    +
  • +

    class (index 0): Contains "class" attributes associated with the module. +Described in Section 5.1.4.1.1.

    +
    • +
  • +

    instance (index 1): Contains a unique identifier of a module's instance. +Described in Section 5.1.4.1.2.

    +
    • +
  • +

    group (index 2): identifier for a group of instances, e.g., if an +anonymization scheme is used. +Described in Section 5.1.4.1.3.

    +
    • +
+
+
+
+5.1.4.1.1. Environment Class +
+

The Class name consists of class attributes that distinguish the class of +environment from other classes. The class attributes include class-id, vendor, +model, layer, and index. The CoMID author determines which attributes are +needed.

+
+
+class-map = non-empty<{
+  ? &(class-id: 0) => $class-id-type-choice
+  ? &(vendor: 1) => tstr
+  ? &(model: 2) => tstr
+  ? &(layer: 3) => uint
+  ? &(index: 4) => uint
+}>
+
+$class-id-type-choice /= tagged-oid-type
+$class-id-type-choice /= tagged-uuid-type
+$class-id-type-choice /= tagged-bytes
+
+
+

The following describes each member of the class-map:

+
    +
  • +

    class-id (index 0): Identifies the environment via a well-known identifier. +Typically, class-id is an object identifier (OID) variable-length opaque byte string (Section 7.8) or universally unique identifier (UUID). +Use of this attribute is preferred.

    +
    • +
  • +

    vendor (index 1): Identifies the entity responsible for choosing values for +the other class attributes that do not already have naming authority.

    +
    • +
  • +

    model (index 2): Describes a product, generation, and family. If +populated, vendor MUST also be populated.

    +
    • +
  • +

    layer (index 3): Is used to capture where in a sequence the environment +exists. For example, the order in which bootstrap code is executed may have +security relevance.

    +
    • +
  • +

    index (index 4): Is used when there are clones (i.e., multiple instances) +of the same class of environment. Each clone is given a different index +value to disambiguate it from the other clones. For example, given a chassis +with several network interface controllers (NIC), each NIC can be given a +different index value.

    +
    • +
+
+
+
+
+
+5.1.4.1.2. Environment Instance +
+

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

+

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

+
+
+$instance-id-type-choice /= tagged-ueid-type
+$instance-id-type-choice /= tagged-uuid-type
+$instance-id-type-choice /= $crypto-key-type-choice
+$instance-id-type-choice /= tagged-bytes
+
+
+
+
+
+
+
+5.1.4.1.3. Environment Group +
+

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

+

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

+
+
+$group-id-type-choice /= tagged-uuid-type
+$group-id-type-choice /= tagged-bytes
+
+
+
+
+
+
+
+5.1.4.1.4. Measurements +
+

Measurements can be of a variety of things including software, firmware, +configuration files, read-only memory, fuses, IO ring configuration, partial +reconfiguration regions, etc. Measurements comprise raw values, digests, or +status information.

+

An environment has one or more measurable elements. Each element can have a +dedicated measurement or multiple elements could be combined into a single +measurement. Measurements can have class, instance or group scope. This is +typically determined by the triple's environment.

+

Class measurements apply generally to all the Attesters in a given class.

+

Instance measurements apply to a specific Attester instance. Environments +identified by a class identifier have measurements that are common to the +class. Environments identified by an instance identifier have measurements that +are specific to that instance.

+

The supply chain entity that is responsible for providing 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.

+

An environment may have multiple measured elements. +Measured elements are distinguished from each other by measurement keys. +Measurement keys may be used to disambiguate measurements of the same type originating from different elements.

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

The following describes each member of the measurement-map:

+
    +
  • +

    mkey (index 0): An optional measurement key. + Described in Section 5.1.4.1.4.1. + A measurement-map without an mkey is said to be anonymous.

    +
    • +
  • +

    mval (index 1): The measurements associated with the environment. + Described in Section 5.1.4.1.4.2.

    +
    • +
  • +

    authorized-by (index 2): The cryptographic identity of the individual or organization that is + the designated authority for this measurement. + For example, the producer of the measurement. + See Section 5.1.4.1.5.

    +
    • +
+
+
+
+5.1.4.1.4.1. Measurement Keys +
+

Measurement keys are locally scoped extensible identifiers. +The initial types defined are OID, UUID, uint, and tstr. +mkey may be necessary to disambiguate multiple measurements of the same type or to distinguish multiple measured elements within the same environment. +A single anonymous measurement-map is allowed within the same environment. +Two or more measurement-map entries within the same environment MUST populate mkey.

+
+
+$measured-element-type-choice /= tagged-oid-type
+$measured-element-type-choice /= tagged-uuid-type
+$measured-element-type-choice /= uint
+$measured-element-type-choice /= tstr
+
+
+
+
+
+
+
+5.1.4.1.4.2. Measurement Values +
+

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

+

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

+
+
+measurement-values-map = non-empty<{
+  ? &(version: 0) => version-map
+  ? &(svn: 1) => svn-type-choice
+  ? &(digests: 2) => digests-type
+  ? &(flags: 3) => flags-map
+  ? (
+      &(raw-value: 4) => $raw-value-type-choice,
+      ? &(raw-value-mask: 5) => raw-value-mask-type
+    )
+  ? &(mac-addr: 6) => mac-addr-type-choice
+  ? &(ip-addr: 7) =>  ip-addr-type-choice
+  ? &(serial-number: 8) => text
+  ? &(ueid: 9) => ueid-type
+  ? &(uuid: 10) => uuid-type
+  ? &(name: 11) => text
+  ? &(cryptokeys: 13) => [ + $crypto-key-type-choice ]
+  ? &(integrity-registers: 14) => integrity-registers
+  * $$measurement-values-map-extension
+}>
+
+
+

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

+
    +
  • +

    version (index 0): Typically changes whenever the measured environment is updated. +Described in Section 5.1.4.1.4.3.

    +
    • +
  • +

    svn (index 1): The security version number typically changes only when a security relevant change is made to the measured environment. +Described in Section 5.1.4.1.4.4.

    +
    • +
  • +

    digests (index 2): Contains the digest(s) of the measured environment +together with the respective hash algorithm used in the process. +It uses the digests-type. +Described in Section 7.7.

    +
    • +
  • +

    flags (index 3): Describes security relevant operational modes. +For example, whether the environment is in a debug mode, recovery mode, not fully +configured, not secure, not replay protected or not integrity protected. +The flags field indicates which operational modes are currently associated with measured environment. +Described in Section 5.1.4.1.4.5.

    +
    • +
  • +

    raw-value (index 4): Contains the actual (not hashed) value of the element. +An optional raw-value-mask (index 5) indicates which bits in the +raw-value field are relevant for verification. A mask of all ones ("1") +means all bits in the raw-value field are relevant. Multiple values could +be combined to create a single raw-value attribute. The vendor determines +how to pack multiple values into a single raw-value structure. The same +packing format is used when collecting Evidence so that Reference Values and +collected values are bit-wise comparable. The vendor determines the encoding +of raw-value and the corresponding raw-value-mask.

    +
    • +
  • +

    mac-addr (index 6): A EUI-48 or EUI-64 MAC address associated with the measured environment. +Described in Section 5.1.4.1.4.7.

    +
    • +
  • +

    ip-addr (index 7): An IPv4 or IPv6 address associated with the measured environment. +Described in Section 5.1.4.1.4.7.

    +
    • +
  • +

    serial-number (index 8): A text string representing the product serial number.

    +
    • +
  • +

    ueid (index 9): UEID associated with the measured environment. +Described in Section 7.5.

    +
    • +
  • +

    uuid (index 10): UUID associated with the measured environment. +Described in Section 7.4.

    +
    • +
  • +

    name (index 11): a name associated with the measured environment.

    +
    • +
  • +

    cryptokeys (index 13): identifies cryptographic keys that are protected by the Target Environment +See Section 5.1.4.1.5 for the supported formats. +An Attesting Environment determines that keys are protected as part of Claims collection. +Appraisal verifies that, for each value in cryptokeys, there is a matching Reference Value entry. +Matching is described in Section 8.6.6.1.5.

    +
    • +
  • +

    integrity-registers (index 14): A group of one or more named measurements associated with the environment. Described in Section 5.1.4.1.6.

    +
    • +
+
+
+
+
+
+5.1.4.1.4.3. Version +
+

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

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

The following describes each member of the version-map:

+
    +
  • +

    version (index 0): the version string

    +
    • +
  • +

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

    +
    • +
+
+
+$version-scheme /= &(multipartnumeric: 1)
+$version-scheme /= &(multipartnumeric-suffix: 2)
+$version-scheme /= &(alphanumeric: 3)
+$version-scheme /= &(decimal: 4)
+$version-scheme /= &(semver: 16384)
+$version-scheme /= int / text
+
+
+
+
+
+
+
+5.1.4.1.4.4. Security Version Number +
+

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

+

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

+

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

+
+
+svn-type = uint
+svn = svn-type
+min-svn = svn-type
+tagged-svn = #6.552(svn)
+tagged-min-svn = #6.553(min-svn)
+svn-type-choice = svn / tagged-svn / tagged-min-svn
+
+
+
+
+
+
+
+5.1.4.1.4.5. Flags +
+

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

+
+
+flags-map = {
+  ? &(is-configured: 0) => bool
+  ? &(is-secure: 1) => bool
+  ? &(is-recovery: 2) => bool
+  ? &(is-debug: 3) => bool
+  ? &(is-replay-protected: 4) => bool
+  ? &(is-integrity-protected: 5) => bool
+  ? &(is-runtime-meas: 6) => bool
+  ? &(is-immutable: 7) => bool
+  ? &(is-tcb: 8) => bool
+  ? &(is-confidentiality-protected: 9) => bool
+  * $$flags-map-extension
+}
+
+
+

The following describes each member of the flags-map:

+
    +
  • +

    is-configured (index 0): If the flag is true, the measured environment is fully configured for normal operation.

    +
    • +
  • +

    is-secure (index 1): If the flag is true, the measured environment's configurable +security settings are fully enabled.

    +
    • +
  • +

    is-recovery (index 2): If the flag is true, the measured environment is in recovery +mode.

    +
    • +
  • +

    is-debug (index 3): If the flag is true, the measured environment is in a debug enabled +mode.

    +
    • +
  • +

    is-replay-protected (index 4): If the flag is true, the measured environment is +protected from replay by a previous image that differs from the current image.

    +
    • +
  • +

    is-integrity-protected (index 5): If the flag is true, the measured environment is +protected from unauthorized update.

    +
    • +
  • +

    is-runtime-meas (index 6): If the flag is true, the measured environment is measured +after being loaded into memory.

    +
    • +
  • +

    is-immutable (index 7): If the flag is true, the measured environment is immutable.

    +
    • +
  • +

    is-tcb (index 8): If the flag is true, the measured environment is a trusted +computing base.

    +
    • +
  • +

    is-confidentiality-protected (index 9): If the flag is true, the measured environment +is confidentiality protected. For example, if the measured environment consists of memory, +the sensitive values in memory are encrypted.

    +
    • +
+
+
+
+
+
+5.1.4.1.4.6. Raw Values Types +
+

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

+

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

+

The mask is applied by the Verifier as part of appraisal. +Only the raw value bits with corresponding TRUE mask bits are compared during appraisal.

+

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

+
+
+$raw-value-type-choice /= tagged-bytes
+
+raw-value-mask-type = bytes
+
+
+
+
+
+
+
+5.1.4.1.4.7. Address Types +
+

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

+
+
+ip-addr-type-choice = ip4-addr-type / ip6-addr-type
+ip4-addr-type = bytes .size 4
+ip6-addr-type = bytes .size 16
+
+mac-addr-type-choice = eui48-addr-type / eui64-addr-type
+eui48-addr-type = bytes .size 6
+eui64-addr-type = bytes .size 8
+
+
+
+
+
+
+
+
+
+5.1.4.1.5. Crypto Keys +
+

A cryptographic key can be one of the following formats:

+
    +
  • +

    tagged-pkix-base64-key-type: PEM encoded SubjectPublicKeyInfo. +Defined in Section 13 of [RFC7468].

    +
    • +
  • +

    tagged-pkix-base64-cert-type: PEM encoded X.509 public key certificate. +Defined in Section 5 of [RFC7468].

    +
    • +
  • +

    tagged-pkix-base64-cert-path-type: X.509 certificate chain created by the +concatenation of as many PEM encoded X.509 certificates as needed. The +certificates MUST be concatenated in order so that each directly certifies +the one preceding.

    +
    • +
  • +

    tagged-cose-key-type: CBOR encoded COSE_Key or COSE_KeySet. +Defined in Section 7 of [STD96].

    +
    • +
  • +

    tagged-pkix-asn1der-cert-type: a bstr of ASN.1 DER encoded X.509 public key certificate. +Defined in Section 4 of [RFC5280].

    +
    • +
+

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

+
    +
  • +

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

    +
    • +
  • +

    tagged-bytes: a key identifier with no prescribed construction method.

    +
    • +
+
+
+$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
+$crypto-key-type-choice /= tagged-pkix-asn1der-cert-type
+$crypto-key-type-choice /= tagged-bytes
+
+tagged-pkix-base64-key-type = #6.554(tstr)
+tagged-pkix-base64-cert-type = #6.555(tstr)
+tagged-pkix-base64-cert-path-type = #6.556(tstr)
+tagged-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)
+tagged-pkix-asn1der-cert-type = #6.562(bstr)
+
+
+
+
+
+
+
+5.1.4.1.6. Integrity Registers +
+

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

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

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

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

then both

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

and

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

are acceptable states.

+

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

+
+
+
+
+
+5.1.4.1.7. Domain Types +
+

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

+

The following CDDL describes domain type choices.

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

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

+
+
+
+
+
+
+
+5.1.4.2. Reference Values Triple +
+

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

+

The Reference Values Triple has the following structure:

+
+
+reference-triple-record = [
+  ref-env: environment-map
+  ref-claims: [ + measurement-map ]
+]
+
+
+

The reference-triple-record has the following parameters:

+
    +
  • +

    ref-env: Search criterion that locates an Evidence environment that matches the reference environment.

    +
    • +
  • +

    ref-claims: Search criteria that locates the Evidence measurements that match the reference Claims.

    +
    • +
+

To process reference-triple-record both the ref-env and ref-claims criteria are compared with Evidence entries. +If the search criteria are satisfied, the matching entry is re-asserted, except with the Reference Value Provider's authority. +By re-asserting Evidence using the RVP's authority, the Verifier can avoid mixing Reference Values (reference state) with Evidence (actual state). +See [I-D.ietf-rats-endorsements]. +Re-asserted Evidence using RVP authority is said to be "corroborated".

+
+
+
+
+
+5.1.4.3. Endorsed Values Triple +
+

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

+

The Endorsed Values Triple has the following structure:

+
+
+endorsed-triple-record = [
+  condition: environment-map
+  endorsement: [ + measurement-map ]
+]
+
+
+

The endorsed-triple-record has the following parameters:

+
    +
  • +

    condition: Search criterion that locates an Evidence, corroborated Evidence, or Endorsements environment.

    +
    • +
  • +

    endorsement: Additional Endorsement Claims.

    +
    • +
+

To process a endorsed-triple-record the condition is compared with existing Evidence, corroborated Evidence, and Endorsements. +If the search criterion is satisfied, the endorsement Claims are combined with the condition environment-map to form a new (actual state) entry. +The new entry is added to the existing set of entries using the Endorser's authority.

+
+
+
+
+
+5.1.4.4. Conditional Endorsement Triple +
+

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

+

The Conditional Endorsement Triple has the following structure:

+
+
+conditional-endorsement-triple-record = [
+  conditions: [ + stateful-environment-record ]
+  endorsements: [ + endorsed-triple-record ]
+]
+
+stateful-environment-record = [
+  environment: environment-map,
+  claims-list: [ + measurement-map ]
+]
+
+
+

The conditional-endorsement-triple-record has the following parameters:

+
    +
  • +

    conditions: Search criteria that locates Evidence, corroborated Evidence, or Endorsements.

    +
    • +
  • +

    endorsements: Additional Endorsements.

    +
    • +
+

To process a conditional-endorsement-triple-record the conditions are compared with existing Evidence, corroborated Evidence, and Endorsements. +If the search criteria are satisfied, the endorsements entries are asserted with the Endorser's authority as new Endorsements.

+
+
+
+
+
+5.1.4.5. Conditional Endorsement Series Triple +
+

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

+

The Conditional Endorsement Series Triple has the following structure:

+
+
+conditional-endorsement-series-triple-record = [
+  condition: stateful-environment-record
+  series: [ + conditional-series-record ]
+]
+
+conditional-series-record = [
+  selection: [ + measurement-map]
+  addition: [ + measurement-map ]
+]
+
+
+

The conditional-endorsement-series-triple-record has the following parameters:

+
    +
  • +

    condition: Search criteria that locates Evidence, corroborated Evidence, or Endorsements.

    +
    • +
  • +

    series: A set of selection-addition tuples.

    +
    • +
+

The conditional-series-record has the following parameters:

+
    +
  • +

    selection: Search criteria that locates Evidence, corroborated Evidence, or Endorsements from the condition result.

    +
    • +
  • +

    addition: Additional Endorsements if the selection criteria are satisfied.

    +
    • +
+

To process a conditional-endorsement-series-record the conditions are compared with existing Evidence, corroborated Evidence, and Endorsements. +If the search criteria are satisfied, the series tuples are processed.

+

The series array contains a list of conditional-series-record entries.

+

For each series entry, if the selection criteria matches an entry found in the condition result, the series addition is combined with the environment-map from the condition result to form a new Endorsement entry. +The new entry is added to the existing set of Endorsements.

+

The first series entry that successfully matches the selection criteria terminates series processing.

+
+
+
+
+
+5.1.4.6. Device Identity Triple +
+

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

+

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

+

A Device Identity triple endorses that the keys were securely provisioned to the named Target Environment. +Additional details about how a key was provisioned or is protected may be asserted using Endorsements such as endorsed-triples.

+

Depending on key formatting, as defined by $crypto-key-type-choice, the Verifier may take different steps to locate and verify the key.

+

If a key has usage restrictions that limit its use to device identity challenges, Verifiers SHOULD check for key use that violates usage restrictions.

+

Verification of a key, including its use restrictions, MAY produce Claims that are added to the ACS. +Alternatively, Verifiers MAY report key verification results as part of an error reporting function.

+
+
+identity-triple-record = [
+  environment-map
+  [ + $crypto-key-type-choice ]
+]
+
+
+
+
+
+
+
+5.1.4.7. Attest Key Triple +
+

An Attest Key triple record relates one or more cryptographic keys to an Attesting Environment. +The cryptographic keys are wielded by an Attesting Environment that collects measurements from a Target Environment. +The cryptographic keys sign Evidence.

+

Attest Key triples instruct a Verifier to perform key validation checks, such as revocation, certificate path construction & verification, or proof of possession. +The Verifier SHOULD verify keys contained in Attest Key triples.

+

Attest Key triples endorse that the keys were securely provisioned to the named (identified via an environment-map) Attesting Environment. +Additional details about how a key was provisioned or is protected may be asserted using Endorsements such as endorsed-triples.

+

Depending on key formatting, as defined by $crypto-key-type-choice, the Verifier may take different steps to locate and verify the key. +If a key has usage restrictions that limits its use to Evidence signing, Verifiers SHOULD check for key use that violates usage restrictions.

+

Verification of a key, including its use restrictions, MAY produce Claims that are added to the ACS. +Alternatively, Verifiers MAY report key verification results as part of an error reporting function.

+
+
+attest-key-triple-record = [
+  environment-map
+  [ + $crypto-key-type-choice ]
+]
+
+
+
+
+
+
+
+5.1.4.8. Domain Dependency Triple +
+

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

+
+
+domain-dependency-triple-record = [
+  $domain-type-choice
+  [ + $domain-type-choice ]
+]
+
+
+
+
+
+
+
+5.1.4.9. Domain Membership Triple +
+

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

+
+
+domain-membership-triple-record = [
+  $domain-type-choice
+  [ + environment-map ]
+]
+
+
+
+
+
+
+
+5.1.4.10. CoMID-CoSWID Linking Triple +
+

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

+
+
+coswid-triple-record = [
+  environment-map
+  [ + concise-swid-tag-id ]
+]
+
+concise-swid-tag-id = text / bstr .size 16
+
+
+
+
+
+
+
+
+
+
+

+5.2. Extensibility +

+

The base CoRIM document definition is described using CDDL [RFC8610] that can be extended only at specific allowed points known as "extension points".

+

The following types of extensions are supported in CoRIM.

+
+
+

+5.2.1. Map Extensions +

+

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

+
+
+
+
+

+5.2.2. Data Type Extensions +

+

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

+

New data type extensions SHOULD be documented to facilitate interoperability. +CoRIM profiles are best used to document vendor or industry defined extensions.

+
+
+
+
+
+
+
+
+

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

+
+
+

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

+
+
+concise-bom-tag = {
+  &(tag-identity: 0) => 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 Section 5.1.1.

    +
    • +
  • +

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

    +
    • +
  • +

    $$concise-bom-tag-extension: This CDDL socket is used to add new information structures to the concise-bom-tag. +See Section 11.5. +The $$concise-bom-tag-extension extension socket is empty in this specification.

    +
    • +
+
+
+
+
+
+
+

+7. Common Types +

+

The following CDDL types may be shared by CoRIM, CoMID, and CoBOM.

+
+
+

+7.1. Non-Empty +

+

The non-empty generic type is used to express that a map with only optional +members MUST at least include one of the members.

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

+7.2. Entity +

+

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

+
    +
  • +

    A role-type-choice, i.e., a selection of roles that entities of the +instantiated type can claim

    +
    • +
  • +

    An extension-socket, i.e., a CDDL socket that can be used to extend +the attributes associated with entities of the instantiated type

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

The following describes each member of the entity-map.

+
    +
  • +

    entity-name (index 0): The name of entity which is responsible for the action(s) as defined by the role. +$entity-name-type-choice can only be text. +Other specifications can extend the $entity-name-type-choice. +See Section 11.4.

    +
    • +
  • +

    reg-id (index 1): A URI associated with the organization that owns the entity name.

    +
    • +
  • +

    role (index 2): A type choice defining the roles that the entity is claiming. +The role is supplied as a parameter at the time the entity-map generic is instantiated.

    +
    • +
  • +

    extension-socket: A CDDL socket used to add new information structures to the entity-map.

    +
    • +
+

Examples of how the entity-map generic is instantiated can be found in +(Section 4.1.5) and (Section 5.1.2).

+
+
+
+
+

+7.3. Validity +

+

A validity-map represents the time interval during which the signer +warrants that it will maintain information about the status of the signed +object (e.g., a manifest).

+

In a validity-map, both ends of the interval are encoded as epoch-based +date/time as per Section 3.4.2 of [STD94].

+
+
+validity-map = {
+  ? &(not-before: 0) => time
+  &(not-after: 1) => time
+}
+
+
+
    +
  • +

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

    +
    • +
  • +

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

    +
    • +
+
+
+
+
+

+7.4. UUID +

+

Used to tag a byte string as a binary UUID. +Defined in Section 4.1.2. of [RFC4122].

+
+
+uuid-type = bytes .size 16
+tagged-uuid-type = #6.37(uuid-type)
+
+
+
+
+
+
+

+7.5. UEID +

+

Used to tag a byte string as Universal Entity ID Claim (UUID). +Defined in Section 4.2.1 of [I-D.ietf-rats-eat].

+
+
+ueid-type = bytes .size 33
+tagged-ueid-type = #6.550(ueid-type)
+
+
+
+
+
+
+

+7.6. OID +

+

Used to tag a byte string as the BER encoding [X.690] of an absolute object +identifier [RFC9090].

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

+7.7. Digest +

+

A digest represents the value of a hashing operation together with the hash algorithm used. +The type of the digest algorithm identifier can be either int or text and is interpreted according to the [IANA.named-information] registry. +Specifically, int values are matched against "ID" entries, text values are matched against "Hash Name String" entries. +Whenever possible, using the int encoding is RECOMMENDED.

+
+
+digest = [
+  alg: (int / text),
+  val: bytes
+]
+
+digests-type = [ + digest ]
+
+
+

A measurement can be obtained using different hash algorithms. +A digests-type can be used to collect multiple digest values obtained by applying different hash algorithms on the same input. +Each entry in the digests-type MUST have a unique alg value.

+
+
+
+
+

+7.8. Tagged Bytes Type +

+

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

+
+
+tagged-bytes = #6.560(bytes)
+
+
+
+
+
+
+
+
+

+8. Appraisal of CoRIM-based Inputs +

+

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

+

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

+

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

+
+
+

+8.1. Appraisal Procedure +

+

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

+
    +
  • +

    Phase 1: Input Validation and Transformation

    +
    • +
+

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

+
    +
  • +

    Phase 2: Evidence Augmentation

    +
    • +
+

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

+
    +
  • +

    Phase 3: Reference Values Corroboration and Augmentation

    +
    • +
+

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

+
    +
  • +

    Phase 4: Endorsed Values Augmentation

    +
    • +
+

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

+
    +
  • +

    Phase 5: Verifier Augmentation

    +
    • +
+

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

+

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

+
    +
  • +

    Phase 6: Policy Augmentation

    +
    • +
+

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

+
    +
  • +

    Phase 7: Attestation Results Production and Transformation

    +
    • +
+

During Phase 7, the outcome of Appraisal and the set of Attester Claims that are interesting to a Relying Party are copied from the Attester state to an output staging area. +The Claims in the output staging area and other Verifier related metadata are transformed into an external representation suitable for consumption by a Relying Party.

+
+
+
+
+

+8.2. Verifier Abstraction +

+

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

+

The following terms are used:

+
+
Claim:
+
+

A piece of information, in the form of a key-value pair.

+
+
+
Environment-Claim Tuple (ECT):
+
+

A structure containing a set of values that describe a Target Environment plus a set of measurement / Claim values that describe properties of the Target Environment. +The ECT also contains authority which identifies the entity that authored the ECT.

+
+
+
reference state:
+
+

Claims that describe various alternative states of a Target Environment. Reference Values Claims typically describe various possible states due to versioning, manufactruing practices, or supplier configuration options. See also Section 2 of [I-D.ietf-rats-endorsements].

+
+
+
actual state:
+
+

Claims that describe a Target Environment instance at a given point in time. Endorsed Values and Evidence typically are Claims about actual state. An Attester may be composed of multiple components, where each component may represent a scope of appraisal. +See also (Section 2 of [I-D.ietf-rats-endorsements]).

+
+
+
Authority:
+
+

The entity asserting that a claim is true. +Typically, a Claim is asserted using a cryptographic key to digitally sign the Claim. A cryptographic key can be a proxy for a human or organizational entity.

+
+
+
Appraisal Claims Set (ACS):
+
+

A structure that holds ECTs that have been appraised. +The ACS contains Attester state that has been authorized by Verifier processing and Appraisal Policy.

+
+
+
Appraisal Policy:
+
+

A description of the conditions that, if met, allow acceptance of Claims. Typically, the entity asserting a Claim should have knowledge, expertise, or context that gives credibility to the assertion. Appraisal Policy resolves which entities are credible and under what conditions. See also "Appraisal Policy for Evidence" in [RFC9334].

+
+
+
Attestation Results Set (ARS):
+
+

A structure that holds results of Appraisal and ECTs that are to be conveyed to a Relying Party.

+
+
+
+
+
+

+8.2.1. Internal Representation of Conceptual Messages +

+

Conceptual Messages are Verifier input and output values such as Evidence, Reference Values, Endorsed Values, Appraisal Policy, and Attestation Results.

+

The internal representation of Conceptual Messages, as well as the ACS (Section 8.2.2) and ARS (Section 8.2.3), are constructed from a common building block structure called Environment-Claims Tuple (ECT).

+

ECTs have five attributes:

+
+
1.
+
+

Environment : Identifies the Target Environment. Environments are identified using instance, class, or group identifiers. Environments may be composed of elements, each having an element identifier.

+
+
+
2.
+
+

Elements : Identifies the set of elements contained within a Target Environment and their trustworthiness Claims.

+
+
+
3.
+
+

Authority : Identifies the entity that issued the tuple. A certain type of key material by which the authority (and corresponding provenance) of the tuple can be determined, such as the public key of an asymmetric key pair that is associated with an authority's PKIX certificate.

+
+
+
4.
+
+

Conceptual Message Type : Identifies the type of Conceptual Message that originated the tuple.

+
+
+
5.
+
+

Profile : The profile that defines this tuple. If no profile is used, this attribute is omitted.

+
+
+
+

The following CDDL describes the ECT structure in more detail.

+
+
+ECT = {
+  ? environment: environment-map
+  ? element-list: [ + element-map ]
+  ? authority: [ + $crypto-key-type-choice ]
+  cmtype: cm-type
+  ? profile: $profile-type-choice
+}
+
+element-map = {
+  ? element-id: $measured-element-type-choice
+  element-claims: measurement-values-map
+}
+
+cm-type =  &(
+  reference-values: 0
+  endorsements: 1
+  evidence: 2
+  attestation-results: 3
+  verifier: 4
+  policy: 5
+)
+
+
+

The Conceptual Message type determines which attributes are mandatory.

+
+
+
+8.2.1.1. Internal Representation of Evidence +
+

An internal representation of attestation Evidence uses the ae relation.

+
+
+ae = [
+  addition: [ + ECT ]
+]
+
+
+

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

+

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

+

Table 3 contains the requirements for the ECT fields of the Evidence tuple:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Table 3: +Evidence tuple requirements +
ECT typeECT FieldRequirement
addition + environment +Mandatory
  + element-list +Mandatory
  + authority +Mandatory
  + cmtype +Mandatory
  + profile +Optional
+
+
+
+
+
+
+8.2.1.2. Internal Representation of Reference Values +
+

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

+
+
+rv = [ + {
+  condition: ECT
+  addition: ECT
+} ]
+
+
+

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

+

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

+

Table 4 contains the requirements for the ECT fields of the Reference Values tuple:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Table 4: +Reference Values tuple requirements +
ECT typeECT FieldRequirement
condition + environment +Mandatory
  + element-list +Mandatory
  + authority +Optional
  + cmtype +n/a
  + profile +n/a
addition + environment +Mandatory
  + element-list +Mandatory
  + authority +Mandatory
  + cmtype +Mandatory
  + profile +Optional
+
+
+
+
+
+
+8.2.1.3. Internal Representation of Endorsed Values +
+

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

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

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

+

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

+

Table 5 contains the requirements for the ECT fields of the Endorsed Values and Endorsed Values Series tuples:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Table 5: +Endorsed Values and Endorsed Values Series tuples requirements +
ECT typeECT FieldRequirement
condition + environment +Mandatory
  + element-list +Mandatory
  + authority +Optional
  + cmtype +n/a
  + profile +n/a
selection + environment +Mandatory
  + element-list +Mandatory
  + authority +Optional
  + cmtype +n/a
  + profile +n/a
addition + environment +Mandatory
  + element-list +Mandatory
  + authority +Mandatory
  + cmtype +Mandatory
  + profile +Optional
+
+
+
+
+
+
+8.2.1.4. Internal Representation of Policy Statements +
+

The policy relation compares the condition ECTs to the ACS.

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

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

+

Table 6 contains the requirements for the ECT fields of the Policy tuple:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Table 6: +Policy tuple requirements +
ECT typeECT FieldRequirement
condition + environment +Optional
  + element-list +Optional
  + authority +Optional
  + cmtype +n/a
  + profile +n/a
addition + environment +Mandatory
  + element-list +Mandatory
  + authority +Mandatory
  + cmtype +Mandatory
  + profile +Optional
+
+
+
+
+
+
+8.2.1.5. Internal Representation of Attestation Results +
+

The ar relation compares the acs-condition to the ACS.

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

If the condition is satisfied, the ars-additions are copied from the ACS to the ARS. +If any of the ars-additions are not found in the ACS then these ACS entries are not copied to the ARS.

+

Table 7 contains the requirements for the ECT fields of the Attestation Results tuple:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Table 7: +Attestation Results tuple requirements +
ECT typeECT FieldRequirement
acs-condition + environment +Optional
  + element-list +Optional
  + authority +Optional
  + cmtype +n/a
  + profile +n/a
ars-addition + environment +Mandatory
  + element-list +Mandatory
  + authority +Mandatory
  + cmtype +Mandatory
  + profile +Optional
+
+
+
+
+
+
+
+

+8.2.2. Internal Representation of ACS +

+

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

+
+
+ACS = [ + ECT ]
+
+
+
+
+
+
+

+8.2.3. Internal Representation of Attestation Results Set (ARS) +

+

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

+
+
+ARS = [ + ECT ]
+
+
+
+
+
+
+
+
+

+8.3. Input Validation and Transformation (Phase 1) +

+

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

+

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

+
+
+

+8.3.1. Input Validation +

+
+
+
+8.3.1.1. CoRIM Selection +
+

All available CoRIMs are collected.

+

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

+

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

+

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

+

The selection process MUST yield at least one usable tag.

+

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

+
+
+
+
+
+8.3.1.2. Tags Extraction and Validation +
+

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

+

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

+
+
+
+
+
+8.3.1.3. CoBOM Extraction +
+

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

+

CoBOMs which are not within their validity period are discarded.

+

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

+

A Verifier MAY decide to discard some of the available and valid CoBOMs depending on any locally configured authorization policies. +(Such policies model the trust relationships between the Verifier Owner and the relevant suppliers, and are out of the scope of the present document.) +For example, a composite device (Section 3.3 of [RFC9334]) is likely to be fully described by multiple CoRIMs, each signed by a different supplier. +In such case, the Verifier Owner may instruct the Verifier to discard tags activated by supplier CoBOMs that are not also activated by the trusted integrator.

+

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

+
+
+
+
+
+
+

+8.3.2. Evidence Collection +

+

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

+

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

+

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

+
+
+
+8.3.2.1. Cryptographic Validation of Evidence +
+

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

+

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

+

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

+

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

+

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

+
    +
  • +

    If a CoRIM profile is supplied, it MUST describe:

    +
      +
    • +

      How cryptographic verification key material is represented (e.g., using Attestation Keys triples, or CoTS tags)

      +
      • +
    • +

      How key material is associated with the Attesting Environment

      +
      • +
    • +

      How the Attesting Environment is identified in Evidence

      +
      • +
    +
    • +
+
+
+
+
+
+
+

+8.3.3. Input Transformation +

+

Input Conceptual Messages, whether Endorsements, Reference Values, Evidence, or Policies, are transformed to an internal representation that is based on ECTs (Section 8.2.1).

+

The following mapping conventions apply to all forms of input transformation:

+
    +
  • +
      +
    • +

      The environment field is populated with a Target Environment identifier.

      +
      • +
    • +

      The element-list field is populated with the measurements collected by an Attesting Environment.

      +
      • +
    • +

      The authority field is populated with the identity of the entity that asserted (e.g., signed) the Conceptual Message.

      +
      • +
    • +

      The cmtype field is set based on the type of Conceptual Message inputted or to be output.

      +
      • +
    • +

      The profile field is set based on the corim-map profile value.

      +
      • +
    +
    • +
+
+
+
+8.3.3.1. Appraisal Context Construction +
+

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

+
+
+
+
+
+8.3.3.2. Reference Triples Transformation +
+
+
Step 1.
+
+

An rv list entry (Section 8.2.1.2) is allocated.

+
+
+
Step 2.
+
+

The cmtype of the addition ECT in the rv entry is set to reference-values.

+
+
+
Step 3.
+
+

The Reference Values Triple (RVT) (Section 5.1.4.2) populates the rv ECTs.

+
+
+
+
+
i
+
+

RVT.ref-env

+
+
+
+
    +
  • +
      +
    • +

      copy(environment-map, rv.condition.environment.environment-map)

      +
      • +
    +
    • +
+
    +
  • +
      +
    • +

      copy(environment-map, rv.addition.environment.environment-map)

      +
      • +
    +
    • +
+
+
ii
+
+

For each e in RVT.ref-claims:

+
+
+
+
    +
  • +
      +
    • +

      copy(e.measurement-map, rv.addition.element-list.element-map)

      +
      • +
    +
    • +
+
+
Step 4.
+
+

The signer of the Endorsement conceptual message is copied to the rv.addition.authority field.

+
+
+
Step 5.
+
+

If the Endorsement conceptual message has a profile, the profile identifier is copied to the rv.addition.profile field.

+
+
+
+
+
+
+
+
+8.3.3.3. Endorsement Triples Transformations +
+

Endorsed Values Triple Transformation :

+
+
Step 1.
+
+

An ev entry (Section 8.2.1.3) is allocated.

+
+
+
Step 2.
+
+

The cmtype of the ev entry's addition ECT is set to endorsements.

+
+
+
Step 3.
+
+

The Endorsed Values Triple (EVT) (Section 5.1.4.3) populates the ev ECTs.

+
+
+
+
+
i
+
+

EVT.condition

+
+
+
+
    +
  • +
      +
    • +

      copy(environment-map, ev.condition.environment.environment-map)

      +
      • +
    +
    • +
+
    +
  • +
      +
    • +

      copy(environment-map, ev.addition.environment.environment-map)

      +
      • +
    +
    • +
+
+
ii
+
+

For each e in EVT.endorsement:

+
+
+
+
    +
  • +
      +
    • +

      copy(e.endorsement.measurement-map, ev.addition.element-list.element-map)

      +
      • +
    +
    • +
+
+
Step 4.
+
+

The signer of the Endorsement conceptual message is copied to the ev.addition.authority field.

+
+
+
Step 5.
+
+

If the Endorsement conceptual message has a profile, the profile is copied to the ev.addition.profile field.

+
+
+
+

Conditional Endorsement Triple Transformation :

+
+
Step 1.
+
+

An ev entry (Section 8.2.1.3) is allocated.

+
+
+
Step 2.
+
+

The cmtype of the ev entry's addition ECT is set to endorsements.

+
+
+
Step 3.
+
+

Entries in the Conditional Endorsement Triple (CET) (Section 5.1.4.4) conditions list are copied to a suitable ECT in the internal representation.

+
+
+
+
+
i
+
+

For each e in CET.conditions:

+
+
+
+
    +
  • +
      +
    • +

      copy(e.stateful-environment-record.environment.environment-map, ev.condition.environment.environment-map)

      +
      • +
    +
    • +
+
    +
  • +
      +
    • +

      copy(e.stateful-environment-record.claims-list.measurement-map, ev.condition.element-list.element-map)

      +
      • +
    +
    • +
+
+
ii
+
+

For each e in CET.endorsements:

+
+
+
+
    +
  • +
      +
    • +

      copy(e.endorsed-triple-record.condition.environment-map, ev.addition.environment.environment-map)

      +
      • +
    +
    • +
+
    +
  • +
      +
    • +

      copy(e.endorsed-triple-record.endorsement.measurement-map, ev.addition.element-list.element-map)

      +
      • +
    +
    • +
+
+
Step 4.
+
+

The signer of the Conditional Endorsement conceptual message is copied to the ev.addition.authority field.

+
+
+
Step 5.
+
+

If the Endorsement conceptual message has a profile, the profile is copied to the ev.addition.profile field.

+
+
+
+

Conditional Endorsement Series Triple Transformation :

+
+
Step 1.
+
+

An evs entry (Section 8.2.1.3) is allocated.

+
+
+
Step 2.
+
+

The cmtype of the evs entry's addition ECT is set to endorsements.

+
+
+
Step 3.
+
+

Populate the evs ECTs using the Conditional Endorsement Series Triple (CEST) (Section 5.1.4.5).

+
+
+
+
+
i.
+
+

CEST.condition:

+
+
+
+
    +
  • +
      +
    • +

      copy(stateful-environment-record.environment.environment-map, evs.condition.environment.environment-map)

      +
      • +
    +
    • +
+
    +
  • +
      +
    • +

      copy(stateful-environment-record.claims-list.measurement-map, evs.condition.element-list.element-map)

      +
      • +
    +
    • +
+
+
ii.
+
+

For each e in CEST.series:

+
+
+
+
    +
  • +
      +
    • +

      copy(evs.condition.environment.environment-map, evs.series.selection.environment.environment-map)

      +
      • +
    +
    • +
+
    +
  • +
      +
    • +

      copy(e.conditional-series-record.selection.measurement.measurement-map, evs.series.selection.element-list.element-map)

      +
      • +
    +
    • +
+
    +
  • +
      +
    • +

      copy(evs.condition.environment.environment-map, evs.series.addition.environment.environment-map)

      +
      • +
    +
    • +
+
    +
  • +
      +
    • +

      copy(e.conditional-series-record.addition.measurement-map, evs.series.addition.element-list.element-map)

      +
      • +
    +
    • +
+
+
Step 4.
+
+

The signer of the Conditional Endorsement conceptual message is copied to the evs.series.addition.authority field.

+
+
+
Step 5.
+
+

If the Endorsement conceptual message has a profile, the profile is copied to the evs.series.addition.profile field.

+
+
+
+
+
+
+
+
+8.3.3.4. Evidence Tranformation +
+

Evidence is transformed from an external representation to an internal representation based on the ae relation (Section 8.2.1.1). +The Evidence is mapped into one or more addition ECTs. +If the Evidence does not have a value for the mandatory ae fields, the Verifier MUST NOT process the Evidence.

+

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

+
+
+
+
+
+
+
+
+

+8.4. ACS Augmentation - Phases 2, 3, and 4 +

+

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

+

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

+
+
+

+8.4.1. ACS Requirements +

+

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

+

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

+

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

+
+
+
+8.4.1.1. ACS Processing Requirements +
+

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

+

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

+

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

+

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

+

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

+

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

+

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

+

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

+

The ACS must maintain the authority information for each ECT. There can be +multiple entries in state-triples which have the same environment-map +and a different authority. +See Section 8.4.2.1.1.

+

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

+

If the merged measurement-values-map contains duplicate codepoints and the +measurement values are not equivalent, then a Verifier SHALL report +an error and stop validation processing.

+
+
+
+8.4.1.1.1. 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 ACS entries to match or modify. +This field may be contained in an explicit matching condition, such as stateful-environment-record.

+

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

+

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

+

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

+
+
+
+
+
+
+
+8.4.1.2. ACS Augmentation Requirements +
+

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

+
+
+
+
+
+
+

+8.4.2. Evidence Augmentation (Phase 2) +

+
+
+
+8.4.2.1. Appraisal Claims Set Initialization +
+

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

+
+
+
+8.4.2.1.1. The authorized-by field in Appraisal Claims Set +
+

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

+

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

+

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

+

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

+

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

+

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

+

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

+
+
+
+
+
+
+
+
+

+8.4.3. Reference Values Corroboration and Augmentation (Phase 3) +

+

Reference Value Providers (RVP) publish Reference Values using the Reference Values Triple (Section 5.1.4.2) which are transformed (Section 8.3.3.2) into an internal representation (Section 8.2.1.2). +Reference Values may describe multiple possible Attester states.

+

Corroboration is the process of determining whether actual Attester state (as contained in the ACS) can be satisfied by Reference Values. +If satisfied, the RVP authority is added to the matching ACS entry.

+

Reference Values are matched with ACS entries by iterating through the rv list. +For each rv entry, the condition ECT is compared with an ACS ECT, where the ACS ECT cmtype contains evidence.

+

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

+

If the ECTs match except for authority, the rv addition ECT authority is added to the ACS ECT authority.

+
+
+
+
+

+8.4.4. Endorsed Values Augmentation (Phase 4) +

+

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

+

Endorsers publish Endorsements using endorsement triples (see Section 5.1.4.3), Section 5.1.4.4, and Section 5.1.4.5) which are transformed (Section 8.3.3.3) into an internal representation (Section 8.2.1.3). +Endorsements describe actual Attester state. +Endorsements are added to the ACS if the Endorsement condition is satisifed by the ACS.

+
+
+
+8.4.4.1. Processing Endorsements +
+

Endorsements are matched with ACS entries by iterating through the ev list. +For each ev entry, the condition ECT is compared with an ACS ECT, where the ACS ECT cmtype contains either evidence or endorsements. +If the ECTs match (Section 8.6), the ev addition ECT is added to the ACS.

+
+
+
+
+
+8.4.4.2. Processing Conditional Endorsements +
+

Conditional Endorsement Triples are transformed into an internal representation based on ev. +Conditional endorsements have the same processing steps as shown in (Section 8.4.4.1).

+
+
+
+
+
+8.4.4.3. Processing Conditional Endorsement Series +
+

Conditional Endorsement Series Triples are transformed into an internal representation based on evs. +Conditional series endorsements are matched with ACS entries first by iterating through the evs list, +where for each evs entry, the condition ECT is compared with an ACS ECT, where the ACS ECT cmtype contains either evidence or endorsements. +If the ECTs match (Section 8.6), the evs series array is iterated, +where for each series entry, if the selection ECT matches an ACS ECT, +the addition ECT is added to the ACS. +Series processing terminates when the first series entry matches.

+
+
+
+
+
+
+
+
+

+8.5. Examples for optional phases 5, 6, and 7 +

+

Phases 5, 6, and 7 are optional depending on implementation design. +Verifier implementations that apply consistency, integrity, or validity checks could be represented as Claims that augment the ACS or could be handled by application specific interfaces. +Processing appraisal policies may result in augmentation or modification of the ACS, but techniques for tracking the application of policies during appraisal need not result in ACS augmentation. +Additionally, the creation of Attestation Results is out-of-scope for this document, nevertheless internal staging may facilitate processing of Attestation Results.

+

Phase 5: Verifier Augmentation

+

Claims related to Verifier-applied consistency checks are asserted under the authority of the Verifier. +For example, the attest-key-triple-record may contain a cryptographic key to which the Verifier applies certificate path construction and validation. +Validation may reveal an expired certificate. +The Verifier implementation might generate a certificate path validation exception that is handled externally, or it could generate a Claim that the certificate path is invalid.

+

Phase 6: Policy Augmentation

+

Appraisal policy inputs could result in Claims that augment the ACS. +For example, an Appraisal Policy for Evidence may specify that if all of a collection of subcomponents satisfy a particular quality metric, the top-level component also satisfies the quality metric. +The Verifier might generate an Endorsement ECT for the top-level component that asserts a quality metric. +Details about the policy applied may also augment the ACS. +An internal representation of policy details, based on the policy ECT, as described in Section 8.2.1.4, contains the environments affected by the policy with policy identifiers as Claims.

+

Phase 7: Attestation Results Production and Transformation

+

Attestation Results rely on input from the ACS, but may not bear any similarity to its content. +For example, Attestation Results processing may map the ACS state to a generalized trustworthiness state such as [I-D.ietf-rats-ar4si]. +Generated Attestation Results Claims may be specific to a particular Relying Party. +Hence, the Verifier may need to maintain multiple Attestation Results contexts. +An internal representation of Attestation Results as separate contexts (Section 8.2.3) ensures Relying Party–specific processing does not modify the ACS, which is common to all Relying Parties. +Attestation Results contexts are the inputs to Attestation Results procedures that produce external representations.

+
+
+
+
+

+8.6. Comparing a condition ECT against the ACS +

+

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

+

A Verifier SHALL iterate over all ACS entries and SHALL attempt to match the condition ECT against each ACS entry. See Section 8.6.1. +A Verifier SHALL create a "matched entries" set, and SHALL populate it with all ACS entries which matched the condition ECT.

+

If the matched entries array is not empty, then the condition ECT matches the ACS.

+

If the matched entries array is empty, then the condition ECT does not match the ACS.

+
+
+

+8.6.1. Comparing a condition ECT against a single ACS entry +

+

If the condition ECT contains a profile and the profile defines an algorithm for a codepoint and environment-map then a Verifier MUST use the algorithm defined by the profile (or a standard algorithm if the profile defines that). +If the condition ECT contains a profile, but the profile does not define an algorithm for a particular codepoint and environment-map then the verifier MUST use the standard algorithm described in this document to compare the data at that codepoint.

+

A Verifier SHALL perform all of the comparisons defined in Section 8.6.2, Section 8.6.3, and Section 8.6.4.

+

Each of these comparisons compares one field in the condition ECT against the same field in the ACS entry.

+

If all of the fields match, then the condition ECT matches the ACS entry.

+

If any of the fields does not match, then the condition ECT does not match the ACS entry.

+
+
+
+
+

+8.6.2. Environment Comparison +

+

A Verifier SHALL compare each field which is present in the condition ECT environment-map against the corresponding field in the ACS entry environment-map using binary comparison. +Before performing the binary comparison, a Verifier SHOULD convert both environment-map fields into a form which meets CBOR Core Deterministic Encoding Requirements [STD94].

+

If all fields which are present in the condition ECT environment-map are present in the ACS entry and are binary identical, then the environments match.

+

If any field which is present in the condition ECT environment-map is not present in the ACS entry, then the environments do not match.

+

If any field which is present in the condition ECT environment-map is not binary identical to the corresponding ACS entry field, then the environments do not match.

+

If a field is not present in the condition ECT environment-map then the presence of, and value of, the corresponding ACS entry field SHALL NOT affect whether the environments match.

+
+
+
+
+

+8.6.3. Authority comparison +

+

A Verifier SHALL compare the condition ECT's authority value to the candidate entry's authority value.

+

If every entry in the condition ECT authority has a matching entry in the ACS entry authority field, then the authorities match. +The order of the fields in each authority field do not affect the result of the comparison.

+

If any entry in the condition ECT authority does not have a matching entry in the ACS entry authority field then the authorities do not match.

+

When comparing two $crypto-key-type-choice fields for equality, a Verifier SHALL treat them as equal if their deterministic CBOR encoding is binary equal.

+
+
+
+
+

+8.6.4. Element list comparison +

+

A Verifier SHALL iterate over all the entries in the condition ECT element-list and compare each one against the corresponding entry in the ACS entry element-list.

+

If every entry in the condition ECT element-list has a matching entry in the ACS entry element-list field then the element lists match.

+

The order of the fields in each element-list field do not affect the result of the comparison.

+

If any entry in the condition ECT element-list does not have a matching entry in the ACS entry element-list field then the element-list do not match.

+
+
+
+
+

+8.6.5. Element map comparison +

+

A Verifier shall compare each element-map within the condition ECT element-list against the ACS entry element-list.

+

First, a Verifier SHALL locate the entries in the ACS entry element-list which have a matching element-id as the condition ECT element-map. +Two element-id fields are the same if they are either both omitted, or both present with binary identical deterministic encodings.

+

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

+

If any condition ECT entry element-id does not have a corresponding element-id in the ACS entry then the element map does not match.

+

If any condition ECT entry has multiple corresponding element-ids then the element map does not match.

+

Second, a Verifier SHALL compare the element-claims field within the condition ECT element-list and the corresponding field from the ACS entry. +See Section 8.6.6.

+
+
+
+
+

+8.6.6. Measurement values map map Comparison +

+

A Verifier SHALL iterate over the codepoints which are present in the condition ECT element's measurement-values-map. +Each of the codepoints present in the condition ECT measurement-values-map is compared against the same codepoint in the candidate entry measurement-values-map.

+

If any codepoint present in the condition ECT measurement-values-map does not have a corresponding codepoint within the candidate entry measurement-values-map then Verifier SHALL remove that candidate entry from the candidate entries array.

+

If any codepoint present in the condition ECT measurement-values-map does not match the same codepoint within the candidate entry measurement-values-map then Verifier SHALL remove that candidate entry from the candidate entries array.

+
+
+
+8.6.6.1. Comparison of a single measurement-values-map codepoint +
+

A Verifier SHALL compare each condition ECT measurement-values-map value against the corresponding ACS entry value using the appropriate algorithm.

+

Non-negative codepoints represent standard data representations. +The comparison algorithms for these are defined in this document (in the sections below) or in other specifications. +For some non-negative codepoints their behavior is modified by the CBOR tag at the start of the condition ECT measurement-values-map value.

+

Negative codepoints represent profile defined data representations. +A Verifier SHALL use the codepoint number, the profile associated with the condition ECT, and the tag value (if present) to select the comparison algorithm.

+

If a Verifier is unable to determine the comparison algorithm which applies to a codepoint then it SHALL behave as though the candidate entry does not match the condition ECT.

+

Profile writers SHOULD use CBOR tags for widely applicable comparison methods to ease Verifier implementation compliance across profiles.

+

The following subsections define the comparison algorithms for the measurement-values-map codepoints defined by this specification.

+
+
+
+8.6.6.1.1. Comparison for version entries +
+

The value stored under measurement-values-map codepoint 0 is an version label, which must have type version-map. +Two version-map values can only be compared for equality, as they are colloquial versions that cannot specify ordering.

+
+
+
+
+
+8.6.6.1.2. Comparison for svn entries +
+

The ACS entry value stored under measurement-values-map codepoint 1 is a security version number, which must have type svn-type.

+

If the entry svn-type is a uint or a uint tagged with #6.552, then comparison with the uint named as SVN is as follows.

+
    +
  • +

    If the condition ECT value for measurement-values-map codepoint 1 is an untagged uint or a uint tagged with #6.552 then an equality comparison is performed on the uint components. +The comparison MUST return true if the value of SVN is equal to the uint value in the condition ECT.

    +
    • +
  • +

    If the condition ECT value for measurement-values-map codepoint 1 is a uint tagged with #6.553 then a minimum comparison is performed. +The comparison MUST return true if the value of SVN is less or equal to than the uint value in the condition ECT.

    +
    • +
+

If the entry svn-type is a uint tagged with #6.553, then comparison with the uint named as MINSVN is as follows.

+
    +
  • +

    If the condition ECT value for measurement-values-map codepoint 1 is an untagged uint or a uint tagged with #6.552 then the comparison MUST return false.

    +
    • +
  • +

    If the condition ECT value for measurement-values-map codepoint 1 is a uint tagged with #6.553 then an equality comparison is performed. +The comparison MUST return true if the value of MINSVN is equal to the uint value in the condition ECT.

    +
    • +
+

The meaning of a minimum SVN as an entry value is only meaningful as an endorsed value that has been added to the ACS. +The condition therefore treats the minimum SVN as an exact state and not one to compare with inequality.

+
+
+
+
+
+8.6.6.1.3. Comparison for digests entries +
+

A digests entry contains one or more digests, each measuring the same object. +When multiple digests are provided, each represents a different algorithm acceptable to the condition ECT author.

+

In the simple case, a condition ECT digests entry containing one digest matches matches a candidate entry containing a single entry with the same algorithm and value.

+

To prevent downgrade attacks, if there are multiple algorithms in common between the condition ECT and candidate entry, then the bytes paired with common algorithms must be equal. +A Verifier SHALL treat two algorithm identifiers as equal if they have the same deterministic binary encoding. +If both an integer and a string representation are defined for an algorithm then entities creating ECTs SHOULD use the integer representation. +If condition ECT and ACS entry use different names for the same algorithm, and the Verifier does not recognize that they are the same, then a downgrade attack is possible.

+

The comparison MUST return false if the CBOR encoding of the digests entry in the condition ECT or the ACS value with the same codepoint is incorrect (for example if fields are missing or the wrong type).

+

The comparison MUST return false if the condition ECT digests entry does not contain any digests.

+

The comparison MUST return false if either digests entry contains multiple values for the same hash algorithm.

+

The Verifier MUST iterate over the condition ECT digests array, locating common hash algorithm identifiers (which are present in the condition ECT and in the candidate entry). +If the value associated with any common hash algorithm identifier in the condition ECT differs from the value for the same algorithm identifier in the candidate entry then the comparison MUST return false.

+

The comparison MUST return false if there are no hash algorithms from the condition ECT in common with the hash algorithms from the candidate entry ECT.

+
+
+
+
+
+8.6.6.1.4. Comparison for raw-value entries +
+

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

+
+
+
+
+
+8.6.6.1.5. Comparison for cryptokeys entries +
+

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

+
+
+
+
+
+8.6.6.1.6. Comparison for Integrity Registers +
+

For each Integrity Register entry in the condition ECT, the Verifier will use the associated identifier (i.e., integrity-register-id-type-choice) to look up the matching Integrity Register entry in the candidate entry. +If no entry is found, the comparison MUST return false. +Instead, if an entry is found, the digest comparison proceeds as defined in Section 8.6.6.1.3 after equivalence has been found according to Section 5.1.4.1.6. +Note that it is not required for all the entries in the candidate entry to be used during matching: the condition ECT 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 condition ECT could describe a subset of PCRs.

+
+
+
+
+
+
+
+
+

+8.6.7. Profile-directed Comparison +

+

A profile MUST specify comparison algorithms for its additions to $-prefixed CoRIM CDDL codepoints when this specification does not prescribe binary comparison. +The profile must specify how to compare the CBOR tagged Reference Value against the ACS.

+

Note that a Verifier may compare Reference Values in any order, so the comparison should not be stateful.

+
+
+
+
+
+
+
+
+

+9. Implementation Status +

+

This section records the status of known implementations of the protocol +defined by this specification at the time of posting of this Internet-Draft, +and is based on a proposal described in [RFC7942]. The description of +implementations in this section is intended to assist the IETF in its decision +processes in progressing drafts to RFCs. Please note that the listing of any +individual implementation here does not imply endorsement by the IETF. +Furthermore, no effort has been spent to verify the information presented here +that was supplied by IETF contributors. This is not intended as, and must not +be construed to be, a catalogue of available implementations or their features. +Readers are advised to note that other implementations may exist.

+

According to [RFC7942], "this will allow reviewers and working groups to +assign due consideration to documents that have the benefit of running code, +which may serve as Evidence of valuable experimentation and feedback that have +made the implemented protocols more mature. It is up to the individual working +groups to use this information as they see fit".

+
+
+

+9.1. Veraison +

+ +
+
+
+
+
+
+

+10. Security and Privacy Considerations +

+

Evidence appraisal is at the core of any RATS protocol flow, mediating all interactions between Attesters and their Relying Parties. +The Verifier is effectively part of the Attesters' and Relying Parties' trusted computing base (TCB). +Any mistake in the appraisal process could have security implications. +For instance, it could lead to the subversion of an access control function, which creates a chance for privilege escalation.

+

Therefore, the Verifier’s code and configuration, especially those of the CoRIM processor, are primary security assets that must be built and maintained as securely as possible.

+

The protection of the Verifier system should be considered throughout its entire lifecycle, from design to operation. +This includes the following aspects:

+
    +
  • +

    Minimizing implementation complexity (see also Section 6.1 of [I-D.ietf-rats-endorsements]);

    +
    • +
  • +

    Using memory-safe programming languages;

    +
    • +
  • +

    Using secure defaults;

    +
    • +
  • +

    Minimizing the attack surface by avoiding unnecessary features that could be exploited by attackers;

    +
    • +
  • +

    Applying the principle of least privilege to the system's users;

    +
    • +
  • +

    Minimizing the potential impact of security breaches by implementing separation of duties in both the software and operational architecture;

    +
    • +
  • +

    Conducting regular, automated audits and reviews of the system, such as ensuring that users' privileges are correctly configured and that any new code has been audited and approved by independent parties;

    +
    • +
  • +

    Failing securely in the event of errors to avoid compromising the security of the system.

    +
    • +
+

The appraisal process should be auditable and reproducible. +The integrity of the code and data during execution should be made an explicit objective, for example ensuring that the appraisal functions are computed in an attestable trusted execution environment (TEE).

+

The integrity of public and private key material and the secrecy of private key material must be ensured at all times. +This includes key material carried in attestation key triples and key material used to verify the authority of triples (such as public keys that identify trusted supply chain actors). +For more detailed information on protecting Trust Anchors, refer to Section 12.4 of [RFC9334].

+

The Verifier should use cryptographically protected, mutually authenticated secure channels to all its trusted input sources (Endorsers, RVPs, Verifier Owners). +These links must reach as deep as possible - possibly terminating within the appraisal session context - to avoid man-in-the-middle attacks. +Also consider minimizing the use of intermediaries: each intermediary becomes another party that needs to be trusted and therefore factored in the Attesters and Relying Parties' TCBs. +Refer to Section 12.2 of [RFC9334] for information on Conceptual Messages protection.

+

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

+
+
+
+
+

+11. IANA Considerations +

+
+
+

+11.1. New COSE Header Parameters +

+

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

+
+
+
+
+

+11.2. New CBOR Tags +

+

IANA is requested to allocate the following tags in the "CBOR Tags" registry [IANA.cbor-tags], preferably with the specific CBOR tag value requested:

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

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

+
+
+
+
+

+11.3. CoRIM Map Registry +

+

This document defines a new registry titled "CoRIM Map". +The registry uses integer values as index values for items in 'unsigned-corim-map' CBOR maps.

+

Future registrations for this registry are to be made based on [RFC8126] as follows:

+
+ + + + + + + + + + + + + + + + + + +
+Table 9: +CoRIM Map Items Registration Procedures +
RangeRegistration Procedures
0-127Standards Action
128-255Specification Required
+
+

All negative values are reserved for Private Use.

+

Initial registrations for the "CoRIM Map" registry are provided below. +Assignments consist of an integer index value, the item name, and a reference to the defining specification.

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Table 10: +CoRIM Map Items Initial Registrations +
IndexItem NameSpecification
0idRFCthis
1tagsRFCthis
2dependent-rimsRFCthis
3profileRFCthis
4rim-validityRFCthis
5entitiesRFCthis
3-255Unassigned 
+
+
+
+
+
+

+11.4. CoMID Map Registry +

+

This document defines a new registry titled "CoMID Map". +The registry uses integer values as index values for items in 'concise-mid-tag' CBOR maps.

+

Future registrations for this registry are to be made based on [RFC8126] as follows:

+
+ + + + + + + + + + + + + + + + + + +
+Table 11: +CoMID Map Items Registration Procedures +
RangeRegistration Procedures
0-127Standards Action
128-255Specification Required
+
+

All negative values are reserved for Private Use.

+

Initial registrations for the "CoMID Map" registry are provided below. +Assignments consist of an integer index value, the item name, and a reference to the defining specification.

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Table 12: +CoMID Map Items Initial Registrations +
IndexItem NameSpecification
0languageRFCthis
1tag-identityRFCthis
2entityRFCthis
3linked-tagsRFCthis
4triplesRFCthis
5-255Unassigned 
+
+
+
+
+
+

+11.5. CoBOM Map Registry +

+

This document defines a new registry titled "CoBOM Map". +The registry uses integer values as index values for items in 'concise-bom-tag' CBOR maps.

+

Future registrations for this registry are to be made based on [RFC8126] as follows:

+
+ + + + + + + + + + + + + + + + + + +
+Table 13: +CoBOM Map Items Registration Procedures +
RangeRegistration Procedures
0-127Standards Action
128-255Specification Required
+
+

All negative values are reserved for Private Use.

+

Initial registrations for the "CoBOM Map" registry are provided below. +Assignments consist of an integer index value, the item name, and a reference to the defining specification.

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Table 14: +CoBOM Map Items Initial Registrations +
IndexItem NameSpecification
0tag-identityRFCthis
1tags-listRFCthis
2bom-validityRFCthis
5-255Unassigned 
+
+
+
+
+
+

+11.6. New Media Types +

+

IANA is requested to add the following media types to the "Media Types" +registry [IANA.media-types].

+
+ + + + + + + + + + + + + + + + + + + + + +
+Table 15: +New Media Types +
NameTemplateReference
corim-signed+cborapplication/corim-signed+cborRFCthis, (Section 11.6.1)
corim-unsigned+cborapplication/corim-unsigned+cborRFCthis, (Section 11.6.2)
+
+
+
+

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

(Section 10) of RFCthis

+
+
+
Interoperability considerations:
+
+

n/a

+
+
+
Published specification:
+
+

RFCthis

+
+
+
Applications that use this media type:
+
+

Attestation Verifiers, Endorsers and Reference-Value providers that need to +transfer 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 and email address to contact for further information:
+
+

RATS WG mailing list (rats@ietf.org)

+
+
+
Intended usage:
+
+

COMMON

+
+
+
Restrictions on usage:
+
+

none

+
+
+
Author/Change controller:
+
+

IETF

+
+
+
Provisional registration?
+
+

Maybe

+
+
+
+
+
+
+
+

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

Section 10 of RFCthis

+
+
+
Interoperability considerations:
+
+

n/a

+
+
+
Published specification:
+
+

RFCthis

+
+
+
Applications that use this media type:
+
+

Attestation Verifiers, Endorsers and Reference-Value providers that need to +transfer unprotected CoRIM payloads over HTTP(S), CoAP(S), and other +transports.

+
+
+
Fragment identifier considerations:
+
+

n/a

+
+
+
Magic number(s):
+
+

D9 01 F5, D9 01 F4 D9 01 F5

+
+
+
File extension(s):
+
+

n/a

+
+
+
Macintosh file type code(s):
+
+

n/a

+
+
+
Person and email address to contact for further information:
+
+

RATS WG mailing list (rats@ietf.org)

+
+
+
Intended usage:
+
+

COMMON

+
+
+
Restrictions on usage:
+
+

none

+
+
+
Author/Change controller:
+
+

IETF

+
+
+
Provisional registration?
+
+

Maybe

+
+
+
+
+
+
+
+
+
+

+11.7. CoAP Content-Formats Registration +

+

IANA is requested to register the two following Content-Format numbers in the +"CoAP Content-Formats" sub-registry, within the "Constrained RESTful +Environments (CoRE) Parameters" Registry [IANA.core-parameters]:

+ + + + + + + + + + + + + + + + + + + + + + + + +
+Table 16: +New Content-Formats +
Content-TypeContent CodingIDReference
application/corim-signed+cbor-TBD1RFCthis
application/corim-unsigned+cbor-TBD2RFCthis
+
+
+
+
+
+
+

+12. References +

+
+
+

+12.1. Normative References +

+
+
[IANA.cbor-tags]
+
+IANA, "Concise Binary Object Representation (CBOR) Tags", <https://www.iana.org/assignments/cbor-tags>.
+
+
[IANA.core-parameters]
+
+IANA, "Constrained RESTful Environments (CoRE) Parameters", <https://www.iana.org/assignments/core-parameters>.
+
+
[IANA.language-subtag-registry]
+
+IANA, "Language Subtag Registry", <https://www.iana.org/assignments/language-subtag-registry>.
+
+
[IANA.media-types]
+
+IANA, "Media Types", <https://www.iana.org/assignments/media-types>.
+
+
[IANA.named-information]
+
+IANA, "Named Information", <https://www.iana.org/assignments/named-information>.
+
+
[RFC2119]
+
+Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
+
+
[RFC4122]
+
+Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, , <https://www.rfc-editor.org/rfc/rfc4122>.
+
+
[RFC5280]
+
+Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/rfc/rfc5280>.
+
+
[RFC7468]
+
+Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, , <https://www.rfc-editor.org/rfc/rfc7468>.
+
+
[RFC8174]
+
+Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
+
+
[RFC8610]
+
+Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, , <https://www.rfc-editor.org/rfc/rfc8610>.
+
+
[RFC9090]
+
+Bormann, C., "Concise Binary Object Representation (CBOR) Tags for Object Identifiers", RFC 9090, DOI 10.17487/RFC9090, , <https://www.rfc-editor.org/rfc/rfc9090>.
+
+
[RFC9334]
+
+Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, , <https://www.rfc-editor.org/rfc/rfc9334>.
+
+
[RFC9393]
+
+Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Waltermire, "Concise Software Identification Tags", RFC 9393, DOI 10.17487/RFC9393, , <https://www.rfc-editor.org/rfc/rfc9393>.
+
+
[STD66]
+
+Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <https://www.rfc-editor.org/rfc/rfc3986>.
+
+
[STD94]
+
+Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/rfc/rfc8949>.
+
+
[STD96]
+
+Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/rfc/rfc9052>.
+
+
[X.690]
+
+International Telecommunications Union, "Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, , <https://www.itu.int/rec/T-REC-X.690>.
+
+
+
+
+
+
+

+12.2. Informative References +

+
+
[DICE.Layer]
+
+Trusted Computing Group, "DICE Layering Architecture", Version 1.0, Revision 0.19 , , <https://trustedcomputinggroup.org/wp-content/uploads/DICE-Layering-Architecture-r19_pub.pdf>.
+
+
[I-D.fdb-rats-psa-endorsements]
+
+Fossati, T., Deshpande, Y., and H. Birkholz, "Arm's Platform Security Architecture (PSA) Attestation Verifier Endorsements", Work in Progress, Internet-Draft, draft-fdb-rats-psa-endorsements-05, , <https://datatracker.ietf.org/doc/html/draft-fdb-rats-psa-endorsements-05>.
+
+
[I-D.ietf-rats-ar4si]
+
+Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V. Scarlata, "Attestation Results for Secure Interactions", Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-rats-ar4si-07>.
+
+
[I-D.ietf-rats-cobom]
+
+"*** BROKEN REFERENCE ***".
+
+
[I-D.ietf-rats-concise-ta-stores]
+
+Wallace, C., Housley, R., Fossati, T., and Y. Deshpande, "Concise TA Stores (CoTS)", Work in Progress, Internet-Draft, draft-ietf-rats-concise-ta-stores-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-rats-concise-ta-stores-02>.
+
+
[I-D.ietf-rats-eat]
+
+Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", Work in Progress, Internet-Draft, draft-ietf-rats-eat-31, , <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-31>.
+
+
[I-D.ietf-rats-endorsements]
+
+Thaler, D., Birkholz, H., and T. Fossati, "RATS Endorsements", Work in Progress, Internet-Draft, draft-ietf-rats-endorsements-03, , <https://datatracker.ietf.org/doc/html/draft-ietf-rats-endorsements-03>.
+
+
[I-D.tschofenig-rats-psa-token]
+
+Tschofenig, H., Frost, S., Brossard, M., Shaw, A. L., and T. Fossati, "Arm's Platform Security Architecture (PSA) Attestation Token", Work in Progress, Internet-Draft, draft-tschofenig-rats-psa-token-24, , <https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-24>.
+
+
[IANA.coswid]
+
+IANA, "Concise Software Identifier (CoSWID)", <https://www.iana.org/assignments/coswid>.
+
+
[RFC7942]
+
+Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, , <https://www.rfc-editor.org/rfc/rfc7942>.
+
+
[RFC8126]
+
+Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/rfc/rfc8126>.
+
+
+
+
+
+
+
+
+

+Appendix A. Base CoRIM CDDL +

+
+
+corim = tagged-concise-rim-type-choice
+
+$concise-rim-type-choice /= tagged-corim-map
+$concise-rim-type-choice /= tagged-signed-corim
+
+concise-bom-tag = {
+  &(tag-identity: 0) => tag-identity-map
+  &(tags-list: 1) => [ + tag-identity-map ],
+  &(bom-validity: 2) => validity-map
+  * $$concise-bom-tag-extension
+}
+
+$concise-tag-type-choice /= tagged-concise-swid-tag
+$concise-tag-type-choice /= tagged-concise-mid-tag
+$concise-tag-type-choice /= tagged-concise-bom-tag
+
+corim-entity-map =
+  entity-map<$corim-role-type-choice, $$corim-entity-map-extension>
+
+$corim-id-type-choice /= tstr
+$corim-id-type-choice /= uuid-type
+
+corim-locator-map = {
+  &(href: 0) => uri
+  ? &(thumbprint: 1) => digest
+}
+
+corim-map = {
+  &(id: 0) => $corim-id-type-choice
+  &(tags: 1) => [ + $concise-tag-type-choice ]
+  ? &(dependent-rims: 2) => [ + corim-locator-map ]
+  ? &(profile: 3) => $profile-type-choice
+  ? &(rim-validity: 4) => validity-map
+  ? &(entities: 5) => [ + corim-entity-map ]
+  * $$corim-map-extension
+}
+
+corim-meta-map = {
+  &(signer: 0) => corim-signer-map
+  ? &(signature-validity: 1) => validity-map
+}
+
+$corim-role-type-choice /= &(manifest-creator: 1)
+
+corim-signer-map = {
+  &(signer-name: 0) => $entity-name-type-choice
+  ? &(signer-uri: 1) => uri
+  * $$corim-signer-map-extension
+}
+
+COSE-Sign1-corim = [
+  protected: bstr .cbor protected-corim-header-map
+  unprotected: unprotected-corim-header-map
+  payload: bstr .cbor tagged-corim-map
+  signature: bstr
+]
+
+$profile-type-choice /= uri
+$profile-type-choice /= tagged-oid-type
+
+protected-corim-header-map = {
+  &(alg: 1) => int
+  &(content-type: 3) => "application/corim-unsigned+cbor"
+  &(kid: 4) => bstr
+  &(corim-meta: 8) => bstr .cbor corim-meta-map
+  * cose-label => cose-value
+}
+
+signed-corim = #6.18(COSE-Sign1-corim)
+
+tagged-corim-map = #6.501(corim-map)
+
+
+tagged-concise-rim-type-choice = #6.500($concise-rim-type-choice)
+
+tagged-signed-corim = #6.502(signed-corim)
+
+tagged-concise-swid-tag = #6.505(bytes .cbor concise-swid-tag)
+
+tagged-concise-mid-tag = #6.506(bytes .cbor concise-mid-tag)
+
+tagged-concise-bom-tag = #6.508(bytes .cbor concise-bom-tag)
+
+unprotected-corim-header-map = {
+  * cose-label => cose-value
+}
+
+validity-map = {
+  ? &(not-before: 0) => time
+  &(not-after: 1) => time
+}
+
+concise-mid-tag = {
+  ? &(language: 0) => text
+  &(tag-identity: 1) => tag-identity-map
+  ? &(entities: 2) => [ + comid-entity-map ]
+  ? &(linked-tags: 3) => [ + linked-tag-map ]
+  &(triples: 4) => triples-map
+  * $$concise-mid-tag-extension
+}
+
+accepted-claims-set = {
+  &(state-triples: 0) => [ + endorsed-triple-record ]
+  ? &(identity-triples: 1) => [ + identity-triple-record ]
+  ? &(coswid-triples: 2) => [ + ev-coswid-triple-record ]
+  * $$accepted-claims-set-extension
+}
+
+attest-key-triple-record = [
+  environment-map
+  [ + $crypto-key-type-choice ]
+]
+
+$class-id-type-choice /= tagged-oid-type
+$class-id-type-choice /= tagged-uuid-type
+$class-id-type-choice /= tagged-bytes
+
+class-map = non-empty<{
+  ? &(class-id: 0) => $class-id-type-choice
+  ? &(vendor: 1) => tstr
+  ? &(model: 2) => tstr
+  ? &(layer: 3) => uint
+  ? &(index: 4) => uint
+}>
+
+comid-entity-map =
+  entity-map<$comid-role-type-choice, $$comid-entity-map-extension>
+
+$comid-role-type-choice /= &(tag-creator: 0)
+$comid-role-type-choice /= &(creator: 1)
+$comid-role-type-choice /= &(maintainer: 2)
+
+conditional-endorsement-series-triple-record = [
+  condition: stateful-environment-record
+  series: [ + conditional-series-record ]
+]
+
+conditional-series-record = [
+  selection: [ + measurement-map]
+  addition: [ + measurement-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
+$crypto-key-type-choice /= tagged-pkix-asn1der-cert-type
+$crypto-key-type-choice /= tagged-bytes
+
+tagged-pkix-base64-key-type = #6.554(tstr)
+tagged-pkix-base64-cert-type = #6.555(tstr)
+tagged-pkix-base64-cert-path-type = #6.556(tstr)
+tagged-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)
+tagged-pkix-asn1der-cert-type = #6.562(bstr)
+
+domain-dependency-triple-record = [
+  $domain-type-choice
+  [ + $domain-type-choice ]
+]
+
+domain-membership-triple-record = [
+  $domain-type-choice
+  [ + environment-map ]
+]
+
+conditional-endorsement-triple-record = [
+  conditions: [ + stateful-environment-record ]
+  endorsements: [ + endorsed-triple-record ]
+]
+
+$domain-type-choice /= uint
+$domain-type-choice /= text
+$domain-type-choice /= tagged-uuid-type
+$domain-type-choice /= tagged-oid-type
+
+endorsed-triple-record = [
+  condition: environment-map
+  endorsement: [ + measurement-map ]
+]
+
+entity-map<role-type-choice, extension-socket> = {
+  &(entity-name: 0) => $entity-name-type-choice
+  ? &(reg-id: 1) => uri
+  &(role: 2) => [ + role-type-choice ]
+  * extension-socket
+}
+
+$entity-name-type-choice /= text
+
+environment-map = non-empty<{
+  ? &(class: 0) => class-map
+  ? &(instance: 1) => $instance-id-type-choice
+  ? &(group: 2) => $group-id-type-choice
+}>
+
+flags-map = {
+  ? &(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
+$measured-element-type-choice /= tstr
+
+measurement-map = {
+  ? &(mkey: 0) => $measured-element-type-choice
+  &(mval: 1) => measurement-values-map
+  ? &(authorized-by: 2) => [ + $crypto-key-type-choice ]
+}
+
+measurement-values-map = non-empty<{
+  ? &(version: 0) => version-map
+  ? &(svn: 1) => svn-type-choice
+  ? &(digests: 2) => digests-type
+  ? &(flags: 3) => flags-map
+  ? (
+      &(raw-value: 4) => $raw-value-type-choice,
+      ? &(raw-value-mask: 5) => raw-value-mask-type
+    )
+  ? &(mac-addr: 6) => mac-addr-type-choice
+  ? &(ip-addr: 7) =>  ip-addr-type-choice
+  ? &(serial-number: 8) => text
+  ? &(ueid: 9) => ueid-type
+  ? &(uuid: 10) => uuid-type
+  ? &(name: 11) => text
+  ? &(cryptokeys: 13) => [ + $crypto-key-type-choice ]
+  ? &(integrity-registers: 14) => integrity-registers
+  * $$measurement-values-map-extension
+}>
+
+non-empty<M> = (M) .and ({ + any => any })
+
+oid-type = bytes
+tagged-oid-type = #6.111(oid-type)
+
+$raw-value-type-choice /= tagged-bytes
+
+raw-value-mask-type = bytes
+
+reference-triple-record = [
+  ref-env: environment-map
+  ref-claims: [ + measurement-map ]
+]
+
+stateful-environment-record = [
+  environment: environment-map,
+  claims-list: [ + measurement-map ]
+]
+
+svn-type = uint
+svn = svn-type
+min-svn = svn-type
+tagged-svn = #6.552(svn)
+tagged-min-svn = #6.553(min-svn)
+svn-type-choice = svn / tagged-svn / tagged-min-svn
+
+$tag-id-type-choice /= tstr
+$tag-id-type-choice /= uuid-type
+
+tag-identity-map = {
+  &(tag-id: 0) => $tag-id-type-choice
+  ? &(tag-version: 1) => tag-version-type
+}
+
+$tag-rel-type-choice /= &(supplements: 0)
+$tag-rel-type-choice /= &(replaces: 1)
+
+tag-version-type = uint .default 0
+
+tagged-bytes = #6.560(bytes)
+
+triples-map = non-empty<{
+  ? &(reference-triples: 0) =>
+    [ + reference-triple-record ]
+  ? &(endorsed-triples: 1) =>
+    [ + endorsed-triple-record ]
+  ? &(identity-triples: 2) =>
+    [ + identity-triple-record ]
+  ? &(attest-key-triples: 3) =>
+    [ + attest-key-triple-record ]
+  ? &(dependency-triples: 4) =>
+    [ + domain-dependency-triple-record ]
+  ? &(membership-triples: 5) =>
+    [ + domain-membership-triple-record ]
+  ? &(coswid-triples: 6) =>
+    [ + coswid-triple-record ]
+  ? &(conditional-endorsement-series-triples: 8) =>
+    [ + conditional-endorsement-series-triple-record ]
+  ? &(conditional-endorsement-triples: 10) =>
+    [ + conditional-endorsement-triple-record ]
+  * $$triples-map-extension
+}>
+
+ueid-type = bytes .size 33
+tagged-ueid-type = #6.550(ueid-type)
+
+uuid-type = bytes .size 16
+tagged-uuid-type = #6.37(uuid-type)
+
+version-map = {
+  &(version: 0) => text
+  ? &(version-scheme: 1) => $version-scheme
+}
+
+digest = [
+  alg: (int / text),
+  val: bytes
+]
+
+digests-type = [ + digest ]
+
+integrity-register-id-type-choice = uint / text
+
+integrity-registers = {
+  + integrity-register-id-type-choice => digests-type
+}
+
+concise-swid-tag = {
+  tag-id => text / bstr .size 16,
+  tag-version => integer,
+  ? corpus => bool,
+  ? patch => bool,
+  ? supplemental => bool,
+  software-name => text,
+  ? software-version => text,
+  ? version-scheme => $version-scheme,
+  ? media => text,
+  ? software-meta => one-or-more<software-meta-entry>,
+  entity => one-or-more<entity-entry>,
+  ? link => one-or-more<link-entry>,
+  ? payload-or-evidence,
+  * $$coswid-extension,
+  global-attributes,
+}
+
+payload-or-evidence //= ( payload => payload-entry )
+payload-or-evidence //= ( evidence => evidence-entry )
+
+any-uri = uri
+label = text / int
+
+$version-scheme /= multipartnumeric
+$version-scheme /= multipartnumeric-suffix
+$version-scheme /= alphanumeric
+$version-scheme /= decimal
+$version-scheme /= semver
+$version-scheme /= int / text
+
+any-attribute = (
+  label => one-or-more<text> / one-or-more<int>
+)
+
+one-or-more<T> = T / [ 2* T ]
+
+global-attributes = (
+  ? lang => text,
+  * any-attribute,
+)
+
+hash-entry = [
+  hash-alg-id: int,
+  hash-value: bytes,
+]
+
+entity-entry = {
+  entity-name => text,
+  ? reg-id => any-uri,
+  role => one-or-more<$role>,
+  ? thumbprint => hash-entry,
+  * $$entity-extension,
+  global-attributes,
+}
+
+$role /= tag-creator
+$role /= software-creator
+$role /= aggregator
+$role /= distributor
+$role /= licensor
+$role /= maintainer
+$role /= int / text
+
+link-entry = {
+  ? artifact => text,
+  href => any-uri,
+  ? media => text,
+  ? ownership => $ownership,
+  rel => $rel,
+  ? media-type => text,
+  ? use => $use,
+  * $$link-extension,
+  global-attributes,
+}
+
+$ownership /= shared
+$ownership /= private
+$ownership /= abandon
+$ownership /= int / text
+
+$rel /= ancestor
+$rel /= component
+$rel /= feature
+$rel /= installationmedia
+$rel /= packageinstaller
+$rel /= parent
+$rel /= patches
+$rel /= requires
+$rel /= see-also
+$rel /= supersedes
+$rel /= supplemental
+$rel /= -256..64436 / text
+
+$use /= optional
+$use /= required
+$use /= recommended
+$use /= int / text
+
+software-meta-entry = {
+  ? activation-status => text,
+  ? channel-type => text,
+  ? colloquial-version => text,
+  ? description => text,
+  ? edition => text,
+  ? entitlement-data-required => bool,
+  ? entitlement-key => text,
+  ? generator =>  text / bstr .size 16,
+  ? persistent-id => text,
+  ? product => text,
+  ? product-family => text,
+  ? revision => text,
+  ? summary => text,
+  ? unspsc-code => text,
+  ? unspsc-version => text,
+  * $$software-meta-extension,
+  global-attributes,
+}
+
+path-elements-group = ( ? directory => one-or-more<directory-entry>,
+                        ? file => one-or-more<file-entry>,
+                      )
+
+resource-collection = (
+  path-elements-group,
+  ? process => one-or-more<process-entry>,
+  ? resource => one-or-more<resource-entry>,
+  * $$resource-collection-extension,
+)
+
+file-entry = {
+  filesystem-item,
+  ? size => uint,
+  ? file-version => text,
+  ? hash => hash-entry,
+  * $$file-extension,
+  global-attributes,
+}
+
+directory-entry = {
+  filesystem-item,
+  ? path-elements => { path-elements-group },
+  * $$directory-extension,
+  global-attributes,
+}
+
+process-entry = {
+  process-name => text,
+  ? pid => integer,
+  * $$process-extension,
+  global-attributes,
+}
+
+resource-entry = {
+  type => text,
+  * $$resource-extension,
+  global-attributes,
+}
+
+filesystem-item = (
+  ? key => bool,
+  ? location => text,
+  fs-name => text,
+  ? root => text,
+)
+
+payload-entry = {
+  resource-collection,
+  * $$payload-extension,
+  global-attributes,
+}
+
+evidence-entry = {
+  resource-collection,
+  ? date => integer-time,
+  ? device-id => text,
+  ? location => text,
+  * $$evidence-extension,
+  global-attributes,
+}
+
+integer-time = #6.1(int)
+
+tag-id = 0
+software-name = 1
+entity = 2
+evidence = 3
+link = 4
+software-meta = 5
+payload = 6
+hash = 7
+corpus = 8
+patch = 9
+media = 10
+supplemental = 11
+tag-version = 12
+software-version = 13
+version-scheme = 14
+lang = 15
+directory = 16
+file = 17
+process = 18
+resource = 19
+size = 20
+file-version = 21
+key = 22
+location = 23
+fs-name = 24
+root = 25
+path-elements = 26
+process-name = 27
+pid = 28
+type = 29
+entity-name = 31
+reg-id = 32
+role = 33
+thumbprint = 34
+date = 35
+device-id = 36
+artifact = 37
+href = 38
+ownership = 39
+rel = 40
+media-type = 41
+use = 42
+activation-status = 43
+channel-type = 44
+colloquial-version = 45
+description = 46
+edition = 47
+entitlement-data-required = 48
+entitlement-key = 49
+generator = 50
+persistent-id = 51
+product = 52
+product-family = 53
+revision = 54
+summary = 55
+unspsc-code = 56
+unspsc-version = 57
+
+multipartnumeric = 1
+multipartnumeric-suffix = 2
+alphanumeric = 3
+decimal = 4
+semver = 16384
+
+tag-creator=1
+software-creator=2
+aggregator=3
+distributor=4
+licensor=5
+maintainer=6
+
+abandon=1
+private=2
+shared=3
+
+ancestor=1
+component=2
+feature=3
+installationmedia=4
+packageinstaller=5
+parent=6
+patches=7
+requires=8
+see-also=9
+supersedes=10
+
+optional=1
+required=2
+recommended=3
+
+
+
+
+
+
+
+

+Acknowledgments +

+

Carl Wallace for review and comments on this document.

+
+
+
+
+

+Contributors +

+
+
Carsten Bormann
+
Universität Bremen TZI
+
Postfach 330440
+
+D-28359 Bremen +
+
Germany
+
+Phone: ++49-421-218-63921 +
+ +
+

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

+
+
Andrew Draper
+
Intel Corporation
+ +
+

Andrew contributed the concept, description, and semantics of conditional endorsements as well as consistent contribution to weekly reviews of others' edits.

+
+
Dionna Glaze
+
Google LLC
+ +
+

Dionna contributed many clarifying questions and disambiguations to the semantics of attestation appraisal as well as consistent contribution to weekly reviews of others' edits.

+
+
+
+
+

+Authors' Addresses +

+
+
Henk Birkholz
+
Fraunhofer SIT
+ +
+
+
Thomas Fossati
+
Linaro
+ +
+
+
Yogesh Deshpande
+
arm
+ +
+
+
Ned Smith
+
Intel
+ +
+
+
Wei Pan
+
Huawei Technologies
+ +
+
+
+ + + diff --git a/Section-restructuring/draft-ietf-rats-corim.txt b/Section-restructuring/draft-ietf-rats-corim.txt new file mode 100644 index 00000000..b09b3443 --- /dev/null +++ b/Section-restructuring/draft-ietf-rats-corim.txt @@ -0,0 +1,4606 @@ + + + + +Remote ATtestation ProcedureS H. Birkholz +Internet-Draft Fraunhofer SIT +Intended status: Standards Track T. Fossati +Expires: 19 April 2025 Linaro + Y. Deshpande + arm + N. Smith + Intel + W. Pan + Huawei Technologies + 16 October 2024 + + + Concise Reference Integrity Manifest + draft-ietf-rats-corim-latest + +Abstract + + Remote Attestation Procedures (RATS) enable Relying Parties to assess + the trustworthiness of a remote Attester and therefore to decide + whether or not to engage in secure interactions with it. Evidence + about trustworthiness can be rather complex and it is deemed + unrealistic that every Relying Party is capable of the appraisal of + Evidence. Therefore that burden is typically offloaded to a + Verifier. In order to conduct Evidence appraisal, a Verifier + requires not only fresh Evidence from an Attester, but also trusted + Endorsements and Reference Values from Endorsers and Reference Value + Providers, such as manufacturers, distributors, or device owners. + This document specifies the information elements for representing + Endorsements and Reference Values in CBOR format. + +Discussion Venues + + This note is to be removed before publishing as an RFC. + + Source for this draft and an issue tracker can be found at + https://github.com/ietf-rats-wg/draft-ietf-rats-corim. + +Status of This Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at https://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on 19 April 2025. + +Copyright Notice + + Copyright (c) 2024 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (https://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Code Components + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. + +Table of Contents + + 1. Introduction + 1.1. Terminology and Requirements Language + 2. Verifier Reconciliation + 2.1. Internal Representation + 2.2. Interacting with an ACS + 2.3. Quantizing Inputs + 3. Typographical Conventions for CDDL + 4. Concise Reference Integrity Manifest (CoRIM) + 4.1. CoRIM Map + 4.1.1. Identity + 4.1.2. Tags + 4.1.3. Locator Map + 4.1.4. Profile Types + 4.1.5. Entities + 4.2. Signed CoRIM + 4.2.1. Protected Header Map + 4.2.2. Meta Map + 4.2.2.1. Signer Map + 4.2.3. Unprotected CoRIM Header Map + 5. Concise Module Identifier (CoMID) + 5.1. Structure + 5.1.1. Tag Identity + 5.1.1.1. Tag ID + 5.1.1.2. Tag Version + 5.1.2. Entities + 5.1.3. Linked Tag + 5.1.4. Triples + 5.1.4.1. Environments + 5.1.4.1.1. Environment Class + 5.1.4.1.2. Environment Instance + 5.1.4.1.3. Environment Group + 5.1.4.1.4. Measurements + 5.1.4.1.4.1. Measurement Keys + 5.1.4.1.4.2. Measurement Values + 5.1.4.1.4.3. Version + 5.1.4.1.4.4. Security Version Number + 5.1.4.1.4.5. Flags + 5.1.4.1.4.6. Raw Values Types + 5.1.4.1.4.7. Address Types + 5.1.4.1.5. Crypto Keys + 5.1.4.1.6. Integrity Registers + 5.1.4.1.7. Domain Types + 5.1.4.2. Reference Values Triple + 5.1.4.3. Endorsed Values Triple + 5.1.4.4. Conditional Endorsement Triple + 5.1.4.5. Conditional Endorsement Series Triple + 5.1.4.6. Device Identity Triple + 5.1.4.7. Attest Key Triple + 5.1.4.8. Domain Dependency Triple + 5.1.4.9. Domain Membership Triple + 5.1.4.10. CoMID-CoSWID Linking Triple + 5.2. Extensibility + 5.2.1. Map Extensions + 5.2.2. Data Type Extensions + 6. CoBOM + 6.1. Structure + 7. Common Types + 7.1. Non-Empty + 7.2. Entity + 7.3. Validity + 7.4. UUID + 7.5. UEID + 7.6. OID + 7.7. Digest + 7.8. Tagged Bytes Type + 8. Appraisal of CoRIM-based Inputs + 8.1. Appraisal Procedure + 8.2. Verifier Abstraction + 8.2.1. Internal Representation of Conceptual Messages + 8.2.1.1. Internal Representation of Evidence + 8.2.1.2. Internal Representation of Reference Values + 8.2.1.3. Internal Representation of Endorsed Values + 8.2.1.4. Internal Representation of Policy Statements + 8.2.1.5. Internal Representation of Attestation Results + 8.2.2. Internal Representation of ACS + 8.2.3. Internal Representation of Attestation Results Set + (ARS) + 8.3. Input Validation and Transformation (Phase 1) + 8.3.1. Input Validation + 8.3.1.1. CoRIM Selection + 8.3.1.2. Tags Extraction and Validation + 8.3.1.3. CoBOM Extraction + 8.3.2. Evidence Collection + 8.3.2.1. Cryptographic Validation of Evidence + 8.3.3. Input Transformation + 8.3.3.1. Appraisal Context Construction + 8.3.3.2. Reference Triples Transformation + 8.3.3.3. Endorsement Triples Transformations + 8.3.3.4. Evidence Tranformation + 8.4. ACS Augmentation - Phases 2, 3, and 4 + 8.4.1. ACS Requirements + 8.4.1.1. ACS Processing Requirements + 8.4.1.1.1. Ordering of triple processing + 8.4.1.2. ACS Augmentation Requirements + 8.4.2. Evidence Augmentation (Phase 2) + 8.4.2.1. Appraisal Claims Set Initialization + 8.4.2.1.1. The authorized-by field in Appraisal Claims Set + 8.4.3. Reference Values Corroboration and Augmentation (Phase + 3) + 8.4.4. Endorsed Values Augmentation (Phase 4) + 8.4.4.1. Processing Endorsements + 8.4.4.2. Processing Conditional Endorsements + 8.4.4.3. Processing Conditional Endorsement Series + 8.5. Examples for optional phases 5, 6, and 7 + 8.6. Comparing a condition ECT against the ACS + 8.6.1. Comparing a condition ECT against a single ACS entry + 8.6.2. Environment Comparison + 8.6.3. Authority comparison + 8.6.4. Element list comparison + 8.6.5. Element map comparison + 8.6.6. Measurement values map map Comparison + 8.6.6.1. Comparison of a single measurement-values-map + codepoint + 8.6.6.1.1. Comparison for version entries + 8.6.6.1.2. Comparison for svn entries + 8.6.6.1.3. Comparison for digests entries + 8.6.6.1.4. Comparison for raw-value entries + 8.6.6.1.5. Comparison for cryptokeys entries + 8.6.6.1.6. Comparison for Integrity Registers + 8.6.7. Profile-directed Comparison + 9. Implementation Status + 9.1. Veraison + 10. Security and Privacy Considerations + 11. IANA Considerations + 11.1. New COSE Header Parameters + 11.2. New CBOR Tags + 11.3. CoRIM Map Registry + 11.4. CoMID Map Registry + 11.5. CoBOM Map Registry + 11.6. New Media Types + 11.6.1. corim-signed+cbor + 11.6.2. corim-unsigned+cbor + 11.7. CoAP Content-Formats Registration + 12. References + 12.1. Normative References + 12.2. Informative References + Appendix A. Base CoRIM CDDL + Acknowledgments + Contributors + Authors' Addresses + +1. 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. Endorsements and Reference Values are obtained from + relevant supply chain actors, such as manufacturers, distributors, or + device owners. In a complex supply chain, multiple actors will + likely produce these values over several points in time. As such, + one supply chain actor will only provide the subset of + characteristics that they know about the Attester. A proper subset + is typical because a certain supply chain actor will be the + responsible authority for only a system component/module that is + measured amongst a long chain of measurements. Attesters vary across + vendors and even across products from a single vendor. Not only + Attesters can evolve and therefore new measurement types need to be + expressed, but an Endorser may also want to provide new security + relevant attributes about an Attester at a future point in time. + + This document specifies Concise Reference Integrity Manifests (CoRIM) + - a CBOR [STD94] 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 + distributed supply chain into a single homogeneous view. See + Section 2. + +1.1. Terminology and Requirements Language + + This document uses terms and concepts defined by the RATS + architecture. For a complete glossary, see Section 4 of [RFC9334]. + + In this document, the term CoRIM message and CoRIM documents are used + as synonyms. A CoRIM data structure can be at rest (e.g., residing + in a file system as a document) or can be in flight (e.g., conveyed + as a message in a protocol exchange). The bytes composing the CoRIM + data structure are the same either way. + + The terminology from CBOR [STD94], CDDL [RFC8610] and COSE [STD96] + applies; in particular, CBOR diagnostic notation is defined in + Section 8 of [STD94] and Appendix G of [RFC8610]. Terms and concepts + are always referenced as proper nouns, i.e., with Capital Letters. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Verifier Reconciliation + + This specification describes the CoRIM format and documents how a + Verifier must process the CoRIM. This ensures that the behaviour of + the CoRIM-based appraisal is predictable and consistent, in a word + deterministic. + + A Verifier needs to reconcile its various inputs, with CoRIM being + one of them. In addition to the external CoRIM documents, the + Verifier is expected to create an internal representation for each + input and map each external representation to an internal one. By + using the internal representation, the Verifier processes inputs as + if they are part of a conversation, keeping track of who said what. + The origin of the inputs is tracked as _authority_. The authority for + the Claims in a CoRIM is the CoRIM issuer. To this effect, this + specification defines one possible internal representation of the + attester's actual state for use during the appraisal procedure, known + as Appraisal Claims Set (ACS). + + Effectively, Attesters, Reference Value Providers, Endorsers, + Verifier Owners, Relying Parties, and even the Verifier potentially + all contribute to the conversation. Each producer of corresponding + RATS Conceptual Messages can assert Claims about an Attester's actual + or allowed state. The Verifier's objective is to produce a list of + Claims that describe the Attester's presumed actual state. Producers + of RATS Conceptual Messages can assert contradictory assertions. For + example, a compromised Attester may produce false claims that + conflict with the Reference Values provided by a Reference Value + Provider (RVP). In essence, if Evidence is not corroborated by an + RVP's Claims, then the RVP's Claims are not included in the ACS. + + A Verifier relies on input from appraisal policy to identify relevant + assertions included in the ACS. For example, if a policy requires + corroborated assertions issued by a particular RVP, then those + assertions may be conveyed as Attestation Results. The Verifier may + produce new assertions as a result of an applied appraisal policy. + For example, if an appraisal procedure finds all of the components of + a subsystem are configured correctly, the policy may direct the + Verifier to produce new assertions, "Subsystem=X" has the Claim + "TRUSTED=TRUE". Consequently, the internal ACS structure is a + reconciled conversation between several producers of RATS Conceptual + Messages that has mapped each message into a consistent internal + representation, has associated the identity of the corresponding RATS + role with each assertion (the authority), and has applied Conceptual + Message constraints to the assertion. + + The CoRIM data model specified in this document covers the RATS + Conceptual Message types, "Reference Values" and "Endorsements". + Reference values and Endorsements are required for Verifier + reconciliation, and Evidence is required for corresponding internal + ACS creation as illustrated in Section 2.2. + +2.1. Internal Representation + + In this document CDDL is used to specify both the CoRIM structure and + to specify an internal representation for use in the appraisal + procedure. The actual internal representation of a Verifier is + implementation-specific and out-of-scope of this document. + Requirements for an internal representation of Conceptual Messages + are defined in Table 1, where each Conceptual Message type has a + structure as depicted by the _Structure_ column. The internal + representations used by this document are defined in Section 8.2.1. + +2.2. Interacting with an ACS + + Conceptual Messages interact with an ACS by specifying criteria that + should be met by the ACS and by presenting the assertions that should + be added to the ACS if the criteria are satisfied. Internal + representations of Conceptual Messages, ACS, and Attestation Results + Set (ARS) should satisfy the following requirements for Verifier + reconciliation and appraisal processing: + + +==============+====================+==============================+ + | CM Type | Structure | Description | + +==============+====================+==============================+ + | Evidence | List of Evidence | If the Attester is | + | | claims | authenticated, add Evidence | + | | | claims to the ACS with | + | | | Attester authority | + +--------------+--------------------+------------------------------+ + | Reference | List of Reference | If a reference value in a | + | Values | Values claims | CoRIM matches claims in the | + | | | ACS, then the authority of | + | | | the CoRIM issuer is added to | + | | | those claims. | + +--------------+--------------------+------------------------------+ + | Endorsements | List of expected | If the list of expected | + | | actual state | claims are in the ACS, then | + | | claims, List of | add the list of Endorsed | + | | Endorsed Values | Values claims to the ACS | + | | claims | with Endorser authority | + +--------------+--------------------+------------------------------+ + | Series | List of expected | If the expected claims are | + | Endorsements | actual state | in the ACS, and if the | + | | claims and a | series selection condition | + | | series of | is satisfied, then add the | + | | selection-addition | additional claims to the ACS | + | | tuples | with Endorser authority. | + | | | See Section 8.2.1.3 | + +--------------+--------------------+------------------------------+ + | Verifier | List of expected | If the list of expected | + | | actual state | claims are in the ACS, then | + | | claims, List of | add the list of Verifier- | + | | Verifier-generated | generated claims to the ACS | + | | claims | with Verifier authority | + +--------------+--------------------+------------------------------+ + | Policy | List of expected | If the list of expected | + | | actual state | claims are in the ACS, then | + | | claims, List of | add the list of Policy- | + | | Policy-generated | generated claims to the ACS | + | | claims | with Policy Owner authority | + +--------------+--------------------+------------------------------+ + | Attestation | List of expected | If the list of expected | + | Results | actual state | claims are in the ACS, then | + | | claims, List of | copy the list of Attestation | + | | expected | Results claims into the ARS. | + | | Attestation | See Section 8.2.3 | + | | Results claims | | + +--------------+--------------------+------------------------------+ + + Table 1: Conceptual Message Representation Requirements + +2.3. Quantizing Inputs + + + // Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/ + issues/242 + +3. Typographical Conventions for CDDL + + The CDDL definitions in this document follows the naming conventions + illustrated in Table 2. + + +========================+===============+==========================+ + | Type trait | Example | Typographical convention | + +========================+===============+==========================+ + | extensible | int / text / | $NAME-type-choice | + | type choice | ... | | + +------------------------+---------------+--------------------------+ + | closed type | int / text | NAME-type-choice | + | choice | | | + +------------------------+---------------+--------------------------+ + | group | ( 1 => int // | $$NAME-group-choice | + | choice | 2 => text ) | | + +------------------------+---------------+--------------------------+ + | group | ( 1 => int, 2 | NAME-group | + | | => text ) | | + +------------------------+---------------+--------------------------+ + | type | int | NAME-type | + +------------------------+---------------+--------------------------+ + | tagged type | #6.123(int) | tagged-NAME-type | + +------------------------+---------------+--------------------------+ + | map | { 1 => int, 2 | NAME-map | + | | => text } | | + +------------------------+---------------+--------------------------+ + | flags | &( a: 1, b: 2 | NAME-flags | + | | ) | | + +------------------------+---------------+--------------------------+ + + Table 2: Type Traits and Typographical Conventions + +4. Concise Reference Integrity Manifest (CoRIM) + + A CoRIM is a collection of tags and related metadata in a concise + CBOR [STD94] encoding. A CoRIM can be digitally signed with a COSE + [STD96] signature. A tag identifies and describes properties of + modules or components of a system. + + Tags can be of different types: + + * Concise Module ID (CoMID) tags (Section 5) contain metadata and + claims about the hardware and firmware modules. + + * Concise Software ID (CoSWID) tags ([RFC9393]) describe software + components. + + * Concise Bill of Material (CoBOM) tags (Section 6) contain the list + of CoMID and CoSWID tags that the Verifier should consider as + "active" at a certain point in time. + + The set of tags is extensible so that future specifications can add + new kinds of information. For example, Concise Trust Anchor Stores + (CoTS) ([I-D.ietf-rats-concise-ta-stores]) is currently being defined + as a standard CoRIM extension. + + Each CoRIM contains a unique identifier to distinguish a CoRIM from + other CoRIMs. + // Tracked at: https://github.com/ietf-rats-wg/draft-ietf-rats-corim/ + issues/73 + + CoRIM can also carry the following optional metadata: + + * A locator, which allows discovery of possibly related RIMs. + + * A profile identifier, which is used to interpret the information + contained in the enclosed tags. A profile allows the base CoRIM + CDDL definition to be customized to fit a specific Attester by + augmenting the base CDDL data definition via the specified + extension points or by constraining types defined. A profile MUST + NOT change the base CoRIM CDDL definition's semantics, which + includes not changing or overloading names and numbers registered + at IANA registries used by this document. For more detail, see + Section 4.1.4. + + * A validity period, which indicates the time period for which the + CoRIM contents are valid. + + * Information about the supply chain entities responsible for the + contents of the CoRIM and their associated roles. + + A CoRIM can be signed (Section 4.2) using COSE Sign1 to provide end- + to-end security to the CoRIM contents. When CoRIM is signed, the + protected header carries further identifying information about the + CoRIM signer. Alternatively, CoRIM can be encoded as a CBOR-tagged + payload (Section 4.1) and transported over a secure channel. + + The following CDDL describes the top-level CoRIM. + + corim = tagged-concise-rim-type-choice + + $concise-rim-type-choice /= tagged-corim-map + $concise-rim-type-choice /= tagged-signed-corim + +4.1. CoRIM Map + + The CDDL specification for the corim-map is as follows and this rule + and its constraints must be followed when creating or validating a + CoRIM map. + + corim-map = { + &(id: 0) => $corim-id-type-choice + &(tags: 1) => [ + $concise-tag-type-choice ] + ? &(dependent-rims: 2) => [ + corim-locator-map ] + ? &(profile: 3) => $profile-type-choice + ? &(rim-validity: 4) => validity-map + ? &(entities: 5) => [ + corim-entity-map ] + * $$corim-map-extension + } + + The following describes each child item of this map. + + * id (index 0): A globally unique identifier to identify a CoRIM. + Described in Section 4.1.1. + + * tags (index 1): An array of one or more CoMID or CoSWID tags. + Described in Section 4.1.2. + + * dependent-rims (index 2): One or more services supplying + additional, possibly dependent, manifests or related files. + Described in Section 4.1.3. + + * profile (index 3): An optional profile identifier for the tags + contained in this CoRIM. The profile MUST be understood by the + CoRIM processor. Failure to recognize the profile identifier MUST + result in the rejection of the entire CoRIM. See Section 4.1.4 + + * rim-validity (index 4): Specifies the validity period of the + CoRIM. Described in Section 7.3. + + * entities (index 5): A list of entities involved in a CoRIM life- + cycle. Described in Section 4.1.5. + + * $$corim-map-extension: This CDDL socket is used to add new + information structures to the corim-map. Described in + Section 11.3. + + tagged-corim-map = #6.501(corim-map) + +4.1.1. Identity + + A CoRIM Identifier uniquely identifies a CoRIM instance. The base + CDDL definition allows UUID and text identifiers. Other types of + identifiers could be defined as needed. + + $corim-id-type-choice /= tstr + $corim-id-type-choice /= uuid-type + +4.1.2. Tags + + A $concise-tag-type-choice is a tagged CBOR payload that carries + either a CoMID (Section 5), a CoSWID ([RFC9393]), or a CoBOM + (Section 6). + + $concise-tag-type-choice /= tagged-concise-swid-tag + $concise-tag-type-choice /= tagged-concise-mid-tag + $concise-tag-type-choice /= tagged-concise-bom-tag + +4.1.3. Locator Map + + The locator map contains pointers to repositories where dependent + manifests, certificates, or other relevant information can be + retrieved by the Verifier. + + corim-locator-map = { + &(href: 0) => uri + ? &(thumbprint: 1) => digest + } + + The following describes each child element of this type. + + * href (index 0): URI identifying the additional resource that can + be fetched + + * thumbprint (index 1): expected digest of the resource referenced + by href. See sec-common-hash-entry}}. + +4.1.4. Profile Types + + Profiling is the mechanism that allows the base CoRIM CDDL definition + to be customized to fit a specific Attester. + + A profile defines which of the optional parts of a CoRIM are + required, which are prohibited and which extension points are + exercised and how. A profile MUST NOT alter the syntax or semantics + of CoRIM types defined in this document. + + A profile MAY constrain the values of a given CoRIM type to a subset + of the values. A profile MAY extend the set of a given CoRIM type + using the defined extension points (Section 5.2). Exercised + extension points should preserve the intent of the original + semantics. + + CoRIM profiles SHOULD be specified in a publicly available document. + + A CoRIM profile can use one of the base CoRIM media types defined in + Section 11.6.1 and Section 11.6.2 with the profile parameter set to + the appropriate value. Alternatively, it MAY define and register its + own media type. + + A profile identifier is either an OID [RFC9090] or a URL [STD66]. + + The profile identifier uniquely identifies a documented profile. Any + changes to the profile, even the slightest deviation, is considered a + different profile that MUST have a different identifier. + + $profile-type-choice /= uri + $profile-type-choice /= tagged-oid-type + + For an example profile definition, see + [I-D.fdb-rats-psa-endorsements]. + +4.1.5. Entities + + The CoRIM Entity is an instantiation of the Entity generic + (Section 7.2) using a $corim-role-type-choice. + + The only role defined in this specification for a CoRIM Entity is + manifest-creator. + + The $$corim-entity-map-extension extension socket is empty in this + specification. + + corim-entity-map = + entity-map<$corim-role-type-choice, $$corim-entity-map-extension> + + $corim-role-type-choice /= &(manifest-creator: 1) + +4.2. Signed CoRIM + + signed-corim = #6.18(COSE-Sign1-corim) + + Signing a CoRIM follows the procedures defined in CBOR Object Signing + and Encryption [STD96]. A CoRIM tag MUST be wrapped in a COSE_Sign1 + structure. The CoRIM MUST be signed by the CoRIM creator. + + The following CDDL specification defines a restrictive subset of COSE + header parameters that MUST be used in the protected header alongside + additional information about the CoRIM encoded in a corim-meta-map + (Section 4.2.2). + + COSE-Sign1-corim = [ + protected: bstr .cbor protected-corim-header-map + unprotected: unprotected-corim-header-map + payload: bstr .cbor tagged-corim-map + signature: bstr + ] + + The following describes each child element of this type. + + * protected: A CBOR Encoded protected header which is protected by + the COSE signature. Contains information as given by Protected + Header Map below. + + * unprotected: A COSE header that is not protected by COSE + signature. + + * payload: A CBOR encoded tagged CoRIM. + + * signature: A COSE signature block which is the signature over the + protected and payload components of the signed CoRIM. + +4.2.1. Protected Header Map + + protected-corim-header-map = { + &(alg: 1) => int + &(content-type: 3) => "application/corim-unsigned+cbor" + &(kid: 4) => bstr + &(corim-meta: 8) => bstr .cbor corim-meta-map + * cose-label => cose-value + } + + The CoRIM protected header map uses some common COSE header + parameters plus an additional corim-meta parameter. The following + describes each child item of this map. + + * alg (index 1): An integer that identifies a signature algorithm. + + * content-type (index 3): A string that represents the "MIME Content + type" carried in the CoRIM payload. + + * kid (index 4): A bit string which is a key identity pertaining to + the CoRIM Issuer. + + * corim-meta (index 8): A map that contains metadata associated with + a signed CoRIM. Described in Section 4.2.2. + + Additional data can be included in the COSE header map as per + (Section 3 of [STD96]). + +4.2.2. Meta Map + + The CoRIM meta map identifies the entity or entities that create and + sign the CoRIM. This ensures the consumer is able to identify + credentials used to authenticate its signer. + + corim-meta-map = { + &(signer: 0) => corim-signer-map + ? &(signature-validity: 1) => validity-map + } + + The following describes each child item of this group. + + * signer (index 0): Information about the entity that signs the + CoRIM. Described in Section 4.2.2.1. + + * signature-validity (index 1): Validity period for the CoRIM. + Described in Section 7.3. + +4.2.2.1. Signer Map + + corim-signer-map = { + &(signer-name: 0) => $entity-name-type-choice + ? &(signer-uri: 1) => uri + * $$corim-signer-map-extension + } + + * signer-name (index 0): Name of the organization that performs the + signer role + + * signer-uri (index 1): A URI identifying the same organization + + * $$corim-signer-map-extension: Extension point for future expansion + of the Signer map. + +4.2.3. Unprotected CoRIM Header Map + + unprotected-corim-header-map = { + * cose-label => cose-value + } + +5. Concise Module Identifier (CoMID) + + A CoMID tag contains information about hardware, firmware, or module + composition. + + Each CoMID has a unique ID that is used to unambiguously identify + CoMID instances when cross referencing CoMID tags, for example in + typed link relations, or in a CoBOM tag. + + A CoMID defines several types of Claims, using "triples" semantics. + + At a high level, a triple is a statement that links a subject to an + object via a predicate. CoMID triples typically encode assertions + made by the CoRIM author about Attesting or Target Environments and + their security features, for example measurements, cryptographic key + material, etc. + + The set of triples is extensible. The following triples are + currently defined: + + * Reference Values triples: containing Reference Values that are + expected to match Evidence for a given Target Environment + (Section 5.1.4.2). + + * Endorsed Values triples: containing "Endorsed Values", i.e., + features about an Environment that do not appear in Evidence. + Specific examples include testing or certification data pertaining + to a module (Section 5.1.4.3). + + * Device Identity triples: containing cryptographic credentials - + for example, an IDevID - uniquely identifying a device + (Section 5.1.4.6). + + * Attestation Key triples: containing cryptographic keys that are + used to verify the integrity protection on the Evidence received + from the Attester (Section 5.1.4.7). + + * Domain dependency triples: describing trust relationships between + domains, i.e., collection of related environments and their + measurements (Section 5.1.4.8). + + * Domain membership triples: describing topological relationships + between (sub-)modules. For example, in a composite Attester + comprising multiple sub-Attesters (sub-modules), this triple can + be used to define the topological relationship between lead- and + sub- Attester environments (Section 5.1.4.9). + + * CoMID-CoSWID linking triples: associating a Target Environment + with existing CoSWID tags (Section 5.1.4.10). + +5.1. Structure + + The CDDL specification for the concise-mid-tag map is as follows and + this rule and its constraints MUST be followed when creating or + validating a CoMID tag: + + concise-mid-tag = { + ? &(language: 0) => text + &(tag-identity: 1) => tag-identity-map + ? &(entities: 2) => [ + comid-entity-map ] + ? &(linked-tags: 3) => [ + linked-tag-map ] + &(triples: 4) => triples-map + * $$concise-mid-tag-extension + } + + The following describes each member of the concise-mid-tag map. + + * lang (index 0): A textual language tag that conforms with IANA + "Language Subtag Registry" [IANA.language-subtag-registry]. The + context of the specified language applies to all sibling and + descendant textual values, unless a descendant object has defined + a different language tag. Thus, a new context is established when + a descendant object redefines a new language tag. All textual + values within a given context MUST be considered expressed in the + specified language. + + * tag-identity (index 1): A tag-identity-map containing unique + identification information for the CoMID. Described in + Section 5.1.1. + + * entities (index 2): Provides information about one or more + organizations responsible for producing the CoMID tag. Described + in Section 5.1.2. + + * linked-tags (index 3): A list of one or more linked-tag-map + providing typed relationships between this and other CoMIDs. + Described in Section 5.1.3). + + * triples (index 4): One or more triples providing information + specific to the described module, e.g.: reference or endorsed + values, cryptographic material, or structural relationship between + the described module and other modules. Described in + Section 5.1.4. + +5.1.1. Tag Identity + + tag-identity-map = { + &(tag-id: 0) => $tag-id-type-choice + ? &(tag-version: 1) => tag-version-type + } + + The following describes each member of the tag-identity-map. + + * tag-id (index 0): A universally unique identifier for the CoMID. + Described in Section 5.1.1.1. + + * tag-version (index 1): Optional versioning information for the + tag-id. Described in Section 5.1.1.2. + +5.1.1.1. Tag ID + + $tag-id-type-choice /= tstr + $tag-id-type-choice /= uuid-type + + A Tag ID is either a 16-byte binary string, or a textual identifier, + uniquely referencing the CoMID. The tag identifier MUST be globally + unique. Failure to ensure global uniqueness can create ambiguity in + tag use since the tag-id serves as the global key for matching, + lookups and linking. If represented as a 16-byte binary string, the + identifier MUST be a valid universally unique identifier as defined + by [RFC4122]. There are no strict guidelines on how the identifier + is structured, but examples include a 16-byte GUID (e.g., class 4 + UUID) [RFC4122], or a URI [STD66]. + +5.1.1.2. Tag Version + + tag-version-type = uint .default 0 + + Tag Version is an integer value that indicates the specific release + revision of the tag. Typically, the initial value of this field is + set to 0 and the value is increased for subsequent tags produced for + the same module release. This value allows a CoMID tag producer to + correct an incorrect tag previously released without indicating a + change to the underlying module the tag represents. For example, the + tag version could be changed to add new metadata, to correct a broken + link, to add a missing reference value, etc. When producing a + revised tag, the new tag-version value MUST be greater than the old + tag-version value. + +5.1.2. Entities + + comid-entity-map = + entity-map<$comid-role-type-choice, $$comid-entity-map-extension> + + The CoMID Entity is an instantiation of entity-map (Section 7.2) + using a $comid-role-type-choice. + + The $$comid-entity-map-extension extension socket is empty in this + specification. + + $comid-role-type-choice /= &(tag-creator: 0) + $comid-role-type-choice /= &(creator: 1) + $comid-role-type-choice /= &(maintainer: 2) + + The roles defined for a CoMID entity are: + + * tag-creator (value 0): creator of the CoMID tag. + + * creator (value 1): original maker of the module described by the + CoMID tag. + + * maintainer (value 2): an entity making changes to the module + described by the CoMID tag. + +5.1.3. Linked Tag + + The linked tag map represents a typed relationship between the + embedding CoMID tag (the source) and another CoMID tag (the target). + + linked-tag-map = { + &(linked-tag-id: 0) => $tag-id-type-choice + &(tag-rel: 1) => $tag-rel-type-choice + } + + The following describes each member of the tag-identity-map. + + * linked-tag-id (index 0): Unique identifier for the target tag. + See Section 5.1.1.1. + + * tag-rel (index 1): the kind of relation linking the source tag to + the target identified by linked-tag-id. + + $tag-rel-type-choice /= &(supplements: 0) + $tag-rel-type-choice /= &(replaces: 1) + + The relations defined in this specification are: + + * supplements (value 0): the source tag provides additional + information about the module described in the target tag. + + * replaces (value 1): the source tag corrects erroneous information + contained in the target tag. The information in the target MUST + be disregarded. + +5.1.4. Triples + + The triples-map contains all the CoMID triples broken down per + category. Not all category need to be present but at least one + category MUST be present and contain at least one entry. + + triples-map = non-empty<{ + ? &(reference-triples: 0) => + [ + reference-triple-record ] + ? &(endorsed-triples: 1) => + [ + endorsed-triple-record ] + ? &(identity-triples: 2) => + [ + identity-triple-record ] + ? &(attest-key-triples: 3) => + [ + attest-key-triple-record ] + ? &(dependency-triples: 4) => + [ + domain-dependency-triple-record ] + ? &(membership-triples: 5) => + [ + domain-membership-triple-record ] + ? &(coswid-triples: 6) => + [ + coswid-triple-record ] + ? &(conditional-endorsement-series-triples: 8) => + [ + conditional-endorsement-series-triple-record ] + ? &(conditional-endorsement-triples: 10) => + [ + conditional-endorsement-triple-record ] + * $$triples-map-extension + }> + + The following describes each member of the triples-map: + + * reference-triples (index 0): Triples containing reference values. + Described in Section 5.1.4.2. + + * endorsed-triples (index 1): Triples containing endorsed values. + Described in Section 5.1.4.3. + + * identity-triples (index 2): Triples containing identity + credentials. Described in Section 5.1.4.6. + + * attest-key-triples (index 3): Triples containing verification keys + associated with attesting environments. Described in + Section 5.1.4.7. + + * dependency-triples (index 4): Triples describing trust + relationships between domains. Described in Section 5.1.4.8. + + * membership-triples (index 5): Triples describing topological + relationships between (sub-)modules. Described in + Section 5.1.4.9. + + * coswid-triples (index 6): Triples associating modules with + existing CoSWID tags. Described in Section 5.1.4.10. + + * conditional-endorsement-series-triples (index 8): Triples + describing a series of conditional Endorsements based on the + acceptance of a stateful environment. Described in + Section 5.1.4.5. + + * conditional-endorsement-triples (index 10): Triples describing a + series of Endorsement that are applicable based on the acceptance + of a series of stateful environment records. Described in + Section 5.1.4.4. + +5.1.4.1. Environments + + An environment-map may be used to represent a whole Attester, an + Attesting Environment, or a Target Environment. The exact semantic + depends on the context (triple) in which the environment is used. + + An environment is named after a class, instance or group identifier + (or a combination thereof). + + An environment MUST be globally unique. The combination of values + within class-map must combine to form a globally unique identifier. + + environment-map = non-empty<{ + ? &(class: 0) => class-map + ? &(instance: 1) => $instance-id-type-choice + ? &(group: 2) => $group-id-type-choice + }> + + The following describes each member of the environment-map: + + * class (index 0): Contains "class" attributes associated with the + module. Described in Section 5.1.4.1.1. + + * instance (index 1): Contains a unique identifier of a module's + instance. Described in Section 5.1.4.1.2. + + * group (index 2): identifier for a group of instances, e.g., if an + anonymization scheme is used. Described in Section 5.1.4.1.3. + +5.1.4.1.1. Environment Class + + The Class name consists of class attributes that distinguish the + class of environment from other classes. The class attributes + include class-id, vendor, model, layer, and index. The CoMID author + determines which attributes are needed. + + class-map = non-empty<{ + ? &(class-id: 0) => $class-id-type-choice + ? &(vendor: 1) => tstr + ? &(model: 2) => tstr + ? &(layer: 3) => uint + ? &(index: 4) => uint + }> + + $class-id-type-choice /= tagged-oid-type + $class-id-type-choice /= tagged-uuid-type + $class-id-type-choice /= tagged-bytes + + The following describes each member of the class-map: + + * class-id (index 0): Identifies the environment via a well-known + identifier. Typically, class-id is an object identifier (OID) + variable-length opaque byte string (Section 7.8) or universally + unique identifier (UUID). Use of this attribute is preferred. + + * vendor (index 1): Identifies the entity responsible for choosing + values for the other class attributes that do not already have + naming authority. + + * model (index 2): Describes a product, generation, and family. If + populated, vendor MUST also be populated. + + * layer (index 3): Is used to capture where in a sequence the + environment exists. For example, the order in which bootstrap + code is executed may have security relevance. + + * index (index 4): Is used when there are clones (i.e., multiple + instances) of the same class of environment. Each clone is given + a different index value to disambiguate it from the other clones. + For example, given a chassis with several network interface + controllers (NIC), each NIC can be given a different index value. + +5.1.4.1.2. Environment Instance + + An instance carries a unique identifier that is reliably bound to a + Target Environment that is an instance of the Attester. + + The types defined for an instance identifier are CBOR tagged + expressions of UEID, UUID, variable-length opaque byte string + (Section 7.8), or cryptographic key identifier. + + $instance-id-type-choice /= tagged-ueid-type + $instance-id-type-choice /= tagged-uuid-type + $instance-id-type-choice /= $crypto-key-type-choice + $instance-id-type-choice /= tagged-bytes + +5.1.4.1.3. Environment Group + + A group carries a unique identifier that is reliably bound to a group + of Attesters, for example when a number of Attester are hidden in the + same anonymity set. + + The types defined for a group identified are UUID and variable-length + opaque byte string (Section 7.8). + + $group-id-type-choice /= tagged-uuid-type + $group-id-type-choice /= tagged-bytes + +5.1.4.1.4. Measurements + + Measurements can be of a variety of things including software, + firmware, configuration files, read-only memory, fuses, IO ring + configuration, partial reconfiguration regions, etc. Measurements + comprise raw values, digests, or status information. + + An environment has one or more measurable elements. Each element can + have a dedicated measurement or multiple elements could be combined + into a single measurement. Measurements can have class, instance or + group scope. This is typically determined by the triple's + environment. + + Class measurements apply generally to all the Attesters in a given + class. + + Instance measurements apply to a specific Attester instance. + Environments identified by a class identifier have measurements that + are common to the class. Environments identified by an instance + identifier have measurements that are specific to that instance. + + The supply chain entity that is responsible for providing 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. + + An environment may have multiple measured elements. Measured + elements are distinguished from each other by measurement keys. + Measurement keys may be used to disambiguate measurements of the same + type originating from different elements. + + measurement-map = { + ? &(mkey: 0) => $measured-element-type-choice + &(mval: 1) => measurement-values-map + ? &(authorized-by: 2) => [ + $crypto-key-type-choice ] + } + + The following describes each member of the measurement-map: + + * mkey (index 0): An optional measurement key. Described in + Section 5.1.4.1.4.1. A measurement-map without an mkey is said to + be anonymous. + + * mval (index 1): The measurements associated with the environment. + Described in Section 5.1.4.1.4.2. + + * authorized-by (index 2): The cryptographic identity of the + individual or organization that is the designated authority for + this measurement. For example, the producer of the measurement. + See Section 5.1.4.1.5. + +5.1.4.1.4.1. Measurement Keys + + Measurement keys are locally scoped extensible identifiers. The + initial types defined are OID, UUID, uint, and tstr. mkey may be + necessary to disambiguate multiple measurements of the same type or + to distinguish multiple measured elements within the same + environment. A single anonymous measurement-map is allowed within + the same environment. Two or more measurement-map entries within the + same environment MUST populate mkey. + + $measured-element-type-choice /= tagged-oid-type + $measured-element-type-choice /= tagged-uuid-type + $measured-element-type-choice /= uint + $measured-element-type-choice /= tstr + +5.1.4.1.4.2. Measurement Values + + A measurement-values-map contains measurements associated with a + certain environment. Depending on the context (triple) in which they + are found, elements in a measurement-values-map can represent class + or instance measurements. Note that some of the elements have + instance scope only. + + Measurement values may support use cases beyond Verifier appraisal. + Typically, a Relying Party determines if additional processing is + desirable and whether the processing is applied by the Verifier or + the Relying Party. + + measurement-values-map = non-empty<{ + ? &(version: 0) => version-map + ? &(svn: 1) => svn-type-choice + ? &(digests: 2) => digests-type + ? &(flags: 3) => flags-map + ? ( + &(raw-value: 4) => $raw-value-type-choice, + ? &(raw-value-mask: 5) => raw-value-mask-type + ) + ? &(mac-addr: 6) => mac-addr-type-choice + ? &(ip-addr: 7) => ip-addr-type-choice + ? &(serial-number: 8) => text + ? &(ueid: 9) => ueid-type + ? &(uuid: 10) => uuid-type + ? &(name: 11) => text + ? &(cryptokeys: 13) => [ + $crypto-key-type-choice ] + ? &(integrity-registers: 14) => integrity-registers + * $$measurement-values-map-extension + }> + + The following describes each member of the measurement-values-map. + + * version (index 0): Typically changes whenever the measured + environment is updated. Described in Section 5.1.4.1.4.3. + + * svn (index 1): The security version number typically changes only + when a security relevant change is made to the measured + environment. Described in Section 5.1.4.1.4.4. + + * digests (index 2): Contains the digest(s) of the measured + environment together with the respective hash algorithm used in + the process. It uses the digests-type. Described in Section 7.7. + + * flags (index 3): Describes security relevant operational modes. + For example, whether the environment is in a debug mode, recovery + mode, not fully configured, not secure, not replay protected or + not integrity protected. The flags field indicates which + operational modes are currently associated with measured + environment. Described in Section 5.1.4.1.4.5. + + * raw-value (index 4): Contains the actual (not hashed) value of the + element. An optional raw-value-mask (index 5) indicates which + bits in the raw-value field are relevant for verification. A mask + of all ones ("1") means all bits in the raw-value field are + relevant. Multiple values could be combined to create a single + raw-value attribute. The vendor determines how to pack multiple + values into a single raw-value structure. The same packing format + is used when collecting Evidence so that Reference Values and + collected values are bit-wise comparable. The vendor determines + the encoding of raw-value and the corresponding raw-value-mask. + + * mac-addr (index 6): A EUI-48 or EUI-64 MAC address associated with + the measured environment. Described in Section 5.1.4.1.4.7. + + * ip-addr (index 7): An IPv4 or IPv6 address associated with the + measured environment. Described in Section 5.1.4.1.4.7. + + * serial-number (index 8): A text string representing the product + serial number. + + * ueid (index 9): UEID associated with the measured environment. + Described in Section 7.5. + + * uuid (index 10): UUID associated with the measured environment. + Described in Section 7.4. + + * name (index 11): a name associated with the measured environment. + + * cryptokeys (index 13): identifies cryptographic keys that are + protected by the Target Environment See Section 5.1.4.1.5 for the + supported formats. An Attesting Environment determines that keys + are protected as part of Claims collection. Appraisal verifies + that, for each value in cryptokeys, there is a matching Reference + Value entry. Matching is described in Section 8.6.6.1.5. + + * integrity-registers (index 14): A group of one or more named + measurements associated with the environment. Described in + Section 5.1.4.1.6. + +5.1.4.1.4.3. Version + + A version-map contains details about the versioning of a measured + environment. + + version-map = { + &(version: 0) => text + ? &(version-scheme: 1) => $version-scheme + } + + The following describes each member of the version-map: + + * version (index 0): the version string + + * version-scheme (index 1): an optional indicator of the versioning + convention used in the version attribute. Defined in Section 4.1 + of [RFC9393]. The CDDL is copied below for convenience. + + $version-scheme /= &(multipartnumeric: 1) + $version-scheme /= &(multipartnumeric-suffix: 2) + $version-scheme /= &(alphanumeric: 3) + $version-scheme /= &(decimal: 4) + $version-scheme /= &(semver: 16384) + $version-scheme /= int / text + +5.1.4.1.4.4. Security Version Number + + The following details the security version number (svn) and the + minimum security version number (min-svn) statements. A security + version number is used to track changes to an object (e.g., a secure + enclave, a boot loader executable, a configuration file, etc.) that + are security relevant. Rollback of a security relevant change is + considered to be an attack vector; as such, security version numbers + cannot be decremented. If a security relevant flaw is discovered in + the Target Environment and is subsequently fixed, the svn value is + typically incremented. + + There may be several revisions to a Target Environment that are in + use at the same time. If there are multiple revisions with different + svn values, the revision with a lower svn value may or may not be in + a security critical condition. The Endorser may provide a minimum + security version number using min-svn to specify the lowest svn value + that is acceptable. svn values that are equal to or greater than min- + svn do not signal a security critical condition. svn values that are + below min-svn are in a security critical condition that is unsafe for + normal use. + + The svn-type-choice measurement consists of a tagged-svn or tagged- + min-svn value. The tagged-svn and tagged-min-svn tags are CBOR tags + with the values #6.552 and #6.553 respectively. + + svn-type = uint + svn = svn-type + min-svn = svn-type + tagged-svn = #6.552(svn) + tagged-min-svn = #6.553(min-svn) + svn-type-choice = svn / tagged-svn / tagged-min-svn + +5.1.4.1.4.5. Flags + + The flags-map measurement describes a number of boolean operational + modes. If a flags-map value is not specified, then the operational + mode is unknown. + + flags-map = { + ? &(is-configured: 0) => bool + ? &(is-secure: 1) => bool + ? &(is-recovery: 2) => bool + ? &(is-debug: 3) => bool + ? &(is-replay-protected: 4) => bool + ? &(is-integrity-protected: 5) => bool + ? &(is-runtime-meas: 6) => bool + ? &(is-immutable: 7) => bool + ? &(is-tcb: 8) => bool + ? &(is-confidentiality-protected: 9) => bool + * $$flags-map-extension + } + + The following describes each member of the flags-map: + + * is-configured (index 0): If the flag is true, the measured + environment is fully configured for normal operation. + + * is-secure (index 1): If the flag is true, the measured + environment's configurable security settings are fully enabled. + + * is-recovery (index 2): If the flag is true, the measured + environment is in recovery mode. + + * is-debug (index 3): If the flag is true, the measured environment + is in a debug enabled mode. + + * is-replay-protected (index 4): If the flag is true, the measured + environment is protected from replay by a previous image that + differs from the current image. + + * is-integrity-protected (index 5): If the flag is true, the + measured environment is protected from unauthorized update. + + * is-runtime-meas (index 6): If the flag is true, the measured + environment is measured after being loaded into memory. + + * is-immutable (index 7): If the flag is true, the measured + environment is immutable. + + * is-tcb (index 8): If the flag is true, the measured environment is + a trusted computing base. + + * is-confidentiality-protected (index 9): If the flag is true, the + measured environment is confidentiality protected. For example, + if the measured environment consists of memory, the sensitive + values in memory are encrypted. + +5.1.4.1.4.6. Raw Values Types + + Raw value measurements are typically vendor defined values that are + checked by Verifiers for consistency only, since the security + relevance is opaque to Verifiers. + + There are two parts to a raw-value-group, a measurement and an + optional mask. The default raw value measurement is of type tagged- + bytes (Section 7.8). Additional raw value types can be defined, but + must be CBOR tagged so that parsers can distinguish between the + various semantics of type values. + + The mask is applied by the Verifier as part of appraisal. Only the + raw value bits with corresponding TRUE mask bits are compared during + appraisal. + + When a new raw value type is defined, the convention for applying the + mask is also defined. Typically, a CoRIM profile is used to define + new raw values and mask semantics. + + $raw-value-type-choice /= tagged-bytes + + raw-value-mask-type = bytes + +5.1.4.1.4.7. Address Types + + The types or associating addressing information to a measured + environment are: + + ip-addr-type-choice = ip4-addr-type / ip6-addr-type + ip4-addr-type = bytes .size 4 + ip6-addr-type = bytes .size 16 + + mac-addr-type-choice = eui48-addr-type / eui64-addr-type + eui48-addr-type = bytes .size 6 + eui64-addr-type = bytes .size 8 + +5.1.4.1.5. Crypto Keys + + A cryptographic key can be one of the following formats: + + * tagged-pkix-base64-key-type: PEM encoded SubjectPublicKeyInfo. + Defined in Section 13 of [RFC7468]. + + * tagged-pkix-base64-cert-type: PEM encoded X.509 public key + certificate. Defined in Section 5 of [RFC7468]. + + * tagged-pkix-base64-cert-path-type: X.509 certificate chain created + by the concatenation of as many PEM encoded X.509 certificates as + needed. The certificates MUST be concatenated in order so that + each directly certifies the one preceding. + + * tagged-cose-key-type: CBOR encoded COSE_Key or COSE_KeySet. + Defined in Section 7 of [STD96]. + + * tagged-pkix-asn1der-cert-type: a bstr of ASN.1 DER encoded X.509 + public key certificate. Defined in Section 4 of [RFC5280]. + + A cryptographic key digest can be one of the following formats: + + * tagged-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. + + * tagged-bytes: a key identifier with no prescribed construction + method. + + $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 + $crypto-key-type-choice /= tagged-pkix-asn1der-cert-type + $crypto-key-type-choice /= tagged-bytes + + tagged-pkix-base64-key-type = #6.554(tstr) + tagged-pkix-base64-cert-type = #6.555(tstr) + tagged-pkix-base64-cert-path-type = #6.556(tstr) + tagged-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) + tagged-pkix-asn1der-cert-type = #6.562(bstr) + +5.1.4.1.6. Integrity Registers + + An Integrity Registers map groups together one or more measured + "objects". Each measured object has a unique identifier and one or + more associated digests. Identifiers are either unsigned integers or + text strings and their type matters, e.g., unsigned integer 5 is + distinct from the text string "5". The digests use digests-type + semantics (Section 7.7). + + integrity-register-id-type-choice = uint / text + + integrity-registers = { + + integrity-register-id-type-choice => digests-type + } + + All the measured objects in an Integrity Registers map are explicitly + named and the order in which they appear in the map is irrelevant. + Any digests associated with a measured object represent an acceptable + state for the object. Therefore, if multiple digests are provided, + the acceptable state is their cross-product. For example, given the + following Integrity Registers: + + { + 0: [ [ 0, h'00' ] ], + 1: [ [ 0, h'11' ], [ 1, h'12' ] ] + } + + then both + + { + 0: [ 0, h'00' ], + 1: [ 0, h'11' ] + } + + and + + { + 0: [ 0, h'00' ], + 1: [ 1, h'12' ] + } + + are acceptable states. + + Integrity Registers can be used to model the PCRs in a TPM or vTPM, + in which case the identifier is the register index, or other kinds of + vendor-specific measured objects. + +5.1.4.1.7. Domain Types + + A domain is a context for bundling a collection of related + environments and their measurements. + + The following CDDL describes domain type choices. + + $domain-type-choice /= uint + $domain-type-choice /= text + $domain-type-choice /= tagged-uuid-type + $domain-type-choice /= tagged-oid-type + + The uint and text types MUST NOT be interpreted in a global scope. + +5.1.4.2. Reference Values Triple + + + // Content missing. Tracked at: https://github.com/ietf-rats-wg/ + draft-ietf-rats-corim/issues/310 + + The Reference Values Triple has the following structure: + + reference-triple-record = [ + ref-env: environment-map + ref-claims: [ + measurement-map ] + ] + + The reference-triple-record has the following parameters: + + * ref-env: Search criterion that locates an Evidence environment + that matches the reference environment. + + * ref-claims: Search criteria that locates the Evidence measurements + that match the reference Claims. + + To process reference-triple-record both the ref-env and ref-claims + criteria are compared with Evidence entries. If the search criteria + are satisfied, the matching entry is re-asserted, except with the + Reference Value Provider's authority. By re-asserting Evidence using + the RVP's authority, the Verifier can avoid mixing Reference Values + (reference state) with Evidence (actual state). See + [I-D.ietf-rats-endorsements]. Re-asserted Evidence using RVP + authority is said to be "corroborated". + +5.1.4.3. Endorsed Values Triple + + + // Content missing. Tracked at: https://github.com/ietf-rats-wg/ + draft-ietf-rats-corim/issues/310 + + The Endorsed Values Triple has the following structure: + + endorsed-triple-record = [ + condition: environment-map + endorsement: [ + measurement-map ] + ] + + The endorsed-triple-record has the following parameters: + + * condition: Search criterion that locates an Evidence, corroborated + Evidence, or Endorsements environment. + + * endorsement: Additional Endorsement Claims. + + To process a endorsed-triple-record the condition is compared with + existing Evidence, corroborated Evidence, and Endorsements. If the + search criterion is satisfied, the endorsement Claims are combined + with the condition environment-map to form a new (actual state) + entry. The new entry is added to the existing set of entries using + the Endorser's authority. + +5.1.4.4. Conditional Endorsement Triple + + + // Content missing. Tracked at: https://github.com/ietf-rats-wg/ + draft-ietf-rats-corim/issues/310 + + The Conditional Endorsement Triple has the following structure: + + conditional-endorsement-triple-record = [ + conditions: [ + stateful-environment-record ] + endorsements: [ + endorsed-triple-record ] + ] + + stateful-environment-record = [ + environment: environment-map, + claims-list: [ + measurement-map ] + ] + + The conditional-endorsement-triple-record has the following + parameters: + + * conditions: Search criteria that locates Evidence, corroborated + Evidence, or Endorsements. + + * endorsements: Additional Endorsements. + + To process a conditional-endorsement-triple-record the conditions are + compared with existing Evidence, corroborated Evidence, and + Endorsements. If the search criteria are satisfied, the endorsements + entries are asserted with the Endorser's authority as new + Endorsements. + +5.1.4.5. Conditional Endorsement Series Triple + + + // Content missing. Tracked at: https://github.com/ietf-rats-wg/ + draft-ietf-rats-corim/issues/310 + + The Conditional Endorsement Series Triple has the following + structure: + + conditional-endorsement-series-triple-record = [ + condition: stateful-environment-record + series: [ + conditional-series-record ] + ] + + conditional-series-record = [ + selection: [ + measurement-map] + addition: [ + measurement-map ] + ] + + The conditional-endorsement-series-triple-record has the following + parameters: + + * condition: Search criteria that locates Evidence, corroborated + Evidence, or Endorsements. + + * series: A set of selection-addition tuples. + + The conditional-series-record has the following parameters: + + * selection: Search criteria that locates Evidence, corroborated + Evidence, or Endorsements from the condition result. + + * addition: Additional Endorsements if the selection criteria are + satisfied. + + To process a conditional-endorsement-series-record the conditions are + compared with existing Evidence, corroborated Evidence, and + Endorsements. If the search criteria are satisfied, the series + tuples are processed. + + The series array contains a list of conditional-series-record + entries. + + For each series entry, if the selection criteria matches an entry + found in the condition result, the series addition is combined with + the environment-map from the condition result to form a new + Endorsement entry. The new entry is added to the existing set of + Endorsements. + + The first series entry that successfully matches the selection + criteria terminates series processing. + +5.1.4.6. Device Identity Triple + + A Device Identity triple record relates one or more cryptographic + keys to a device identity. The cryptographic keys are bound to or + associated with a Target Environment that is within the device. The + device identifier may be part of the Target Environment's + environment-map or may be part of some other device identity + credential, such as a certificate. The cryptographic keys are + expected to be used to authenticate the device. + + Device Identity triples instruct a Verifier to perform key validation + checks, such as revocation, certificate path construction & + verification, or proof of possession. The Verifier SHOULD verify + keys contained in Device Identity triples. + + A Device Identity triple endorses that the keys were securely + provisioned to the named Target Environment. Additional details + about how a key was provisioned or is protected may be asserted using + Endorsements such as endorsed-triples. + + Depending on key formatting, as defined by $crypto-key-type-choice, + the Verifier may take different steps to locate and verify the key. + + If a key has usage restrictions that limit its use to device identity + challenges, Verifiers SHOULD check for key use that violates usage + restrictions. + + Verification of a key, including its use restrictions, MAY produce + Claims that are added to the ACS. Alternatively, Verifiers MAY + report key verification results as part of an error reporting + function. + + identity-triple-record = [ + environment-map + [ + $crypto-key-type-choice ] + ] + +5.1.4.7. Attest Key Triple + + An Attest Key triple record relates one or more cryptographic keys to + an Attesting Environment. The cryptographic keys are wielded by an + Attesting Environment that collects measurements from a Target + Environment. The cryptographic keys sign Evidence. + + Attest Key triples instruct a Verifier to perform key validation + checks, such as revocation, certificate path construction & + verification, or proof of possession. The Verifier SHOULD verify + keys contained in Attest Key triples. + + Attest Key triples endorse that the keys were securely provisioned to + the named (identified via an environment-map) Attesting Environment. + Additional details about how a key was provisioned or is protected + may be asserted using Endorsements such as endorsed-triples. + + Depending on key formatting, as defined by $crypto-key-type-choice, + the Verifier may take different steps to locate and verify the key. + If a key has usage restrictions that limits its use to Evidence + signing, Verifiers SHOULD check for key use that violates usage + restrictions. + + Verification of a key, including its use restrictions, MAY produce + Claims that are added to the ACS. Alternatively, Verifiers MAY + report key verification results as part of an error reporting + function. + + attest-key-triple-record = [ + environment-map + [ + $crypto-key-type-choice ] + ] + +5.1.4.8. Domain Dependency Triple + + A Domain Dependency triple defines trust dependencies between + measurement sources. The subject identifies a domain + (Section 5.1.4.1.7) that has a predicate relationship to the object + containing one or more dependent domains. Dependency means the + subject domain’s trustworthiness properties rely on the object + domain(s) trustworthiness having been established before the + trustworthiness properties of the subject domain exists. + + domain-dependency-triple-record = [ + $domain-type-choice + [ + $domain-type-choice ] + ] + +5.1.4.9. Domain Membership Triple + + A Domain Membership triple assigns domain membership to environments. + The subject identifies a domain (Section 5.1.4.1.7) that has a + predicate relationship to the object containing one or more + environments. Endorsed environments (Section 5.1.4.3) membership is + conditional upon successful matching of Reference Values + (Section 5.1.4.2) to Evidence. + + domain-membership-triple-record = [ + $domain-type-choice + [ + environment-map ] + ] + +5.1.4.10. CoMID-CoSWID Linking Triple + + A CoSWID triple relates reference measurements contained in one or + more CoSWIDs to a Target Environment. The subject identifies a + Target Environment, the object one or more unique tag identifiers of + existing CoSWIDs, and the predicate asserts that these contain the + expected (i.e., reference) measurements for the Target Environment. + + coswid-triple-record = [ + environment-map + [ + concise-swid-tag-id ] + ] + + concise-swid-tag-id = text / bstr .size 16 + +5.2. Extensibility + + The base CoRIM document definition is described using CDDL [RFC8610] + that can be extended only at specific allowed points known as + "extension points". + + The following types of extensions are supported in CoRIM. + +5.2.1. Map Extensions + + Map extensions provide extensibility support to CoRIM map structures. + CDDL map extensibility enables a CoRIM profile to extend the base + CoRIM CDDL definition. CDDL map extension points have the form + ($$NAME-extension) where "NAME" is the name of the map and '$$' + signifies map extensibility. Typically, map extension requires a + convention for code point naming that avoids code-point reuse. Well- + known code points may be in a registry, such as CoSWID [IANA.coswid]. + Non-negative integers are reserved for IANA to assign meaning + globally. + +5.2.2. Data Type Extensions + + Data type extensibility has the form ($NAME-type-choice) where "NAME" + is the type name and '$' signifies type extensibility. + + New data type extensions SHOULD be documented to facilitate + interoperability. CoRIM profiles are best used to document vendor or + industry defined extensions. + +6. 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. + +6.1. 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: + + concise-bom-tag = { + &(tag-identity: 0) => 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 + Section 5.1.1. + + * 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 Section 7.3. + + * $$concise-bom-tag-extension: This CDDL socket is used to add new + information structures to the concise-bom-tag. See Section 11.5. + The $$concise-bom-tag-extension extension socket is empty in this + specification. + +7. Common Types + + The following CDDL types may be shared by CoRIM, CoMID, and CoBOM. + +7.1. Non-Empty + + The non-empty generic type is used to express that a map with only + optional members MUST at least include one of the members. + + non-empty = (M) .and ({ + any => any }) + +7.2. Entity + + The entity-map is a generic type describing an organization + responsible for the contents of a manifest. It is instantiated by + supplying two parameters: + + * A role-type-choice, i.e., a selection of roles that entities of + the instantiated type can claim + + * An extension-socket, i.e., a CDDL socket that can be used to + extend the attributes associated with entities of the instantiated + type + + entity-map = { + &(entity-name: 0) => $entity-name-type-choice + ? &(reg-id: 1) => uri + &(role: 2) => [ + role-type-choice ] + * extension-socket + } + + $entity-name-type-choice /= text + + The following describes each member of the entity-map. + + * entity-name (index 0): The name of entity which is responsible for + the action(s) as defined by the role. $entity-name-type-choice can + only be text. Other specifications can extend the $entity-name- + type-choice. See Section 11.4. + + * reg-id (index 1): A URI associated with the organization that owns + the entity name. + + * role (index 2): A type choice defining the roles that the entity + is claiming. The role is supplied as a parameter at the time the + entity-map generic is instantiated. + + * extension-socket: A CDDL socket used to add new information + structures to the entity-map. + + Examples of how the entity-map generic is instantiated can be found + in (Section 4.1.5) and (Section 5.1.2). + +7.3. Validity + + A validity-map represents the time interval during which the signer + warrants that it will maintain information about the status of the + signed object (e.g., a manifest). + + In a validity-map, both ends of the interval are encoded as epoch- + based date/time as per Section 3.4.2 of [STD94]. + + validity-map = { + ? &(not-before: 0) => time + &(not-after: 1) => time + } + + * not-before (index 0): the date on which the signed manifest + validity period begins + + * not-after (index 1): the date on which the signed manifest + validity period ends + +7.4. UUID + + Used to tag a byte string as a binary UUID. Defined in + Section 4.1.2. of [RFC4122]. + + uuid-type = bytes .size 16 + tagged-uuid-type = #6.37(uuid-type) + +7.5. UEID + + Used to tag a byte string as Universal Entity ID Claim (UUID). + Defined in Section 4.2.1 of [I-D.ietf-rats-eat]. + + ueid-type = bytes .size 33 + tagged-ueid-type = #6.550(ueid-type) + +7.6. OID + + Used to tag a byte string as the BER encoding [X.690] of an absolute + object identifier [RFC9090]. + + oid-type = bytes + tagged-oid-type = #6.111(oid-type) + +7.7. Digest + + A digest represents the value of a hashing operation together with + the hash algorithm used. The type of the digest algorithm identifier + can be either int or text and is interpreted according to the + [IANA.named-information] registry. Specifically, int values are + matched against "ID" entries, text values are matched against "Hash + Name String" entries. Whenever possible, using the int encoding is + RECOMMENDED. + + digest = [ + alg: (int / text), + val: bytes + ] + + digests-type = [ + digest ] + + A measurement can be obtained using different hash algorithms. A + digests-type can be used to collect multiple digest values obtained + by applying different hash algorithms on the same input. Each entry + in the digests-type MUST have a unique alg value. + +7.8. Tagged Bytes Type + + An opaque, variable-length byte string. It can be used in different + contexts: as an instance, class or group identifier in an + environment-map; as a raw value measurement in a measurement-values- + map. Its semantics are defined by the context in which it is found, + and by the overarching CoRIM profile. When used as an identifier the + responsible allocator entity SHOULD ensure uniqueness within the + context that it is used. + + tagged-bytes = #6.560(bytes) + +8. Appraisal of CoRIM-based Inputs + + Inputs to a Verifier are mapped from their external representation to + an internal representation. CoRIM defines CBOR structures and + content media types for Conceptual Messages that include Endorsements + and Reference Values. CoRIM data structures may also be used by + Evidence and Attestation Results that wish to describe overlapping + structure. CoRIM-based data structures define an external + representation of Conceptual Messages that are mapped to an internal + representation. Appraisal processing describes both mapping + transformations and Verifier reconciliation (Section 2). Non-CoRIM- + based data structures require mapping transformation, but these are + out of scope for this document. + + If a CoRIM profile is specified, there are a few well-defined points + in the procedure where Verifier behaviour depends on the profile. + The CoRIM profile MUST provide a description of the expected Verifier + behavior for each of those well-defined points. + + Verifier implementations MUST exhibit the same externally visible + behavior as described in this specification. They are not required + to use the same internal representation or evaluation order described + by this specification. + +8.1. Appraisal Procedure + + The appraisal procedure is divided into several logical phases for + clarity. + + * *Phase 1*: Input Validation and Transformation + + During Phase 1, Conceptual Message inputs are cryptographically + validated, such as checking digital signatures. Inputs are + transformed from their external representations to an internal + representation. Internal representations are staged for appraisal + processing, such as populating an input queue. + + * *Phase 2*: Evidence Augmentation + + During Phase 2, Evidence inputs are added to a list that describes + the Attester's actual state. These inputs are added with the + Attester's authority. + + * *Phase 3*: Reference Values Corroboration and Augmentation + + During Phase 3, Reference Values inputs are compared with Evidence + inputs. Reference Values inputs describe possible states of + Attesters. If the actual state of the Attester is described by the + possible Attester states, then the overlapping (corroborated) actual + states are added to the Attester's actual state. These inputs are + added with the Reference Value Provider's authority. + + * *Phase 4*: Endorsed Values Augmentation + + During Phase 4, Endorsed Values inputs containing conditions that + describe expected Attester state are processed. If the comparison is + satisfied, then additional Claims about the Attester are added to the + ACS. These inputs are added with the Endorser's authority. + + * *Phase 5*: Verifier Augmentation + + During Phase 5, the Verifier may perform consistency, integrity, or + additional validity checks. + + These checks may result in additional Claims about the Attester that + are added to the ACS. These Claims are added with the Verifier's + authority. + + * *Phase 6*: Policy Augmentation + + During Phase 6, appraisal policies are processed that describe + Attester states that are desirable or undesirable. If these + conditions exist, the policy may add additional Claims about the + Attester, to the ACS. These Claims are added with the policy + author's authority. + + * *Phase 7*: Attestation Results Production and Transformation + + During Phase 7, the outcome of Appraisal and the set of Attester + Claims that are interesting to a Relying Party are copied from the + Attester state to an output staging area. The Claims in the output + staging area and other Verifier related metadata are transformed into + an external representation suitable for consumption by a Relying + Party. + +8.2. Verifier Abstraction + + This document assumes that Verifier implementations may differ. To + facilitate the description of normative Verifier behavior, this + document uses an abstract representation of Verifier internals. + + The following terms are used: + + Claim: + A piece of information, in the form of a key-value pair. + + Environment-Claim Tuple (ECT): + A structure containing a set of values that describe a Target + Environment plus a set of measurement / Claim values that describe + properties of the Target Environment. The ECT also contains + authority which identifies the entity that authored the ECT. + + reference state: + Claims that describe various alternative states of a Target + Environment. Reference Values Claims typically describe various + possible states due to versioning, manufactruing practices, or + supplier configuration options. See also Section 2 of + [I-D.ietf-rats-endorsements]. + + actual state: + Claims that describe a Target Environment instance at a given + point in time. Endorsed Values and Evidence typically are Claims + about actual state. An Attester may be composed of multiple + components, where each component may represent a scope of + appraisal. See also (Section 2 of [I-D.ietf-rats-endorsements]). + + Authority: + The entity asserting that a claim is true. Typically, a Claim is + asserted using a cryptographic key to digitally sign the Claim. A + cryptographic key can be a proxy for a human or organizational + entity. + + Appraisal Claims Set (ACS): + A structure that holds ECTs that have been appraised. The ACS + contains Attester state that has been authorized by Verifier + processing and Appraisal Policy. + + Appraisal Policy: + A description of the conditions that, if met, allow acceptance of + Claims. Typically, the entity asserting a Claim should have + knowledge, expertise, or context that gives credibility to the + assertion. Appraisal Policy resolves which entities are credible + and under what conditions. See also "Appraisal Policy for + Evidence" in [RFC9334]. + + Attestation Results Set (ARS): + A structure that holds results of Appraisal and ECTs that are to + be conveyed to a Relying Party. + +8.2.1. Internal Representation of Conceptual Messages + + Conceptual Messages are Verifier input and output values such as + Evidence, Reference Values, Endorsed Values, Appraisal Policy, and + Attestation Results. + + The internal representation of Conceptual Messages, as well as the + ACS (Section 8.2.2) and ARS (Section 8.2.3), are constructed from a + common building block structure called Environment-Claims Tuple + (ECT). + + ECTs have five attributes: + + 1. Environment : Identifies the Target Environment. Environments + are identified using instance, class, or group identifiers. + Environments may be composed of elements, each having an element + identifier. + + 2. Elements : Identifies the set of elements contained within a + Target Environment and their trustworthiness Claims. + + 3. Authority : Identifies the entity that issued the tuple. A + certain type of key material by which the authority (and + corresponding provenance) of the tuple can be determined, such as + the public key of an asymmetric key pair that is associated with + an authority's PKIX certificate. + + 4. Conceptual Message Type : Identifies the type of Conceptual + Message that originated the tuple. + + 5. Profile : The profile that defines this tuple. If no profile is + used, this attribute is omitted. + + The following CDDL describes the ECT structure in more detail. + + ECT = { + ? environment: environment-map + ? element-list: [ + element-map ] + ? authority: [ + $crypto-key-type-choice ] + cmtype: cm-type + ? profile: $profile-type-choice + } + + element-map = { + ? element-id: $measured-element-type-choice + element-claims: measurement-values-map + } + + cm-type = &( + reference-values: 0 + endorsements: 1 + evidence: 2 + attestation-results: 3 + verifier: 4 + policy: 5 + ) + + The Conceptual Message type determines which attributes are + mandatory. + +8.2.1.1. Internal Representation of Evidence + + An internal representation of attestation Evidence uses the ae + relation. + + ae = [ + addition: [ + ECT ] + ] + + The addition is a list of ECTs with Evidence to be appraised. + + A Verifier may maintain multiple simultaneous sessions to different + Attesters. Each Attester has a different ACS. The Verifier ensures + the Evidence inputs are associated with the correct ACS. The + addition is added to the ACS for a specific Attester. + + Table 3 contains the requirements for the ECT fields of the Evidence + tuple: + + +==========+==============+=============+ + | ECT type | ECT Field | Requirement | + +==========+==============+=============+ + | addition | environment | Mandatory | + +----------+--------------+-------------+ + | | element-list | Mandatory | + +----------+--------------+-------------+ + | | authority | Mandatory | + +----------+--------------+-------------+ + | | cmtype | Mandatory | + +----------+--------------+-------------+ + | | profile | Optional | + +----------+--------------+-------------+ + + Table 3: Evidence tuple requirements + +8.2.1.2. Internal Representation of Reference Values + + An internal representation of Reference Values uses the rv relation, + which is a list of ECTs that contains possible states and a list of + ECTs that contain actual states asserted with RVP authority. + + rv = [ + { + condition: ECT + addition: ECT + } ] + + The rv relation is a list of condition-addition pairings where each + pairing is evaluated together. If the condition containing reference + ECTs overlaps Evidence ECTs then the Evidence ECTs are re-asserted, + but with RVP authority as contained in the addition. + + The reference ECTs define the matching conditions that are applied to + Evidence ECTs. If the matching condition is satisfied, then the re- + asserted ECTs are added to the ACS. + + Table 4 contains the requirements for the ECT fields of the Reference + Values tuple: + + +===========+==============+=============+ + | ECT type | ECT Field | Requirement | + +===========+==============+=============+ + | condition | environment | Mandatory | + +-----------+--------------+-------------+ + | | element-list | Mandatory | + +-----------+--------------+-------------+ + | | authority | Optional | + +-----------+--------------+-------------+ + | | cmtype | n/a | + +-----------+--------------+-------------+ + | | profile | n/a | + +-----------+--------------+-------------+ + | addition | environment | Mandatory | + +-----------+--------------+-------------+ + | | element-list | Mandatory | + +-----------+--------------+-------------+ + | | authority | Mandatory | + +-----------+--------------+-------------+ + | | cmtype | Mandatory | + +-----------+--------------+-------------+ + | | profile | Optional | + +-----------+--------------+-------------+ + + Table 4: Reference Values tuple + requirements + +8.2.1.3. Internal Representation of Endorsed Values + + An internal representation of Endorsed Values uses the ev and evs + relations, which are lists of ECTs that describe matching conditions + and the additions that are added if the conditions are satisfied. + + ev = [ + condition: [ + ECT ] + addition: [ + ECT ] + ] + + evs = [ + condition: [ + ECT ] + series: [ + { + selection: [ + ECT ] + addition: [ + ECT ] + } ] + ] + + The ev relation compares the condition ECTs to the ACS and if all of + the ECTs are found in the ACS then the addition ECTs are added to the + ACS. + + The evs relation compares the condition ECTs to the ACS and if all of + the ECTs are found in the ACS then each entry in the series list is + evaluated. The selection ECTs are compared with the ACS and if the + selection criteria is satisfied, then the addition ECTs are added to + the ACS and evaluation of the series ends. If the selection criteria + is not satisfied, then evaluation procedes to the next series list + entry. + + Table 5 contains the requirements for the ECT fields of the Endorsed + Values and Endorsed Values Series tuples: + + +===========+==============+=============+ + | ECT type | ECT Field | Requirement | + +===========+==============+=============+ + | condition | environment | Mandatory | + +-----------+--------------+-------------+ + | | element-list | Mandatory | + +-----------+--------------+-------------+ + | | authority | Optional | + +-----------+--------------+-------------+ + | | cmtype | n/a | + +-----------+--------------+-------------+ + | | profile | n/a | + +-----------+--------------+-------------+ + | selection | environment | Mandatory | + +-----------+--------------+-------------+ + | | element-list | Mandatory | + +-----------+--------------+-------------+ + | | authority | Optional | + +-----------+--------------+-------------+ + | | cmtype | n/a | + +-----------+--------------+-------------+ + | | profile | n/a | + +-----------+--------------+-------------+ + | addition | environment | Mandatory | + +-----------+--------------+-------------+ + | | element-list | Mandatory | + +-----------+--------------+-------------+ + | | authority | Mandatory | + +-----------+--------------+-------------+ + | | cmtype | Mandatory | + +-----------+--------------+-------------+ + | | profile | Optional | + +-----------+--------------+-------------+ + + Table 5: Endorsed Values and Endorsed + Values Series tuples requirements + +8.2.1.4. Internal Representation of Policy Statements + + The policy relation compares the condition ECTs to the ACS. + + policy = [ + condition: [ + ECT ] + addition: [ + ECT ] + ] + + If all of the ECTs are found in the ACS then the addition ECTs are + added to the ACS with the policy author's authority. + + Table 6 contains the requirements for the ECT fields of the Policy + tuple: + + +===========+==============+=============+ + | ECT type | ECT Field | Requirement | + +===========+==============+=============+ + | condition | environment | Optional | + +-----------+--------------+-------------+ + | | element-list | Optional | + +-----------+--------------+-------------+ + | | authority | Optional | + +-----------+--------------+-------------+ + | | cmtype | n/a | + +-----------+--------------+-------------+ + | | profile | n/a | + +-----------+--------------+-------------+ + | addition | environment | Mandatory | + +-----------+--------------+-------------+ + | | element-list | Mandatory | + +-----------+--------------+-------------+ + | | authority | Mandatory | + +-----------+--------------+-------------+ + | | cmtype | Mandatory | + +-----------+--------------+-------------+ + | | profile | Optional | + +-----------+--------------+-------------+ + + Table 6: Policy tuple requirements + +8.2.1.5. Internal Representation of Attestation Results + + The ar relation compares the acs-condition to the ACS. + + ar = [ + acs-condition: [ + ECT ] + ars-addition: [ + ECT ] + ] + + If the condition is satisfied, the ars-additions are copied from the + ACS to the ARS. If any of the ars-additions are not found in the ACS + then these ACS entries are not copied to the ARS. + + Table 7 contains the requirements for the ECT fields of the + Attestation Results tuple: + + +===============+==============+=============+ + | ECT type | ECT Field | Requirement | + +===============+==============+=============+ + | acs-condition | environment | Optional | + +---------------+--------------+-------------+ + | | element-list | Optional | + +---------------+--------------+-------------+ + | | authority | Optional | + +---------------+--------------+-------------+ + | | cmtype | n/a | + +---------------+--------------+-------------+ + | | profile | n/a | + +---------------+--------------+-------------+ + | ars-addition | environment | Mandatory | + +---------------+--------------+-------------+ + | | element-list | Mandatory | + +---------------+--------------+-------------+ + | | authority | Mandatory | + +---------------+--------------+-------------+ + | | cmtype | Mandatory | + +---------------+--------------+-------------+ + | | profile | Optional | + +---------------+--------------+-------------+ + + Table 7: Attestation Results tuple + requirements + +8.2.2. Internal Representation of ACS + + An ACS is a list of ECTs that describe an Attester's actual state. + + ACS = [ + ECT ] + +8.2.3. Internal Representation of Attestation Results Set (ARS) + + An ARS is a list of ECTs that describe ACS entries that are selected + for use as Attestation Results. + + ARS = [ + ECT ] + +8.3. Input Validation and Transformation (Phase 1) + + During the initialization phase, the CoRIM Appraisal Context is + loaded with various conceptual message inputs such as CoMID tags + (Section 5), CoSWID tags [RFC9393], CoBOM tags [I-D.ietf-rats-cobom], + and cryptographic validation key material (including raw public keys, + root certificates, intermediate CA certificate chains), and Concise + Trust Anchor Stores (CoTS) [I-D.ietf-rats-concise-ta-stores]. These + objects will be utilized in the Evidence Appraisal phase that + follows. The primary goal of this phase is to ensure that all + necessary information is available for subsequent processing. + + After context initialization, additional inputs are held back until + appraisal processing has completed. + +8.3.1. Input Validation + +8.3.1.1. CoRIM Selection + + All available CoRIMs are collected. + + CoRIMs that are not within their validity period, or that cannot be + associated with an authenticated and authorized source MUST be + discarded. + + Any CoRIM that has been secured by a cryptographic mechanism, such as + a signature, that fails validation MUST be discarded. + + Other selection criteria MAY be applied. For example, if the + Evidence format is known in advance, CoRIMs using a profile that is + not understood by a Verifier can be readily discarded. + + The selection process MUST yield at least one usable tag. + + Later stages will further select the CoRIMs appropriate to the + Evidence Appraisal stage. + +8.3.1.2. Tags Extraction and Validation + + The Verifier chooses tags from the selected CoRIMs - including CoMID, + CoSWID, CoBOM, and CoTS. + + The Verifier MUST discard all tags which are not syntactically and + semantically valid. In particular, any cross-referenced triples + (e.g., CoMID-CoSWID linking triples) MUST be successfully resolved. + +8.3.1.3. CoBOM Extraction + + This section is not applicable if the Verifier appraisal policy does + not require CoBOMs. + + CoBOMs which are not within their validity period are discarded. + + The Verifier processes all CoBOMs that are valid at the point in time + of Evidence Appraisal and activates all tags referenced therein. + + A Verifier MAY decide to discard some of the available and valid + CoBOMs depending on any locally configured authorization policies. + (Such policies model the trust relationships between the Verifier + Owner and the relevant suppliers, and are out of the scope of the + present document.) For example, a composite device (Section 3.3 of + [RFC9334]) is likely to be fully described by multiple CoRIMs, each + signed by a different supplier. In such case, the Verifier Owner may + instruct the Verifier to discard tags activated by supplier CoBOMs + that are not also activated by the trusted integrator. + + After the Verifier has processed all CoBOMs it MUST discard any tags + which have not been activated by a CoBOM. + +8.3.2. Evidence Collection + + During the Evidence collection phase, the Verifier communicates with + Attesters to gather Evidence. The first part of this phase does not + require any cryptographic validation. This means that Verifiers can + use untrusted code to discover Evidence sources. Attesters are + Evidence sources. + + Verifiers may rely on conveyance protocol specific context to + identify an Evidence source, which is the Evidence input oracle for + appraisal. + + The collected Evidence is then transformed to an internal + representation, making it suitable for appraisal processing. + +8.3.2.1. Cryptographic Validation of Evidence + + If Evidence is cryptographically signed, its validation is applied + before transforming Evidence to an internal representation. + + If Evidence is not cryptographically signed, the security context of + the conveyance protocol that collected it is used to + cryptographically validate Evidence. + + The way cryptographic signature validation works depends on the + specific Evidence collection method used. For example, in DICE, a + proof of liveness is carried out on the final key in the certificate + chain (a.k.a., the alias certificate). If this is successful, a + suitable certification path is looked up in the Appraisal Context, + based on linking information obtained from the DeviceID certificate. + See Section 9.2.1 of [DICE.Layer]. If a trusted root certificate is + found, the usual X.509 certificate validation is performed. + + As a second example, in PSA [I-D.tschofenig-rats-psa-token] the + verification public key is looked up in the appraisal context using + the ueid claim found in the PSA claims-set. If found, COSE Sign1 + verification is performed accordingly. + + Regardless of the specific integrity protection method used, the + Evidence's integrity MUST be validated successfully. + + If a CoRIM profile is supplied, it MUST describe: + + - How cryptographic verification key material is represented + (e.g., using Attestation Keys triples, or CoTS tags) + + - How key material is associated with the Attesting Environment + + - How the Attesting Environment is identified in Evidence + +8.3.3. Input Transformation + + Input Conceptual Messages, whether Endorsements, Reference Values, + Evidence, or Policies, are transformed to an internal representation + that is based on ECTs (Section 8.2.1). + + The following mapping conventions apply to all forms of input + transformation: + + - The environment field is populated with a Target Environment + identifier. + + - The element-list field is populated with the measurements + collected by an Attesting Environment. + + - The authority field is populated with the identity of the + entity that asserted (e.g., signed) the Conceptual Message. + + - The cmtype field is set based on the type of Conceptual Message + inputted or to be output. + + - The profile field is set based on the corim-map profile value. + +8.3.3.1. Appraisal Context Construction + + All of the extracted and validated tags are loaded into an _appraisal + context_. The Appraisal Context contains an internal representation + of the inputted Conceptual Messages. The selected tags are mapped to + an internal representation, making them suitable for appraisal + processing. + +8.3.3.2. Reference Triples Transformation + + Step 1. An rv list entry (Section 8.2.1.2) is allocated. + + Step 2. The cmtype of the addition ECT in the rv entry is set to + reference-values. + + Step 3. The Reference Values Triple (RVT) (Section 5.1.4.2) + populates the rv ECTs. + + i RVT.ref-env + + *copy*(environment-map, rv.condition.environment.environment- + map) + + *copy*(environment-map, rv.addition.environment.environment- + map) + + ii For each e in RVT.ref-claims: + + *copy*(e.measurement-map, rv.addition.element-list.element-map) + + Step 4. The signer of the Endorsement conceptual message is copied + to the rv.addition.authority field. + + Step 5. If the Endorsement conceptual message has a profile, the + profile identifier is copied to the rv.addition.profile + field. + +8.3.3.3. Endorsement Triples Transformations + + Endorsed Values Triple Transformation : + + Step 1. An ev entry (Section 8.2.1.3) is allocated. + + Step 2. The cmtype of the ev entry's addition ECT is set to + endorsements. + + Step 3. The Endorsed Values Triple (EVT) (Section 5.1.4.3) populates + the ev ECTs. + + i EVT.condition + + *copy*(environment-map, ev.condition.environment.environment- + map) + + *copy*(environment-map, ev.addition.environment.environment- + map) + + ii For each e in EVT.endorsement: + + *copy*(e.endorsement.measurement-map, ev.addition.element- + list.element-map) + + Step 4. The signer of the Endorsement conceptual message is copied + to the ev.addition.authority field. + + Step 5. If the Endorsement conceptual message has a profile, the + profile is copied to the ev.addition.profile field. + + Conditional Endorsement Triple Transformation : + + Step 1. An ev entry (Section 8.2.1.3) is allocated. + + Step 2. The cmtype of the ev entry's addition ECT is set to + endorsements. + + Step 3. Entries in the Conditional Endorsement Triple (CET) + (Section 5.1.4.4) conditions list are copied to a suitable + ECT in the internal representation. + + i For each e in CET.conditions: + + *copy*(e.stateful-environment-record.environment.environment- + map, ev.condition.environment.environment-map) + + *copy*(e.stateful-environment-record.claims-list.measurement- + map, ev.condition.element-list.element-map) + + ii For each e in CET.endorsements: + + *copy*(e.endorsed-triple-record.condition.environment-map, + ev.addition.environment.environment-map) + + *copy*(e.endorsed-triple-record.endorsement.measurement-map, + ev.addition.element-list.element-map) + + Step 4. The signer of the Conditional Endorsement conceptual message + is copied to the ev.addition.authority field. + + Step 5. If the Endorsement conceptual message has a profile, the + profile is copied to the ev.addition.profile field. + + Conditional Endorsement Series Triple Transformation : + + Step 1. An evs entry (Section 8.2.1.3) is allocated. + + Step 2. The cmtype of the evs entry's addition ECT is set to + endorsements. + + Step 3. Populate the evs ECTs using the Conditional Endorsement + Series Triple (CEST) (Section 5.1.4.5). + + i. CEST.condition: + + *copy*(stateful-environment-record.environment.environment-map, + evs.condition.environment.environment-map) + + *copy*(stateful-environment-record.claims-list.measurement-map, + evs.condition.element-list.element-map) + + ii. For each e in CEST.series: + + *copy*(evs.condition.environment.environment-map, + evs.series.selection.environment.environment-map) + + *copy*(e.conditional-series- + record.selection.measurement.measurement-map, + evs.series.selection.element-list.element-map) + + *copy*(evs.condition.environment.environment-map, + evs.series.addition.environment.environment-map) + + *copy*(e.conditional-series-record.addition.measurement-map, + evs.series.addition.element-list.element-map) + + Step 4. The signer of the Conditional Endorsement conceptual message + is copied to the evs.series.addition.authority field. + + Step 5. If the Endorsement conceptual message has a profile, the + profile is copied to the evs.series.addition.profile field. + +8.3.3.4. Evidence Tranformation + + Evidence is transformed from an external representation to an + internal representation based on the ae relation (Section 8.2.1.1). + The Evidence is mapped into one or more addition ECTs. If the + Evidence does not have a value for the mandatory ae fields, the + Verifier MUST NOT process the Evidence. + + Evidence transformation algorithms may be well-known, defined by a + CoRIM profile (Section 4.1.4), or supplied dynamically. The handling + of dynamic Evidence transformation algorithms is out of scope for + this document. + +8.4. ACS Augmentation - Phases 2, 3, and 4 + + In the ACS augmentation phase, a CoRIM Appraisal Context and an + Evidence Appraisal Policy are used by the Verifier to find CoMID + triples which match the ACS. Triples that specify an ACS matching + condition will augment the ACS with Endorsements if the condition is + met. + + Each triple is processed independently of other triples. However, + the ACS state may change as a result of processing a triple. If a + triple condition does not match, then the Verifier continues to + process other triples. + +8.4.1. ACS Requirements + + At the end of the Evidence collection process Evidence has been + converted into an internal represenetation suitable for appraisal. + See Section 8.2.1. + + Verifiers are not required to use this as their internal + representation. For the purposes of this document, appraisal is + described in terms of the above cited internal representation. + + + // Content missing. Tracked at: https://github.com/ietf-rats-wg/ + draft-ietf-rats-corim/issues/232 + +8.4.1.1. ACS Processing Requirements + + The ACS contains the actual state of Attester's Target Environments + (TEs). The state-triples field contains Evidence (from Attesters) + and Endorsements (e.g. from endorsed-triple-record). + + CoMID Reference Values will be matched against the ACS, as per the + appraisal policy of the Verifier. This document describes an example + evidence structure which can be easily matched against these + Reference Values. + + Each entry within state-triples uses the syntax of endorsed-triple- + record. When an endorsed-triple-record appears within state-triples + it indicates that the authority named by measurement-map/authorized- + by asserts that the actual state of one or more Claims within the + Target Environment, as identified by environment-map, have the + measurement values in measurement-map/mval. + + ECT authority is represented by cryptographic keys. Authority is + asserted by digitally signing a Claim using the key. Hence, Claims + are added to the ACS under the authority of a cryptographic key. + + Each Claim is encoded as an ECT. The environment-map and a key + within measurement-values-map encode the name of the Claim. The + value matching that key within measurement-values-map is the actual + state of the Claim. + + This specification does not assign special meanings to any Claim + name, it only specifies rules for determining when two Claim names + are the same. + + If two Claims have the same environment-map encoding then this does + not trigger special encoding in the Verifier. The Verifier follows + instructions in the CoRIM file which tell it how claims are related. + + If Evidence or Endorsements from different sources has the same + environment-map and authorized-by then the measurement-values-maps + are merged. + + The ACS must maintain the authority information for each ECT. There + can be multiple entries in state-triples which have the same + environment-map and a different authority. See Section 8.4.2.1.1. + + If the merged measurement-values-map contains duplicate codepoints + and the measurement values are equivalent, then duplicate claims + SHOULD be omitted. Equivalence typically means values MUST be binary + identical. + + If the merged measurement-values-map contains duplicate codepoints + and the measurement values are not equivalent, then a Verifier SHALL + report an error and stop validation processing. + +8.4.1.1.1. 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 ACS entries to match or + modify. This field may be contained in an explicit matching + condition, such as stateful-environment-record. + + The order of triples processing is important. Processing a triple + may result in ACS modifications that affect matching behavior of + other triples. + + The Verifier MUST ensure that a triple including a matching condition + is processed after any other triple that modifies or adds an ACS + entry with an environment-map that is in the matching condition. + + This can be acheived by sorting the triples before processing, by + repeating processing of some triples after ACS modifications or by + other algorithms. + +8.4.1.2. ACS Augmentation Requirements + + The ordering of ECTs in the ACS is not significant. Logically, new + ECT entries are appended to the existing ACS. But implementations + may optimize ECT order to achieve better performance. Additions to + the ACS MUST be atomic. + +8.4.2. Evidence Augmentation (Phase 2) + +8.4.2.1. Appraisal Claims Set Initialization + + The ACS is initialized by copying the internal representation of + Evidence claims to the ACS. See Section 8.4. + +8.4.2.1.1. The authorized-by field in Appraisal Claims Set + + The a field in an ECT in the ACS indicates the entity whose authority + backs the claim. + + An entity is authoritative when it makes Claims that are inside its + area of competence. The Verifier keeps track of the authorities that + assert Claims so that it can filter out claims from entities that do + not satisfy appraisal policies. + + When adding an Evidence Claim to the ACS, the Verifier SHALL set the + authorized-by field in that Claim to the trusted authority keys at + the head of each key chain which signed that Evidence. This key is + often the subject of a self-signed certificate. The Verifier has + already verified the certificate chain. See Section 8.3.2.1. + + If multiple authorities approve the same Claim, for example if + multiple key chains are available, then the authorized-by field SHALL + be set to include the trusted authority keys used by each of those + authorities. + + When adding Endorsement Claims to the ACS that resulted from CoRIM + processing (Section 8.4) the Verifier SHALL set the authorized-by + field in that Evidence to the trusted authority key that is at the + head of the key chain that signed the CoRIM. + + When searching the ACS for an entry which matches a Reference Value + containing an authorized-by field, the Verifier SHALL ignore ACS + entries if none of the keys present in the Reference Value + authorized-by field are also present in the ACS authorized-by field. + + The Verifier SHOULD set the authorized-by field in ACS entries to a + format which contains only a key, for example the tagged-cose-key- + type format. Using a common format makes it easier to compare the + field. + +8.4.3. Reference Values Corroboration and Augmentation (Phase 3) + + Reference Value Providers (RVP) publish Reference Values using the + Reference Values Triple (Section 5.1.4.2) which are transformed + (Section 8.3.3.2) into an internal representation (Section 8.2.1.2). + Reference Values may describe multiple possible Attester states. + + Corroboration is the process of determining whether actual Attester + state (as contained in the ACS) can be satisfied by Reference Values. + If satisfied, the RVP authority is added to the matching ACS entry. + + Reference Values are matched with ACS entries by iterating through + the rv list. For each rv entry, the condition ECT is compared with + an ACS ECT, where the ACS ECT cmtype contains evidence. + + + // Content missing. Tracked at: https://github.com/ietf-rats-wg/ + draft-ietf-rats-corim/issues/302 + + If the ECTs match except for authority, the rv addition ECT authority + is added to the ACS ECT authority. + +8.4.4. Endorsed Values Augmentation (Phase 4) + + + // Content missing. Tracked at: https://github.com/ietf-rats-wg/ + draft-ietf-rats-corim/issues/179 + + Endorsers publish Endorsements using endorsement triples (see + Section 5.1.4.3), Section 5.1.4.4, and Section 5.1.4.5) which are + transformed (Section 8.3.3.3) into an internal representation + (Section 8.2.1.3). Endorsements describe actual Attester state. + Endorsements are added to the ACS if the Endorsement condition is + satisifed by the ACS. + +8.4.4.1. Processing Endorsements + + Endorsements are matched with ACS entries by iterating through the ev + list. For each ev entry, the condition ECT is compared with an ACS + ECT, where the ACS ECT cmtype contains either evidence or + endorsements. If the ECTs match (Section 8.6), the ev addition ECT + is added to the ACS. + +8.4.4.2. Processing Conditional Endorsements + + Conditional Endorsement Triples are transformed into an internal + representation based on ev. Conditional endorsements have the same + processing steps as shown in (Section 8.4.4.1). + +8.4.4.3. Processing Conditional Endorsement Series + + Conditional Endorsement Series Triples are transformed into an + internal representation based on evs. Conditional series + endorsements are matched with ACS entries first by iterating through + the evs list, where for each evs entry, the condition ECT is compared + with an ACS ECT, where the ACS ECT cmtype contains either evidence or + endorsements. If the ECTs match (Section 8.6), the evs series array + is iterated, where for each series entry, if the selection ECT + matches an ACS ECT, the addition ECT is added to the ACS. Series + processing terminates when the first series entry matches. + +8.5. Examples for optional phases 5, 6, and 7 + + Phases 5, 6, and 7 are optional depending on implementation design. + Verifier implementations that apply consistency, integrity, or + validity checks could be represented as Claims that augment the ACS + or could be handled by application specific interfaces. Processing + appraisal policies may result in augmentation or modification of the + ACS, but techniques for tracking the application of policies during + appraisal need not result in ACS augmentation. Additionally, the + creation of Attestation Results is out-of-scope for this document, + nevertheless internal staging may facilitate processing of + Attestation Results. + + Phase 5: Verifier Augmentation + + Claims related to Verifier-applied consistency checks are asserted + under the authority of the Verifier. For example, the attest-key- + triple-record may contain a cryptographic key to which the Verifier + applies certificate path construction and validation. Validation may + reveal an expired certificate. The Verifier implementation might + generate a certificate path validation exception that is handled + externally, or it could generate a Claim that the certificate path is + invalid. + + Phase 6: Policy Augmentation + + Appraisal policy inputs could result in Claims that augment the ACS. + For example, an Appraisal Policy for Evidence may specify that if all + of a collection of subcomponents satisfy a particular quality metric, + the top-level component also satisfies the quality metric. The + Verifier might generate an Endorsement ECT for the top-level + component that asserts a quality metric. Details about the policy + applied may also augment the ACS. An internal representation of + policy details, based on the policy ECT, as described in + Section 8.2.1.4, contains the environments affected by the policy + with policy identifiers as Claims. + + Phase 7: Attestation Results Production and Transformation + + Attestation Results rely on input from the ACS, but may not bear any + similarity to its content. For example, Attestation Results + processing may map the ACS state to a generalized trustworthiness + state such as [I-D.ietf-rats-ar4si]. Generated Attestation Results + Claims may be specific to a particular Relying Party. Hence, the + Verifier may need to maintain multiple Attestation Results contexts. + An internal representation of Attestation Results as separate + contexts (Section 8.2.3) ensures Relying Party–specific processing + does not modify the ACS, which is common to all Relying Parties. + Attestation Results contexts are the inputs to Attestation Results + procedures that produce external representations. + +8.6. Comparing a condition ECT against the ACS + + + // Content missing. Tracked at: https://github.com/ietf-rats-wg/ + draft-ietf-rats-corim/issues/71 + + A Verifier SHALL iterate over all ACS entries and SHALL attempt to + match the condition ECT against each ACS entry. See Section 8.6.1. + A Verifier SHALL create a "matched entries" set, and SHALL populate + it with all ACS entries which matched the condition ECT. + + If the matched entries array is not empty, then the condition ECT + matches the ACS. + + If the matched entries array is empty, then the condition ECT does + not match the ACS. + +8.6.1. Comparing a condition ECT against a single ACS entry + + If the condition ECT contains a profile and the profile defines an + algorithm for a codepoint and environment-map then a Verifier MUST + use the algorithm defined by the profile (or a standard algorithm if + the profile defines that). If the condition ECT contains a profile, + but the profile does not define an algorithm for a particular + codepoint and environment-map then the verifier MUST use the standard + algorithm described in this document to compare the data at that + codepoint. + + A Verifier SHALL perform all of the comparisons defined in + Section 8.6.2, Section 8.6.3, and Section 8.6.4. + + Each of these comparisons compares one field in the condition ECT + against the same field in the ACS entry. + + If all of the fields match, then the condition ECT matches the ACS + entry. + + If any of the fields does not match, then the condition ECT does not + match the ACS entry. + +8.6.2. Environment Comparison + + A Verifier SHALL compare each field which is present in the condition + ECT environment-map against the corresponding field in the ACS entry + environment-map using binary comparison. Before performing the + binary comparison, a Verifier SHOULD convert both environment-map + fields into a form which meets CBOR Core Deterministic Encoding + Requirements [STD94]. + + If all fields which are present in the condition ECT environment-map + are present in the ACS entry and are binary identical, then the + environments match. + + If any field which is present in the condition ECT environment-map is + not present in the ACS entry, then the environments do not match. + + If any field which is present in the condition ECT environment-map is + not binary identical to the corresponding ACS entry field, then the + environments do not match. + + If a field is not present in the condition ECT environment-map then + the presence of, and value of, the corresponding ACS entry field + SHALL NOT affect whether the environments match. + +8.6.3. Authority comparison + + A Verifier SHALL compare the condition ECT's authority value to the + candidate entry's authority value. + + If every entry in the condition ECT authority has a matching entry in + the ACS entry authority field, then the authorities match. The order + of the fields in each authority field do not affect the result of the + comparison. + + If any entry in the condition ECT authority does not have a matching + entry in the ACS entry authority field then the authorities do not + match. + + When comparing two $crypto-key-type-choice fields for equality, a + Verifier SHALL treat them as equal if their deterministic CBOR + encoding is binary equal. + +8.6.4. Element list comparison + + A Verifier SHALL iterate over all the entries in the condition ECT + element-list and compare each one against the corresponding entry in + the ACS entry element-list. + + If every entry in the condition ECT element-list has a matching entry + in the ACS entry element-list field then the element lists match. + + The order of the fields in each element-list field do not affect the + result of the comparison. + + If any entry in the condition ECT element-list does not have a + matching entry in the ACS entry element-list field then the element- + list do not match. + +8.6.5. Element map comparison + + A Verifier shall compare each element-map within the condition ECT + element-list against the ACS entry element-list. + + First, a Verifier SHALL locate the entries in the ACS entry element- + list which have a matching element-id as the condition ECT element- + map. Two element-id fields are the same if they are either both + omitted, or both present with binary identical deterministic + encodings. + + Before performing the binary comparison, a Verifier SHOULD convert + both fields into a form which meets CBOR Core Deterministic Encoding + Requirements [STD94]. + + If any condition ECT entry element-id does not have a corresponding + element-id in the ACS entry then the element map does not match. + + If any condition ECT entry has multiple corresponding element-ids + then the element map does not match. + + Second, a Verifier SHALL compare the element-claims field within the + condition ECT element-list and the corresponding field from the ACS + entry. See Section 8.6.6. + +8.6.6. Measurement values map map Comparison + + A Verifier SHALL iterate over the codepoints which are present in the + condition ECT element's measurement-values-map. Each of the + codepoints present in the condition ECT measurement-values-map is + compared against the same codepoint in the candidate entry + measurement-values-map. + + If any codepoint present in the condition ECT measurement-values-map + does not have a corresponding codepoint within the candidate entry + measurement-values-map then Verifier SHALL remove that candidate + entry from the candidate entries array. + + If any codepoint present in the condition ECT measurement-values-map + does not match the same codepoint within the candidate entry + measurement-values-map then Verifier SHALL remove that candidate + entry from the candidate entries array. + +8.6.6.1. Comparison of a single measurement-values-map codepoint + + A Verifier SHALL compare each condition ECT measurement-values-map + value against the corresponding ACS entry value using the appropriate + algorithm. + + Non-negative codepoints represent standard data representations. The + comparison algorithms for these are defined in this document (in the + sections below) or in other specifications. For some non-negative + codepoints their behavior is modified by the CBOR tag at the start of + the condition ECT measurement-values-map value. + + Negative codepoints represent profile defined data representations. + A Verifier SHALL use the codepoint number, the profile associated + with the condition ECT, and the tag value (if present) to select the + comparison algorithm. + + If a Verifier is unable to determine the comparison algorithm which + applies to a codepoint then it SHALL behave as though the candidate + entry does not match the condition ECT. + + Profile writers SHOULD use CBOR tags for widely applicable comparison + methods to ease Verifier implementation compliance across profiles. + + The following subsections define the comparison algorithms for the + measurement-values-map codepoints defined by this specification. + +8.6.6.1.1. Comparison for version entries + + The value stored under measurement-values-map codepoint 0 is an + version label, which must have type version-map. Two version-map + values can only be compared for equality, as they are colloquial + versions that cannot specify ordering. + +8.6.6.1.2. Comparison for svn entries + + The ACS entry value stored under measurement-values-map codepoint 1 + is a security version number, which must have type svn-type. + + If the entry svn-type is a uint or a uint tagged with #6.552, then + comparison with the uint named as SVN is as follows. + + * If the condition ECT value for measurement-values-map codepoint 1 + is an untagged uint or a uint tagged with #6.552 then an equality + comparison is performed on the uint components. The comparison + MUST return true if the value of SVN is equal to the uint value in + the condition ECT. + + * If the condition ECT value for measurement-values-map codepoint 1 + is a uint tagged with #6.553 then a minimum comparison is + performed. The comparison MUST return true if the value of SVN is + less or equal to than the uint value in the condition ECT. + + If the entry svn-type is a uint tagged with #6.553, then comparison + with the uint named as MINSVN is as follows. + + * If the condition ECT value for measurement-values-map codepoint 1 + is an untagged uint or a uint tagged with #6.552 then the + comparison MUST return false. + + * If the condition ECT value for measurement-values-map codepoint 1 + is a uint tagged with #6.553 then an equality comparison is + performed. The comparison MUST return true if the value of MINSVN + is equal to the uint value in the condition ECT. + + The meaning of a minimum SVN as an entry value is only meaningful as + an endorsed value that has been added to the ACS. The condition + therefore treats the minimum SVN as an exact state and not one to + compare with inequality. + +8.6.6.1.3. Comparison for digests entries + + A digests entry contains one or more digests, each measuring the same + object. When multiple digests are provided, each represents a + different algorithm acceptable to the condition ECT author. + + In the simple case, a condition ECT digests entry containing one + digest matches matches a candidate entry containing a single entry + with the same algorithm and value. + + To prevent downgrade attacks, if there are multiple algorithms in + common between the condition ECT and candidate entry, then the bytes + paired with common algorithms must be equal. A Verifier SHALL treat + two algorithm identifiers as equal if they have the same + deterministic binary encoding. If both an integer and a string + representation are defined for an algorithm then entities creating + ECTs SHOULD use the integer representation. If condition ECT and ACS + entry use different names for the same algorithm, and the Verifier + does not recognize that they are the same, then a downgrade attack is + possible. + + The comparison MUST return false if the CBOR encoding of the digests + entry in the condition ECT or the ACS value with the same codepoint + is incorrect (for example if fields are missing or the wrong type). + + The comparison MUST return false if the condition ECT digests entry + does not contain any digests. + + The comparison MUST return false if either digests entry contains + multiple values for the same hash algorithm. + + The Verifier MUST iterate over the condition ECT digests array, + locating common hash algorithm identifiers (which are present in the + condition ECT and in the candidate entry). If the value associated + with any common hash algorithm identifier in the condition ECT + differs from the value for the same algorithm identifier in the + candidate entry then the comparison MUST return false. + + The comparison MUST return false if there are no hash algorithms from + the condition ECT in common with the hash algorithms from the + candidate entry ECT. + +8.6.6.1.4. Comparison for raw-value entries + + + // Content missing. Tracked at: https://github.com/ietf-rats-wg/ + draft-ietf-rats-corim/issues/71 + +8.6.6.1.5. Comparison for cryptokeys entries + + The CBOR tag of the first entry of the condition ECT cryptokeys array + is compared with the CBOR tag of the first entry of the candidate + entry cryptokeys value. If the CBOR tags match, then the bytes + following the CBOR tag from the condition ECT entry are compared with + the bytes following the CBOR tag from the candidate entry. If the + byte strings match, and there is another array entry, then the next + entry from the condition ECTs array is likewise compared with the + next entry of the ACS array. If all entries of the condition ECTs + array match a corresponding entry in the ACS array, then the + cryptokeys condition ECT matches. Otherwise, cryptokeys does not + match. + +8.6.6.1.6. Comparison for Integrity Registers + + For each Integrity Register entry in the condition ECT, the Verifier + will use the associated identifier (i.e., integrity-register-id-type- + choice) to look up the matching Integrity Register entry in the + candidate entry. If no entry is found, the comparison MUST return + false. Instead, if an entry is found, the digest comparison proceeds + as defined in Section 8.6.6.1.3 after equivalence has been found + according to Section 5.1.4.1.6. Note that it is not required for all + the entries in the candidate entry to be used during matching: the + condition ECT 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 condition ECT could describe a subset of PCRs. + +8.6.7. Profile-directed Comparison + + A profile MUST specify comparison algorithms for its additions to + $-prefixed CoRIM CDDL codepoints when this specification does not + prescribe binary comparison. The profile must specify how to compare + the CBOR tagged Reference Value against the ACS. + + Note that a Verifier may compare Reference Values in any order, so + the comparison should not be stateful. + +9. Implementation Status + + This section records the status of known implementations of the + protocol defined by this specification at the time of posting of this + Internet-Draft, and is based on a proposal described in [RFC7942]. + The description of implementations in this section is intended to + assist the IETF in its decision processes in progressing drafts to + RFCs. Please note that the listing of any individual implementation + here does not imply endorsement by the IETF. Furthermore, no effort + has been spent to verify the information presented here that was + supplied by IETF contributors. This is not intended as, and must not + be construed to be, a catalogue of available implementations or their + features. Readers are advised to note that other implementations may + exist. + + According to [RFC7942], "this will allow reviewers and working groups + to assign due consideration to documents that have the benefit of + running code, which may serve as Evidence of valuable experimentation + and feedback that have made the implemented protocols more mature. + It is up to the individual working groups to use this information as + they see fit". + +9.1. Veraison + + * Organization responsible for the implementation: Veraison Project, + Linux Foundation + + * Implementation's web page: https://github.com/veraison/corim/ + README.md (https://github.com/veraison/corim/blob/main/README.md) + + * Brief general description: 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 + (https://github.com/veraison/corim/blob/main/cocli/README.md) for + further details. + + * Implementation's level of maturity: alpha. + + * Coverage: the whole protocol is implemented, including PSA- + specific extensions [I-D.fdb-rats-psa-endorsements]. + + * Version compatibility: Version -02 of the draft + + * Licensing: Apache 2.0 https://github.com/veraison/corim/blob/main/ + LICENSE (https://github.com/veraison/corim/blob/main/LICENSE) + + * Implementation experience: n/a + + * Contact information: https://veraison.zulipchat.com + (https://veraison.zulipchat.com) + + * Last updated: https://github.com/veraison/corim/commits/main + (https://github.com/veraison/corim/commits/main) + +10. Security and Privacy Considerations + + Evidence appraisal is at the core of any RATS protocol flow, + mediating all interactions between Attesters and their Relying + Parties. The Verifier is effectively part of the Attesters' and + Relying Parties' trusted computing base (TCB). Any mistake in the + appraisal process could have security implications. For instance, it + could lead to the subversion of an access control function, which + creates a chance for privilege escalation. + + Therefore, the Verifier’s code and configuration, especially those of + the CoRIM processor, are primary security assets that must be built + and maintained as securely as possible. + + The protection of the Verifier system should be considered throughout + its entire lifecycle, from design to operation. This includes the + following aspects: + + * Minimizing implementation complexity (see also Section 6.1 of + [I-D.ietf-rats-endorsements]); + + * Using memory-safe programming languages; + + * Using secure defaults; + + * Minimizing the attack surface by avoiding unnecessary features + that could be exploited by attackers; + + * Applying the principle of least privilege to the system's users; + + * Minimizing the potential impact of security breaches by + implementing separation of duties in both the software and + operational architecture; + + * Conducting regular, automated audits and reviews of the system, + such as ensuring that users' privileges are correctly configured + and that any new code has been audited and approved by independent + parties; + + * Failing securely in the event of errors to avoid compromising the + security of the system. + + The appraisal process should be auditable and reproducible. The + integrity of the code and data during execution should be made an + explicit objective, for example ensuring that the appraisal functions + are computed in an attestable trusted execution environment (TEE). + + The integrity of public and private key material and the secrecy of + private key material must be ensured at all times. This includes key + material carried in attestation key triples and key material used to + verify the authority of triples (such as public keys that identify + trusted supply chain actors). For more detailed information on + protecting Trust Anchors, refer to Section 12.4 of [RFC9334]. + + The Verifier should use cryptographically protected, mutually + authenticated secure channels to all its trusted input sources + (Endorsers, RVPs, Verifier Owners). These links must reach as deep + as possible - possibly terminating within the appraisal session + context - to avoid man-in-the-middle attacks. Also consider + minimizing the use of intermediaries: each intermediary becomes + another party that needs to be trusted and therefore factored in the + Attesters and Relying Parties' TCBs. Refer to Section 12.2 of + [RFC9334] for information on Conceptual Messages protection. + + + // Content missing. Tracked at: https://github.com/ietf-rats-wg/ + draft-ietf-rats-corim/issues/11 + +11. IANA Considerations + +11.1. New COSE Header Parameters + + + // Content missing. Tracked at: https://github.com/ietf-rats-wg/ + draft-ietf-rats-corim/issues/12 + +11.2. New CBOR Tags + + IANA is requested to allocate the following tags in the "CBOR Tags" + registry [IANA.cbor-tags], preferably with the specific CBOR tag + value requested: + + +=======+===========+====================================+=========+ + |Tag |Data Item | Semantics |Reference| + +=======+===========+====================================+=========+ + |500 |tag | A tagged-concise-rim-type-choice, |RFCthis | + | | | see Section 4.1.2 | | + +-------+-----------+------------------------------------+---------+ + |501 |map | A tagged-corim-map, see |RFCthis | + | | | Section 4.1 | | + +-------+-----------+------------------------------------+---------+ + |502 |tag | A tagged-signed-corim, see |RFCthis | + | | | Section 4.2 | | + +-------+-----------+------------------------------------+---------+ + |503-504|any | Earmarked for CoRIM |RFCthis | + +-------+-----------+------------------------------------+---------+ + |505 |bytes | A tagged-concise-swid-tag, see |RFCthis | + | | | Section 4.1.2 | | + +-------+-----------+------------------------------------+---------+ + |506 |bytes | A tagged-concise-mid-tag, see |RFCthis | + | | | Section 4.1.2 | | + +-------+-----------+------------------------------------+---------+ + |507 |any | Earmarked for CoRIM |RFCthis | + +-------+-----------+------------------------------------+---------+ + |508 |bytes | A tagged-concise-bom-tag, see |RFCthis | + | | | Section 4.1.2 | | + +-------+-----------+------------------------------------+---------+ + |509-549|any | Earmarked for CoRIM |RFCthis | + +-------+-----------+------------------------------------+---------+ + |550 |bytes .size| tagged-ueid-type, see Section 7.5 |RFCthis | + | |33 | | | + +-------+-----------+------------------------------------+---------+ + |552 |uint | tagged-svn, see |RFCthis | + | | | Section 5.1.4.1.4.4 | | + +-------+-----------+------------------------------------+---------+ + |553 |uint | tagged-min-svn, see |RFCthis | + | | | Section 5.1.4.1.4.4 | | + +-------+-----------+------------------------------------+---------+ + |554 |text | tagged-pkix-base64-key-type, see |RFCthis | + | | | Section 5.1.4.1.5 | | + +-------+-----------+------------------------------------+---------+ + |555 |text | tagged-pkix-base64-cert-type, see |RFCthis | + | | | Section 5.1.4.1.5 | | + +-------+-----------+------------------------------------+---------+ + |556 |text | tagged-pkix-base64-cert-path-type, |RFCthis | + | | | see Section 5.1.4.1.5 | | + +-------+-----------+------------------------------------+---------+ + |557 |[int/text, | tagged-thumbprint-type, see |RFCthis | + | |bytes] | Section 7.7 | | + +-------+-----------+------------------------------------+---------+ + |558 |COSE_Key/ | tagged-cose-key-type, see |RFCthis | + | |COSE_KeySet| Section 5.1.4.1.5 | | + +-------+-----------+------------------------------------+---------+ + |559 |digest | tagged-cert-thumbprint-type, see |RFCthis | + | | | Section 5.1.4.1.5 | | + +-------+-----------+------------------------------------+---------+ + |560 |bytes | tagged-bytes, see Section 7.8 |RFCthis | + +-------+-----------+------------------------------------+---------+ + |561 |digest | tagged-cert-path-thumbprint-type, |RFCthis | + | | | see Section 5.1.4.1.5 | | + +-------+-----------+------------------------------------+---------+ + |562 |bytes | tagged-pkix-asn1der-cert-type, see |RFCthis | + | | | Section 5.1.4.1.5 | | + +-------+-----------+------------------------------------+---------+ + |563-599|any | Earmarked for CoRIM |RFCthis | + +-------+-----------+------------------------------------+---------+ + + Table 8 + + Tags designated as "Earmarked for CoRIM" can be reassigned by IANA + based on advice from the designated expert for the CBOR Tags + registry. + +11.3. CoRIM Map Registry + + This document defines a new registry titled "CoRIM Map". The + registry uses integer values as index values for items in 'unsigned- + corim-map' CBOR maps. + + Future registrations for this registry are to be made based on + [RFC8126] as follows: + + +=========+=========================+ + | Range | Registration Procedures | + +=========+=========================+ + | 0-127 | Standards Action | + +---------+-------------------------+ + | 128-255 | Specification Required | + +---------+-------------------------+ + + Table 9: CoRIM Map Items + Registration Procedures + + All negative values are reserved for Private Use. + + Initial registrations for the "CoRIM Map" registry are provided + below. Assignments consist of an integer index value, the item name, + and a reference to the defining specification. + + +=======+================+===============+ + | Index | Item Name | Specification | + +=======+================+===============+ + | 0 | id | RFCthis | + +-------+----------------+---------------+ + | 1 | tags | RFCthis | + +-------+----------------+---------------+ + | 2 | dependent-rims | RFCthis | + +-------+----------------+---------------+ + | 3 | profile | RFCthis | + +-------+----------------+---------------+ + | 4 | rim-validity | RFCthis | + +-------+----------------+---------------+ + | 5 | entities | RFCthis | + +-------+----------------+---------------+ + | 3-255 | Unassigned | | + +-------+----------------+---------------+ + + Table 10: CoRIM Map Items Initial + Registrations + +11.4. CoMID Map Registry + + This document defines a new registry titled "CoMID Map". The + registry uses integer values as index values for items in 'concise- + mid-tag' CBOR maps. + + Future registrations for this registry are to be made based on + [RFC8126] as follows: + + +=========+=========================+ + | Range | Registration Procedures | + +=========+=========================+ + | 0-127 | Standards Action | + +---------+-------------------------+ + | 128-255 | Specification Required | + +---------+-------------------------+ + + Table 11: CoMID Map Items + Registration Procedures + + All negative values are reserved for Private Use. + + Initial registrations for the "CoMID Map" registry are provided + below. Assignments consist of an integer index value, the item name, + and a reference to the defining specification. + + +=======+==============+===============+ + | Index | Item Name | Specification | + +=======+==============+===============+ + | 0 | language | RFCthis | + +-------+--------------+---------------+ + | 1 | tag-identity | RFCthis | + +-------+--------------+---------------+ + | 2 | entity | RFCthis | + +-------+--------------+---------------+ + | 3 | linked-tags | RFCthis | + +-------+--------------+---------------+ + | 4 | triples | RFCthis | + +-------+--------------+---------------+ + | 5-255 | Unassigned | | + +-------+--------------+---------------+ + + Table 12: CoMID Map Items Initial + Registrations + +11.5. CoBOM Map Registry + + This document defines a new registry titled "CoBOM Map". The + registry uses integer values as index values for items in 'concise- + bom-tag' CBOR maps. + + Future registrations for this registry are to be made based on + [RFC8126] as follows: + + +=========+=========================+ + | Range | Registration Procedures | + +=========+=========================+ + | 0-127 | Standards Action | + +---------+-------------------------+ + | 128-255 | Specification Required | + +---------+-------------------------+ + + Table 13: CoBOM Map Items + Registration Procedures + + All negative values are reserved for Private Use. + + Initial registrations for the "CoBOM Map" registry are provided + below. Assignments consist of an integer index value, the item name, + and a reference to the defining specification. + + +=======+==============+===============+ + | Index | Item Name | Specification | + +=======+==============+===============+ + | 0 | tag-identity | RFCthis | + +-------+--------------+---------------+ + | 1 | tags-list | RFCthis | + +-------+--------------+---------------+ + | 2 | bom-validity | RFCthis | + +-------+--------------+---------------+ + | 5-255 | Unassigned | | + +-------+--------------+---------------+ + + Table 14: CoBOM Map Items Initial + Registrations + +11.6. New Media Types + + IANA is requested to add the following media types to the "Media + Types" registry [IANA.media-types]. + + +=====================+=====================+==================+ + | Name | Template | Reference | + +=====================+=====================+==================+ + | corim-signed+cbor | application/corim- | RFCthis, | + | | signed+cbor | (Section 11.6.1) | + +---------------------+---------------------+------------------+ + | corim-unsigned+cbor | application/corim- | RFCthis, | + | | unsigned+cbor | (Section 11.6.2) | + +---------------------+---------------------+------------------+ + + Table 15: New Media Types + +11.6.1. 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: (Section 10) of RFCthis + Interoperability considerations: n/a + Published specification: RFCthis + Applications that use this media type: Attestation Verifiers, + Endorsers and Reference-Value providers that need to transfer 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 and email address to contact for further information: RATS WG + mailing list (rats@ietf.org) + Intended usage: COMMON + Restrictions on usage: none + Author/Change controller: IETF + Provisional registration? Maybe + +11.6.2. 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: Section 10 of RFCthis + Interoperability considerations: n/a + Published specification: RFCthis + Applications that use this media type: Attestation Verifiers, + Endorsers and Reference-Value providers that need to transfer + unprotected CoRIM payloads over HTTP(S), CoAP(S), and other + transports. + Fragment identifier considerations: n/a + Magic number(s): D9 01 F5, D9 01 F4 D9 01 F5 + File extension(s): n/a + Macintosh file type code(s): n/a + Person and email address to contact for further information: RATS WG + mailing list (rats@ietf.org) + Intended usage: COMMON + Restrictions on usage: none + Author/Change controller: IETF + Provisional registration? Maybe + +11.7. CoAP Content-Formats Registration + + IANA is requested to register the two following Content-Format + numbers in the "CoAP Content-Formats" sub-registry, within the + "Constrained RESTful Environments (CoRE) Parameters" Registry + [IANA.core-parameters]: + + +===============================+================+======+===========+ + | Content-Type | Content Coding | ID | Reference | + +===============================+================+======+===========+ + | application/corim- | - | TBD1 | RFCthis | + | signed+cbor | | | | + +-------------------------------+----------------+------+-----------+ + | application/corim- | - | TBD2 | RFCthis | + | unsigned+cbor | | | | + +-------------------------------+----------------+------+-----------+ + + Table 16: New Content-Formats + +12. References + +12.1. Normative References + + [IANA.cbor-tags] + IANA, "Concise Binary Object Representation (CBOR) Tags", + . + + [IANA.core-parameters] + IANA, "Constrained RESTful Environments (CoRE) + Parameters", + . + + [IANA.language-subtag-registry] + IANA, "Language Subtag Registry", + . + + [IANA.media-types] + IANA, "Media Types", + . + + [IANA.named-information] + IANA, "Named Information", + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally + Unique IDentifier (UUID) URN Namespace", RFC 4122, + DOI 10.17487/RFC4122, July 2005, + . + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + . + + [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, + PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, + April 2015, . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data + Definition Language (CDDL): A Notational Convention to + Express Concise Binary Object Representation (CBOR) and + JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, + June 2019, . + + [RFC9090] Bormann, C., "Concise Binary Object Representation (CBOR) + Tags for Object Identifiers", RFC 9090, + DOI 10.17487/RFC9090, July 2021, + . + + [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and + W. Pan, "Remote ATtestation procedureS (RATS) + Architecture", RFC 9334, DOI 10.17487/RFC9334, January + 2023, . + + [RFC9393] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. + Waltermire, "Concise Software Identification Tags", + RFC 9393, DOI 10.17487/RFC9393, June 2023, + . + + [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + . + + [STD94] Bormann, C. and P. Hoffman, "Concise Binary Object + Representation (CBOR)", STD 94, RFC 8949, + DOI 10.17487/RFC8949, December 2020, + . + + [STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE): + Structures and Process", STD 96, RFC 9052, + DOI 10.17487/RFC9052, August 2022, + . + + [X.690] International Telecommunications Union, "Information + technology — ASN.1 encoding rules: Specification of Basic + Encoding Rules (BER), Canonical Encoding Rules (CER) and + Distinguished Encoding Rules (DER)", ITU-T Recommendation + X.690, August 2015, . + +12.2. Informative References + + [DICE.Layer] + Trusted Computing Group, "DICE Layering Architecture", + Version 1.0, Revision 0.19 , July 2020, + . + + [I-D.fdb-rats-psa-endorsements] + Fossati, T., Deshpande, Y., and H. Birkholz, "Arm's + Platform Security Architecture (PSA) Attestation Verifier + Endorsements", Work in Progress, Internet-Draft, draft- + fdb-rats-psa-endorsements-05, 30 August 2024, + . + + [I-D.ietf-rats-ar4si] + Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V. + Scarlata, "Attestation Results for Secure Interactions", + Work in Progress, Internet-Draft, draft-ietf-rats-ar4si- + 07, 2 September 2024, + . + + [I-D.ietf-rats-cobom] + "*** BROKEN REFERENCE ***". + + [I-D.ietf-rats-concise-ta-stores] + Wallace, C., Housley, R., Fossati, T., and Y. Deshpande, + "Concise TA Stores (CoTS)", Work in Progress, Internet- + Draft, draft-ietf-rats-concise-ta-stores-02, 5 December + 2023, . + + [I-D.ietf-rats-eat] + Lundblade, L., Mandyam, G., O'Donoghue, J., and C. + Wallace, "The Entity Attestation Token (EAT)", Work in + Progress, Internet-Draft, draft-ietf-rats-eat-31, 6 + September 2024, . + + [I-D.ietf-rats-endorsements] + Thaler, D., Birkholz, H., and T. Fossati, "RATS + Endorsements", Work in Progress, Internet-Draft, draft- + ietf-rats-endorsements-03, 23 July 2024, + . + + [I-D.tschofenig-rats-psa-token] + Tschofenig, H., Frost, S., Brossard, M., Shaw, A. L., and + T. Fossati, "Arm's Platform Security Architecture (PSA) + Attestation Token", Work in Progress, Internet-Draft, + draft-tschofenig-rats-psa-token-24, 23 September 2024, + . + + [IANA.coswid] + IANA, "Concise Software Identifier (CoSWID)", + . + + [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running + Code: The Implementation Status Section", BCP 205, + RFC 7942, DOI 10.17487/RFC7942, July 2016, + . + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + . + +Appendix A. Base CoRIM CDDL + + corim = tagged-concise-rim-type-choice + + $concise-rim-type-choice /= tagged-corim-map + $concise-rim-type-choice /= tagged-signed-corim + + concise-bom-tag = { + &(tag-identity: 0) => tag-identity-map + &(tags-list: 1) => [ + tag-identity-map ], + &(bom-validity: 2) => validity-map + * $$concise-bom-tag-extension + } + + $concise-tag-type-choice /= tagged-concise-swid-tag + $concise-tag-type-choice /= tagged-concise-mid-tag + $concise-tag-type-choice /= tagged-concise-bom-tag + + corim-entity-map = + entity-map<$corim-role-type-choice, $$corim-entity-map-extension> + + $corim-id-type-choice /= tstr + $corim-id-type-choice /= uuid-type + + corim-locator-map = { + &(href: 0) => uri + ? &(thumbprint: 1) => digest + } + + corim-map = { + &(id: 0) => $corim-id-type-choice + &(tags: 1) => [ + $concise-tag-type-choice ] + ? &(dependent-rims: 2) => [ + corim-locator-map ] + ? &(profile: 3) => $profile-type-choice + ? &(rim-validity: 4) => validity-map + ? &(entities: 5) => [ + corim-entity-map ] + * $$corim-map-extension + } + + corim-meta-map = { + &(signer: 0) => corim-signer-map + ? &(signature-validity: 1) => validity-map + } + + $corim-role-type-choice /= &(manifest-creator: 1) + + corim-signer-map = { + &(signer-name: 0) => $entity-name-type-choice + ? &(signer-uri: 1) => uri + * $$corim-signer-map-extension + } + + COSE-Sign1-corim = [ + protected: bstr .cbor protected-corim-header-map + unprotected: unprotected-corim-header-map + payload: bstr .cbor tagged-corim-map + signature: bstr + ] + + $profile-type-choice /= uri + $profile-type-choice /= tagged-oid-type + + protected-corim-header-map = { + &(alg: 1) => int + &(content-type: 3) => "application/corim-unsigned+cbor" + &(kid: 4) => bstr + &(corim-meta: 8) => bstr .cbor corim-meta-map + * cose-label => cose-value + } + + signed-corim = #6.18(COSE-Sign1-corim) + + tagged-corim-map = #6.501(corim-map) + + + tagged-concise-rim-type-choice = #6.500($concise-rim-type-choice) + + tagged-signed-corim = #6.502(signed-corim) + + tagged-concise-swid-tag = #6.505(bytes .cbor concise-swid-tag) + + tagged-concise-mid-tag = #6.506(bytes .cbor concise-mid-tag) + + tagged-concise-bom-tag = #6.508(bytes .cbor concise-bom-tag) + + unprotected-corim-header-map = { + * cose-label => cose-value + } + + validity-map = { + ? &(not-before: 0) => time + &(not-after: 1) => time + } + + concise-mid-tag = { + ? &(language: 0) => text + &(tag-identity: 1) => tag-identity-map + ? &(entities: 2) => [ + comid-entity-map ] + ? &(linked-tags: 3) => [ + linked-tag-map ] + &(triples: 4) => triples-map + * $$concise-mid-tag-extension + } + + accepted-claims-set = { + &(state-triples: 0) => [ + endorsed-triple-record ] + ? &(identity-triples: 1) => [ + identity-triple-record ] + ? &(coswid-triples: 2) => [ + ev-coswid-triple-record ] + * $$accepted-claims-set-extension + } + + attest-key-triple-record = [ + environment-map + [ + $crypto-key-type-choice ] + ] + + $class-id-type-choice /= tagged-oid-type + $class-id-type-choice /= tagged-uuid-type + $class-id-type-choice /= tagged-bytes + + class-map = non-empty<{ + ? &(class-id: 0) => $class-id-type-choice + ? &(vendor: 1) => tstr + ? &(model: 2) => tstr + ? &(layer: 3) => uint + ? &(index: 4) => uint + }> + + comid-entity-map = + entity-map<$comid-role-type-choice, $$comid-entity-map-extension> + + $comid-role-type-choice /= &(tag-creator: 0) + $comid-role-type-choice /= &(creator: 1) + $comid-role-type-choice /= &(maintainer: 2) + + conditional-endorsement-series-triple-record = [ + condition: stateful-environment-record + series: [ + conditional-series-record ] + ] + + conditional-series-record = [ + selection: [ + measurement-map] + addition: [ + measurement-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 + $crypto-key-type-choice /= tagged-pkix-asn1der-cert-type + $crypto-key-type-choice /= tagged-bytes + + tagged-pkix-base64-key-type = #6.554(tstr) + tagged-pkix-base64-cert-type = #6.555(tstr) + tagged-pkix-base64-cert-path-type = #6.556(tstr) + tagged-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) + tagged-pkix-asn1der-cert-type = #6.562(bstr) + + domain-dependency-triple-record = [ + $domain-type-choice + [ + $domain-type-choice ] + ] + + domain-membership-triple-record = [ + $domain-type-choice + [ + environment-map ] + ] + + conditional-endorsement-triple-record = [ + conditions: [ + stateful-environment-record ] + endorsements: [ + endorsed-triple-record ] + ] + + $domain-type-choice /= uint + $domain-type-choice /= text + $domain-type-choice /= tagged-uuid-type + $domain-type-choice /= tagged-oid-type + + endorsed-triple-record = [ + condition: environment-map + endorsement: [ + measurement-map ] + ] + + entity-map = { + &(entity-name: 0) => $entity-name-type-choice + ? &(reg-id: 1) => uri + &(role: 2) => [ + role-type-choice ] + * extension-socket + } + + $entity-name-type-choice /= text + + environment-map = non-empty<{ + ? &(class: 0) => class-map + ? &(instance: 1) => $instance-id-type-choice + ? &(group: 2) => $group-id-type-choice + }> + + flags-map = { + ? &(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 + $measured-element-type-choice /= tstr + + measurement-map = { + ? &(mkey: 0) => $measured-element-type-choice + &(mval: 1) => measurement-values-map + ? &(authorized-by: 2) => [ + $crypto-key-type-choice ] + } + + measurement-values-map = non-empty<{ + ? &(version: 0) => version-map + ? &(svn: 1) => svn-type-choice + ? &(digests: 2) => digests-type + ? &(flags: 3) => flags-map + ? ( + &(raw-value: 4) => $raw-value-type-choice, + ? &(raw-value-mask: 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 = [ + ref-env: environment-map + ref-claims: [ + measurement-map ] + ] + + stateful-environment-record = [ + environment: environment-map, + claims-list: [ + measurement-map ] + ] + + svn-type = uint + svn = svn-type + min-svn = svn-type + tagged-svn = #6.552(svn) + tagged-min-svn = #6.553(min-svn) + svn-type-choice = svn / tagged-svn / tagged-min-svn + + $tag-id-type-choice /= tstr + $tag-id-type-choice /= uuid-type + + tag-identity-map = { + &(tag-id: 0) => $tag-id-type-choice + ? &(tag-version: 1) => tag-version-type + } + + $tag-rel-type-choice /= &(supplements: 0) + $tag-rel-type-choice /= &(replaces: 1) + + tag-version-type = uint .default 0 + + tagged-bytes = #6.560(bytes) + + triples-map = non-empty<{ + ? &(reference-triples: 0) => + [ + reference-triple-record ] + ? &(endorsed-triples: 1) => + [ + endorsed-triple-record ] + ? &(identity-triples: 2) => + [ + identity-triple-record ] + ? &(attest-key-triples: 3) => + [ + attest-key-triple-record ] + ? &(dependency-triples: 4) => + [ + domain-dependency-triple-record ] + ? &(membership-triples: 5) => + [ + domain-membership-triple-record ] + ? &(coswid-triples: 6) => + [ + coswid-triple-record ] + ? &(conditional-endorsement-series-triples: 8) => + [ + conditional-endorsement-series-triple-record ] + ? &(conditional-endorsement-triples: 10) => + [ + conditional-endorsement-triple-record ] + * $$triples-map-extension + }> + + ueid-type = bytes .size 33 + tagged-ueid-type = #6.550(ueid-type) + + uuid-type = bytes .size 16 + tagged-uuid-type = #6.37(uuid-type) + + version-map = { + &(version: 0) => text + ? &(version-scheme: 1) => $version-scheme + } + + digest = [ + alg: (int / text), + val: bytes + ] + + digests-type = [ + digest ] + + integrity-register-id-type-choice = uint / text + + integrity-registers = { + + integrity-register-id-type-choice => digests-type + } + + concise-swid-tag = { + tag-id => text / bstr .size 16, + tag-version => integer, + ? corpus => bool, + ? patch => bool, + ? supplemental => bool, + software-name => text, + ? software-version => text, + ? version-scheme => $version-scheme, + ? media => text, + ? software-meta => one-or-more, + 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 + + Carl Wallace for review and comments on this document. + +Contributors + + Carsten Bormann + Universität Bremen TZI + Postfach 330440 + D-28359 Bremen + Germany + Phone: +49-421-218-63921 + Email: cabo@tzi.org + + + Carsten Bormann contributed to the CDDL specifications and the IANA + considerations. + + Andrew Draper + Intel Corporation + Email: andrew.draper@intel.com + + + Andrew contributed the concept, description, and semantics of + conditional endorsements as well as consistent contribution to weekly + reviews of others' edits. + + Dionna Glaze + Google LLC + Email: dionnaglaze@google.com + + + Dionna contributed many clarifying questions and disambiguations to + the semantics of attestation appraisal as well as consistent + contribution to weekly reviews of others' edits. + +Authors' Addresses + + Henk Birkholz + Fraunhofer SIT + Email: henk.birkholz@ietf.contact + + + Thomas Fossati + Linaro + Email: Thomas.Fossati@linaro.org + + + Yogesh Deshpande + arm + Email: yogesh.deshpande@arm.com + + + Ned Smith + Intel + Email: ned.smith@intel.com + + + Wei Pan + Huawei Technologies + Email: william.panwei@huawei.com diff --git a/Section-restructuring/index.html b/Section-restructuring/index.html new file mode 100644 index 00000000..91af124a --- /dev/null +++ b/Section-restructuring/index.html @@ -0,0 +1,45 @@ + + + + ietf-rats-wg/draft-ietf-rats-corim Section-restructuring preview + + + + +

Editor's drafts for Section-restructuring branch of ietf-rats-wg/draft-ietf-rats-corim

+ + + + + + +
CoRIMplain textsame as main
+ + + diff --git a/index.html b/index.html index f0ab789c..b4bc89c8 100644 --- a/index.html +++ b/index.html @@ -56,6 +56,14 @@

Preview for branch tcg-compatible

diff with main +

Preview for branch Section-restructuring

+ + + + + + +
CoRIMplain textdiff with main

Preview for branch series-triple-element-multiplicity