merge glossaries #389
merge glossaries #389
Conversation
Signed-off-by: Thomas Fossati <[email protected]>
thomas-fossati
requested review from
henkbirkholz,
yogeshbdeshpande and
nedmsmith
as code owners
thomas-fossati
requested review from
deeglaze,
steven-bellock and
andrew-draper
draft-ietf-rats-corim.md
Outdated
| See also ({{Section 2 of -rats-endorsements}}). | ||
|
|
||
| Appraisal Claims Set (ACS): | ||
| : A structure that holds ECTs that have been appraised. |
There was a problem hiding this comment.
| : A structure that holds ECTs that have been appraised. | |
| : A structure that holds ECTs ( for ECTs see below) that have been appraised. |
There was a problem hiding this comment.
If you look through the entries, this is not the only one.
There are constant references between the glossary entries, even 1:n.
|
And thanks for tidying this up! |
|
do we have reference to this glossary from first acronym use in the document?? |
good catch! I have expanded ECT in all the entries (except ECT :-)). |
| 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. |
There was a problem hiding this comment.
| : A description of the conditions that, if met, allow acceptance of Claims. | |
| : A description of the conditions that, if met, allow appraisal of Claims. |
There was a problem hiding this comment.
Acceptance is defined by the appraisal processing as defined in this spec. It isn't to be modified by profiles or policies. The wording could be misinterpreted to mean this, but could also be interpreted to mean the verifier selects which inputs are allowed based on policy.
| @@ -190,20 +226,25 @@ The term "Target Environment" refers to the group of system security metrics tha | |||
| The term "Attesting Environment" refers to the entity that collects and cryptographically signs such security metrics. | |||
| See also {{Section 3.1 of -rats-arch}}. | |||
|
|
|||
| 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. | |||
There was a problem hiding this comment.
| : 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. | |
| : A structure containing a set of values that typically describe a Target Environment plus a set of Measurement / Claim values that describe properties of the Target Environment. |
There was a problem hiding this comment.
ECTs can contain claims about keys which might not be terminology that is intuitive when keys are described. Target Object is more intuitive. Note that Environment-map includes object identifiers, UUID, UEID, ect. that typically identify objects. There isn't perfect naming for this so I think its OK as is, but adding "typically" helps avoid nuanced discussions.
There was a problem hiding this comment.
Agree: When Attest Key Triple introduces keys, ECT may also contain set of keys.
Co-authored-by: Ned Smith <[email protected]>
Co-authored-by: Ned Smith <[email protected]>
|
@deeglaze & @andrew-draper : Please review it on Monday,(24th Feb), we plan to submit it today! |
| 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 -rats-endorsements}}. | ||
|
|
||
| Reference Values: | ||
| : A set of values that represent the desired or undesired state of an Attester. |
There was a problem hiding this comment.
As per #394 (comment):
| : A set of values that represent the desired or undesired state of an Attester. | |
| : A set of values that represent possible states of an Attester. |
| : An identifier of an Environment that is unique to that Environment instance, such as the serial number of a hardware module. | ||
| See also {{Section 4.2.1 of -eat}}. | ||
| reference state: | ||
| : Claims that describe various alternative states of a Target Environment. |
There was a problem hiding this comment.
The definition of reference state seems confusing to me! Is it alternative state or rather the most correct state or golden state of a target environment?
| See also {{Section 4.2.1 of -eat}}. | ||
| reference state: | ||
| : Claims that describe various alternative states of a Target Environment. | ||
| Reference Values Claims typically describe various possible states due to versioning, manufacturing practices, or supplier configuration options. |
There was a problem hiding this comment.
| Reference Values Claims typically describe various possible states due to versioning, manufacturing practices, or supplier configuration options. | |
| Reference Values Claims typically describe various reference states from a target environment such as versioning, manufacturing practices, or supplier configuration options. |
Fix #385
Note: I've only merged §8.2 and left Table 1 as-is.