-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Section restructuring #329
Changes from 1 commit
67ec31c
5ad6473
ac0b5dd
12de6be
7e7ff12
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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 | ||
henkbirkholz marked this conversation as resolved.
Show resolved
Hide resolved
|
||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And the mkey There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. refer issue #334 |
||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The order should not be important so long as additions are followed by triple processing that has a condition that could match it. We don’t want to impose other order dependencies unless you need to stratify triple processing more explicitly. Given that we’re defining a processing order for base triples, it should also be allowable for profiles to specify when their triples get processed if indeed order is important. Will they always be after the base triples, or can they be specified to happen at any time? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. refer to issue #335 |
||
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. | ||
yogeshbdeshpande marked this conversation as resolved.
Show resolved
Hide resolved
|
||
But implementations may optimize ECT order to achieve better performance. | ||
yogeshbdeshpande marked this conversation as resolved.
Show resolved
Hide resolved
|
||
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,26 +2143,26 @@ 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 | ||
|
||
Endorsers publish Endorsements using endorsement triples (see {{sec-comid-triple-endval}}), {{sec-comid-triple-cond-endors}}, and {{sec-comid-triple-cond-series}}) which are transformed ({{sec-end-trans}}) into an internal representation ({{sec-ir-end-val}}). | ||
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 | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CoMID reference value matching isn’t up to policy. We define it here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issue #336