From a5a32094d40ce9f33bd0b09f8dbb77f9891f68ff Mon Sep 17 00:00:00 2001 From: Ned Smith Date: Wed, 16 Oct 2024 07:04:58 -0700 Subject: [PATCH 1/8] Allow mkey tstr (#325) * Update measured-element-type-choice.cddl Added tstr as mkey type. * Update comid-3.diag Added mkey examples for all of the possible mkey types. * Update draft-ietf-rats-corim.md Added tstr as an mkey type. --- cddl/examples/comid-3.diag | 34 +++++++++++++++++++++++++- cddl/measured-element-type-choice.cddl | 1 + draft-ietf-rats-corim.md | 2 +- 3 files changed, 35 insertions(+), 2 deletions(-) diff --git a/cddl/examples/comid-3.diag b/cddl/examples/comid-3.diag index ec0e66d3..759638ae 100644 --- a/cddl/examples/comid-3.diag +++ b/cddl/examples/comid-3.diag @@ -28,9 +28,41 @@ / hash-alg-id / 6, / sha-256-32 / / hash-value / h'ABCDEF00' ]] } + }, + / measurement-map / { + / comid.mkey / 0: "my_element", + / comid.mval / 1 : { + / comid.digests / 2 : [[ + / hash-alg-id / 6, / sha-256-32 / + / hash-value / h'00FEDCBA' ]] + } + }, + / measurement-map / { + / comid.mkey / 0: 111( h'5502C001' ), + / comid.mval / 1 : { + / comid.digests / 2 : [[ + / hash-alg-id / 6, / sha-256-32 / + / hash-value / h'00FEDCBA' ]] + } + }, + / measurement-map / { + / comid.mkey / 0: 37( h'67b28b6c34cc40a19117ab5b05911e38' ), + / comid.mval / 1 : { + / comid.digests / 2 : [[ + / hash-alg-id / 6, / sha-256-32 / + / hash-value / h'00FEDCBA' ]] + } + }, + / measurement-map / { + / anonymous mkey / + / comid.mval / 1 : { + / comid.digests / 2 : [[ + / hash-alg-id / 6, / sha-256-32 / + / hash-value / h'11223344' ]] + } } ] ] ] } -} +} \ No newline at end of file diff --git a/cddl/measured-element-type-choice.cddl b/cddl/measured-element-type-choice.cddl index 72b05595..cc33cc99 100644 --- a/cddl/measured-element-type-choice.cddl +++ b/cddl/measured-element-type-choice.cddl @@ -1,3 +1,4 @@ $measured-element-type-choice /= tagged-oid-type $measured-element-type-choice /= tagged-uuid-type $measured-element-type-choice /= uint +$measured-element-type-choice /= tstr diff --git a/draft-ietf-rats-corim.md b/draft-ietf-rats-corim.md index 835e05a0..ea1cde4f 100644 --- a/draft-ietf-rats-corim.md +++ b/draft-ietf-rats-corim.md @@ -812,7 +812,7 @@ The following describes each member of the `measurement-map`: ###### Measurement Keys {#sec-comid-mkey} Measurement keys are locally scoped extensible identifiers. -The initial types defined are OID, UUID, and uint. +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`. From 67ec31cf5c6b03476fa763f28026e44a83a7a798 Mon Sep 17 00:00:00 2001 From: nedmsmith Date: Wed, 16 Oct 2024 13:19:40 -0700 Subject: [PATCH 2/8] Section restructuring Created a section for acs augmentation and put ACS requirements, and phase 2 - 4 sections inside. order of triple processing became part of ACS requirements and augmentation using CoMID triples became introduction to the new ACS augmentation section --- draft-ietf-rats-corim.md | 198 +++++++++++++++++++-------------------- 1 file changed, 99 insertions(+), 99 deletions(-) diff --git a/draft-ietf-rats-corim.md b/draft-ietf-rats-corim.md index ea1cde4f..b2d890b6 100644 --- a/draft-ietf-rats-corim.md +++ b/draft-ietf-rats-corim.md @@ -1998,14 +1998,103 @@ If the Evidence does not have a value for the mandatory `ae` fields, the Verifie Evidence transformation algorithms may be well-known, defined by a CoRIM profile ({{sec-corim-profile-types}}), or supplied dynamically. The handling of dynamic Evidence transformation algorithms is out of scope for this document. -## Evidence Augmentation (Phase 2) {#sec-phase2} +## ACS Augmentation - Phases 2, 3, and 4 {#sec-acs-aug} -### Appraisal Claims Set Initialization {#sec-acs-initialization} +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. + +### ACS Requirements {#sec-acs-reqs} + +At the end of the Evidence collection process Evidence has been converted into an internal represenetation suitable for appraisal. +See {{sec-ir-cm}}. + +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. + +[^issue] https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/232 + +#### 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-map`s 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 {{sec-authorized-by}}. + +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. + +##### 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. + +#### ACS Augmentation Requirements {#sec-acs-aug-req} + +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. + +### Evidence Augmentation (Phase 2) {#sec-phase2} + +#### Appraisal Claims Set Initialization {#sec-acs-initialization} The ACS is initialized by copying the internal representation of Evidence claims to the ACS. -See {{sec-add-to-acs}}. +See {{sec-acs-aug}}. -#### The authorized-by field in Appraisal Claims Set {#sec-authorized-by} +##### The authorized-by field in Appraisal Claims Set {#sec-authorized-by} The `a` field in an ECT in the ACS indicates the entity whose authority backs the claim. @@ -2026,7 +2115,7 @@ are available, then the `authorized-by` field SHALL be set to include the truste authority keys used by each of those authorities. When adding Endorsement Claims to the ACS that resulted -from CoRIM processing ({{sec-add-to-acs}}) the Verifier SHALL set the +from CoRIM processing ({{sec-acs-aug}}) 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. @@ -2039,29 +2128,7 @@ 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. -#### Appraisal Claims Set augmentation using CoMID triples - -In the ACS augmentation phase, a CoRIM Appraisal Context and an Evidence Appraisal Policy are used by the Verifier to find CoMID triples which match the ACS. -Triples that specify an ACS matching condition will augment the ACS with Endorsements if the condition is met. - -Each triple is processed independently of other triples. -However, the ACS state may change as a result of processing a triple. -If a triple condition does not match, then the Verifier continues to process other triples. - -#### 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. - -## Reference Values Corroboration and Augmentation (Phase 3) {#sec-phase3} +### Reference Values Corroboration and Augmentation (Phase 3) {#sec-phase3} Reference Value Providers (RVP) publish Reference Values using the Reference Values Triple ({{sec-comid-triple-refval}}) which are transformed ({{sec-ref-trans}}) into an internal representation ({{sec-ir-ref-val}}). Reference Values may describe multiple possible Attester states. @@ -2076,7 +2143,7 @@ For each `rv` entry, the `condition` ECT is compared with an ACS ECT, where the If the ECTs match except for authority, the `rv` `addition` ECT authority is added to the ACS ECT authority. -## Endorsed Values Augmentation (Phase 4) {#sec-phase4} +### Endorsed Values Augmentation (Phase 4) {#sec-phase4} [^issue] https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/179 @@ -2084,18 +2151,18 @@ Endorsers publish Endorsements using endorsement triples (see {{sec-comid-triple Endorsements describe actual Attester state. Endorsements are added to the ACS if the Endorsement condition is satisifed by the ACS. -### Processing Endorsements {#sec-process-end} +#### Processing Endorsements {#sec-process-end} 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 ({{sec-match-condition-ect}}), the `ev` `addition` ECT is added to the ACS. -### Processing Conditional Endorsements {#sec-process-cond-end} +#### Processing Conditional Endorsements {#sec-process-cond-end} Conditional Endorsement Triples are transformed into an internal representation based on `ev`. Conditional endorsements have the same processing steps as shown in ({{sec-process-end}}). -### Processing Conditional Endorsement Series {#sec-process-series} +#### Processing Conditional Endorsement Series {#sec-process-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, @@ -2136,73 +2203,6 @@ Hence, the Verifier may need to maintain multiple Attestation Results contexts. An internal representation of Attestation Results as separate contexts ({{sec-ir-ars}}) 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. -## Adding to the Appraisal Claims Set {#sec-add-to-acs} - -### Appraisal Claims Set Requirements {#sec-acs-reqs} - -At the end of the Evidence collection process Evidence has been converted into an internal represenetation suitable for appraisal. -See {{sec-ir-cm}}. - -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. - -[^issue] https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/232 - -The ACS contains the actual state of Attester's Target Environments (TEs). -The `state-triples` field contains Evidence (from Attesters) and Endorsements -(e.g. from `endorsed-triple-record`). - -CoMID Reference Values will be matched against the ACS, as per -the appraisal policy of the Verifier. -This document describes an example evidence structure which can be easily -matched against these Reference Values. - -Each entry within `state-triples` uses the syntax of `endorsed-triple-record`. -When an `endorsed-triple-record` appears within `state-triples` it -indicates that the authority named by `measurement-map`/`authorized-by` -asserts that the actual state of one or more Claims within the -Target Environment, as identified by `environment-map`, have the -measurement values in `measurement-map`/`mval`. - -ECT authority is represented by cryptographic keys. Authority -is asserted by digitally signing a Claim using the key. Hence, Claims are -added to the ACS under the authority of a cryptographic key. - -Each Claim is encoded as an ECT. The `environment-map` and a -key within `measurement-values-map` encode the name of the Claim. -The value matching that key within `measurement-values-map` is the actual -state of the Claim. - -This specification does not assign special meanings to any Claim name, -it only specifies rules for determining when two Claim names are the same. - -If two Claims have the same `environment-map` encoding then this does not -trigger special encoding in the Verifier. The Verifier follows instructions -in the CoRIM file which tell it how claims are related. - -If Evidence or Endorsements from different sources has the same `environment-map` -and `authorized-by` then the `measurement-values-map`s 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 {{sec-authorized-by}}. - -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. - -### ACS Augmentation {#sec-acs-aug} - -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. - ## Comparing a condition ECT against the ACS {#sec-match-condition-ect} [^issue] https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/71 From cef560ec815f27d0289991aefa912ada22ac8f65 Mon Sep 17 00:00:00 2001 From: Ned Smith Date: Fri, 18 Oct 2024 11:03:29 -0700 Subject: [PATCH 3/8] Update prose to reflect authorized-by and authority processing (#323) * Update prose to reflect authorized-by and authority processing Issue #293 and #159 are addressed by this PR. Some section naming cleanup also applied. * Update draft-ietf-rats-corim.md Co-authored-by: Thomas Fossati * Update draft-ietf-rats-corim.md Co-authored-by: Henk Birkholz * Update draft-ietf-rats-corim.md fixed whitespace * Update draft-ietf-rats-corim.md improved verbose lines. * Update draft-ietf-rats-corim.md Co-authored-by: Yogesh Deshpande * More detail around signers Added detail that there could be multiple corim signers and hence the possibility for different search criteria applied to authorized-by in measurement-map. * Update draft-ietf-rats-corim.md remove duplicate lines --------- Co-authored-by: Dionna Amalie Glaze Co-authored-by: Thomas Fossati Co-authored-by: Henk Birkholz Co-authored-by: Yogesh Deshpande --- draft-ietf-rats-corim.md | 131 ++++++++++++++------------------------- 1 file changed, 46 insertions(+), 85 deletions(-) diff --git a/draft-ietf-rats-corim.md b/draft-ietf-rats-corim.md index ea1cde4f..e1c7dc14 100644 --- a/draft-ietf-rats-corim.md +++ b/draft-ietf-rats-corim.md @@ -641,6 +641,13 @@ The `triples-map` contains all the CoMID triples broken down per category. Not all category need to be present but at least one category MUST be present and contain at least one entry. +In most cases, the supply chain entity that is responsible for providing a triple (i.e., Reference Values or Endorsed Values) is by default the CoRIM signer. +The signer of a triple is said to be its *authority*. +However, multiple authorities may be involved in signing triples. +See {{-cose}}. +Consequently, authority may differ for search criteria. +See {{sec-measurements}}. + ~~~ cddl {::include cddl/triples-map.cddl} ~~~ @@ -764,7 +771,7 @@ The types defined for a group identified are UUID and variable-length opaque byt {::include cddl/group-id-type-choice.cddl} ~~~ -##### Measurements +##### Measurements {#sec-measurements} Measurements can be of a variety of things including software, firmware, configuration files, read-only memory, fuses, IO ring configuration, partial @@ -783,14 +790,12 @@ 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. +Triples that have search conditions may specify authority as matching criteria by populating `authorized-by`. + ~~~ cddl {::include cddl/measurement-map.cddl} ~~~ @@ -804,10 +809,12 @@ The following describes each member of the `measurement-map`: * `mval` (index 1): The measurements associated with the environment. Described in {{sec-comid-mval}}. -* `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. +* `authorized-by` (index 2): The cryptographic identity of the entity (individual or organization) that is + the designated authority for measurement Claims. + For example, the signer of a CoMID triple. See {{sec-crypto-keys}}. + An entity is authoritative when it makes Claims that are inside its area of +competence. ###### Measurement Keys {#sec-comid-mkey} @@ -1743,7 +1750,7 @@ If any of the `ars-additions` are not found in the ACS then these ACS entries ar | | `profile` | Optional | {: #tbl-ar-ect-optionality title="Attestation Results tuple requirements"} -### Internal Representation of ACS {#sec-ir-acs} +### Internal Representation of Appraisal Claims Set (ACS) {#sec-ir-acs} An ACS is a list of ECTs that describe an Attester's actual state. @@ -2000,46 +2007,28 @@ The handling of dynamic Evidence transformation algorithms is out of scope for t ## Evidence Augmentation (Phase 2) {#sec-phase2} -### Appraisal Claims Set Initialization {#sec-acs-initialization} +### Appraisal Claims Set (ACS) Initialization {#sec-acs-initialization} The ACS is initialized by copying the internal representation of Evidence claims to the ACS. See {{sec-add-to-acs}}. -#### The authorized-by field in Appraisal Claims Set {#sec-authorized-by} +#### The authority field in the ACS {#sec-authority} -The `a` field in an ECT in the ACS indicates the entity whose authority backs the claim. +The `authority` field in an ACS ECT indicates the entity whose authority backs the Claims. -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. +The Verifier keeps track of authority so that it can satisfy appraisal policy that specifies authority. -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 {{sec-crypto-validate-evidence}}. +When adding an Evidence entry to the ACS, the Verifier SHALL set the `authority` field using a `$crypto-keys-type-choice` representation of the entity that signed the Evidence. -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. +If multiple authorities approve the same Claim, for example if multiple key chains are available, then the `authority` field SHALL be set to include the `$crypto-keys-type-choice` representation for each key chain. -When adding Endorsement Claims to the ACS that resulted -from CoRIM processing ({{sec-add-to-acs}}) 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 adding Endorsement or Reference Values Claims to the ACS that resulted from CoRIM processing ({{sec-add-to-acs}}). +The Verifier SHALL set the `authority` field using a `$crypto-keys-type-choice` representation of the entity 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. +When searching the ACS for an entry which matches a triple condition containing an `authorized-by` field, the Verifier SHALL ignore ACS entries if none of the entries present in the condition `authorized-by` field are present in the ACS `authority` field. +The Verifier SHALL match ACS entries if all of the entries present in the condition `authorized-by` field are present in the ACS `authority` 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. - -#### Appraisal Claims Set augmentation using CoMID triples +#### ACS augmentation using CoMID triples In the ACS augmentation phase, a CoRIM Appraisal Context and an Evidence Appraisal Policy are used by the Verifier to find CoMID triples which match the ACS. Triples that specify an ACS matching condition will augment the ACS with Endorsements if the condition is met. @@ -2136,9 +2125,9 @@ Hence, the Verifier may need to maintain multiple Attestation Results contexts. An internal representation of Attestation Results as separate contexts ({{sec-ir-ars}}) 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. -## Adding to the Appraisal Claims Set {#sec-add-to-acs} +## Adding to the Appraisal Claims Set (ACS) {#sec-add-to-acs} -### Appraisal Claims Set Requirements {#sec-acs-reqs} +### ACS Processing Requirements {#sec-acs-reqs} At the end of the Evidence collection process Evidence has been converted into an internal represenetation suitable for appraisal. See {{sec-ir-cm}}. @@ -2146,61 +2135,33 @@ See {{sec-ir-cm}}. 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. -[^issue] https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/232 - -The ACS contains the actual state of Attester's Target Environments (TEs). -The `state-triples` field contains Evidence (from Attesters) and Endorsements -(e.g. from `endorsed-triple-record`). - -CoMID Reference Values will be matched against the ACS, as per -the appraisal policy of the Verifier. -This document describes an example evidence structure which can be easily -matched against these Reference Values. +ACS entries contain Evidence (from Attesters), corroborated Reference Values, and Endorsements. +The ACS SHALL contain the Attester's *actual state* as defined by its Target Environments (TEs). -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`. +Each ACS ECT entry SHALL contain `authority`. +See {{sec-authority}}. +There can be multiple entries in the ACS which have the same `environment-map` and a different authority. -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 ACS entry is an ECT Claim. +The ECT `environment` and `element-id` together define the Claim's name. +The ECT `element-claims` are the Claim's *actual state*. -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-map`s are merged. +This specification defines rules for determining when two Claim names are equivalent. +See {{sec-compare-environment}} and {{sec-compare-element-map}}. +Equivalence typically means values MUST be binary identical. -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 {{sec-authorized-by}}. +If two Claims have the same Claim name, the CoRIM triples instruct the Verifier on how these Claims are related. -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 multiple Claims have the same name and the measurement values (i.e., `measurement-values-map` codepoints and values) are equivalent, they are considered *duplicates*. +Duplicate claims SHOULD be omitted. -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. +If multiple Claims have the same name and `measurement-values-map` contains duplicate codepoints but the measurement values are not equivalent, then a Verifier SHALL report an error and stop validation processing. -### ACS Augmentation {#sec-acs-aug} +### ACS Augmentation Requirements {#sec-acs-aug} 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. +Nevertheless, implementations may optimize ECT order, to achieve better performance. Additions to the ACS MUST be atomic. ## Comparing a condition ECT against the ACS {#sec-match-condition-ect} From 27766e76f58b38ec5f7726c41051902026c74f8d Mon Sep 17 00:00:00 2001 From: Yogesh Deshpande Date: Mon, 21 Oct 2024 14:11:18 +0100 Subject: [PATCH 4/8] Fix broken reference Signed-off-by: Yogesh Deshpande --- draft-ietf-rats-corim.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft-ietf-rats-corim.md b/draft-ietf-rats-corim.md index e1c7dc14..d4db4631 100644 --- a/draft-ietf-rats-corim.md +++ b/draft-ietf-rats-corim.md @@ -114,7 +114,6 @@ informative: I-D.ietf-rats-eat: eat I-D.ietf-rats-concise-ta-stores: ta-store I-D.ietf-rats-ar4si: ar4si - I-D.ietf-rats-cobom: cobom entity: SELF: "RFCthis" @@ -1768,7 +1767,7 @@ An ARS is a list of ECTs that describe ACS entries that are selected for use as ## Input Validation and Transformation (Phase 1) {#sec-phase1} -During the initialization phase, the CoRIM Appraisal Context is loaded with various conceptual message inputs such as CoMID tags ({{sec-comid}}), CoSWID tags {{-coswid}}, CoBOM tags {{-cobom}}, and cryptographic validation key material (including raw public keys, root certificates, intermediate CA certificate chains), and Concise Trust Anchor Stores (CoTS) {{-ta-store}}. +During the initialization phase, the CoRIM Appraisal Context is loaded with various conceptual message inputs such as CoMID tags ({{sec-comid}}), CoSWID tags {{-coswid}}, CoBOM tags, and cryptographic validation key material (including raw public keys, root certificates, intermediate CA certificate chains), and Concise Trust Anchor Stores (CoTS) {{-ta-store}}. 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. From 69cb6fdf09c2cb88e714e49e5df1717c593ebadd Mon Sep 17 00:00:00 2001 From: Dionna Amalie Glaze Date: Wed, 23 Oct 2024 07:30:42 -0700 Subject: [PATCH 5/8] Allow signing untagged corim-map (#332) * Allow signing untagged corim-map There's no need to require the tag, and the veraison/corim package hasn't been tagging its payload. Signed-off-by: Dionna Glaze * Remove 'maybe' name --------- Signed-off-by: Dionna Glaze --- cddl/cose-sign1-corim.cddl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cddl/cose-sign1-corim.cddl b/cddl/cose-sign1-corim.cddl index cfa916e1..0e574015 100644 --- a/cddl/cose-sign1-corim.cddl +++ b/cddl/cose-sign1-corim.cddl @@ -1,6 +1,6 @@ COSE-Sign1-corim = [ protected: bstr .cbor protected-corim-header-map unprotected: unprotected-corim-header-map - payload: bstr .cbor tagged-corim-map + payload: bstr .cbor (tagged-corim-map / corim-map) signature: bstr ] From 5ad647371944a2ec254d7a6dc084679439d34ebb Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Wed, 23 Oct 2024 16:31:32 +0200 Subject: [PATCH 6/8] Update draft-ietf-rats-corim.md Co-authored-by: Dionna Amalie Glaze --- draft-ietf-rats-corim.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-corim.md b/draft-ietf-rats-corim.md index b2d890b6..7f2806f1 100644 --- a/draft-ietf-rats-corim.md +++ b/draft-ietf-rats-corim.md @@ -2025,7 +2025,7 @@ The `state-triples` field contains Evidence (from Attesters) and Endorsements 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 +This document describes an example evidence structure which can be matched against these Reference Values. Each entry within `state-triples` uses the syntax of `endorsed-triple-record`. From ac0b5dd1d8e16cb4bb7999fef8842babb95fd3c5 Mon Sep 17 00:00:00 2001 From: Yogesh Deshpande Date: Wed, 23 Oct 2024 15:35:28 +0100 Subject: [PATCH 7/8] Apply suggestions from code review Co-authored-by: Dionna Amalie Glaze --- draft-ietf-rats-corim.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-rats-corim.md b/draft-ietf-rats-corim.md index 7f2806f1..f4ed0149 100644 --- a/draft-ietf-rats-corim.md +++ b/draft-ietf-rats-corim.md @@ -2083,8 +2083,8 @@ This can be acheived by sorting the triples before processing, by repeating proc #### ACS Augmentation Requirements {#sec-acs-aug-req} 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. +Logically, the ACS represents the conjunction of all claims, so adding an ECT entry to the existing ACS at the end is equivalent to inserting it anywhere else. +Implementations may optimize ECT order to achieve better performance. Additions to the ACS MUST be atomic. ### Evidence Augmentation (Phase 2) {#sec-phase2} From 7e7ff12de841c739b2e57072769646403fb001ca Mon Sep 17 00:00:00 2001 From: nedmsmith Date: Wed, 23 Oct 2024 11:18:04 -0700 Subject: [PATCH 8/8] Update draft-ietf-rats-corim.md fix broken cross references --- draft-ietf-rats-corim.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-rats-corim.md b/draft-ietf-rats-corim.md index 9ad93f75..a119917c 100644 --- a/draft-ietf-rats-corim.md +++ b/draft-ietf-rats-corim.md @@ -2063,7 +2063,7 @@ and `authorized-by` then the `measurement-values-map`s 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 {{sec-authorized-by}}. +See {{sec-authority}}. If the merged `measurement-values-map` contains duplicate codepoints and the measurement values are equivalent, then duplicate claims SHOULD be omitted. @@ -2110,7 +2110,7 @@ When adding an Evidence entry to the ACS, the Verifier SHALL set the `authority` If multiple authorities approve the same Claim, for example if multiple key chains are available, then the `authority` field SHALL be set to include the `$crypto-keys-type-choice` representation for each key chain. -When adding Endorsement or Reference Values Claims to the ACS that resulted from CoRIM processing ({{sec-add-to-acs}}). +When adding Endorsement or Reference Values Claims to the ACS that resulted from CoRIM processing. The Verifier SHALL set the `authority` field using a `$crypto-keys-type-choice` representation of the entity that signed the CoRIM. When searching the ACS for an entry which matches a triple condition containing an `authorized-by` field, the Verifier SHALL ignore ACS entries if none of the entries present in the condition `authorized-by` field are present in the ACS `authority` field.