Thomas’s review of §9 of draft-ietf-rats-corim-10

[thomas-fossati]

• §1.1.1: ACS definition reads: "A structure that holds Environment-Claim Tuples that have been appraised. The ACS contains Attester state that has been authorized by Verifier processing and Appraisal Policy" unclear what it means for "Verifier processing" to authorize attester state...

• §1.1.1: Appraisal Policy definition: "A description of the conditions that, if met, allow appraisal of Claims." what does "appraisal of claims" mean? Which claims?

• §1.1.1: ARS is defined but not used - drop it

• §1.1.1: Authority definition: "The entity asserting that a Claim is true." I don't think truth is important here, it's purely about asserting: "The entity asserting a given Claim"

§2 has deep links with §9 (authority, ACS, ...), this needs to be made more explicit. The content could be moved directly into Section 8.

• §2: this sentence: "In essence, if Evidence is not corroborated by an RVP's Claims, then the RVP's Claims are not included in the ACS. Please see Figure 1." makes no sense, also the pointer to the figure seems spurious.

• §2: this sentence: "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." 1. "consequently" is used inappropriately as there is no logical consequence from the preceding sentence. 2. unclear what does "Conceptual Message constraints" refer to?

• §2, last para: "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." the second sentence is unclear and unnecessary.

• §2.2, second para: "The internal representations of Conceptual Messages and ACS SHOULD satisfy the requirements in Table 1 for Verifier reconciliation and appraisal processing:" why SHOULD and not MUST?

• Table 1: "Description" column is vague, description of what?

• Table 1: "selection-addition tuples" comes out of the blue. can this be explained more plainly?

• §5.1.4.5: (measurements) Semantics of authorized-by are unclear therefore rather unusable: "designated authority for measurement Claims" is too generic to be useful. Is this something similar to EAT MC authority, i.e., related to software updates/installations?

• §5.1.4.5: re: authorized-by, it says: "For example, the signer of a CoMID triple". CoMID triples aren't signed! This is the only concrete example and it doesn't compute.

• §5.1.4.5: re: authorized-by, it says: "See Section 5.1.4.6." which defines the crypto-key-type-choice type. A bit out of the blue and withouth much context.

• §5.1.4.5: re: authorized-by, it says: "An entity is authoritative when it makes Claims that are inside its area of competence.". What is this supposed to mean?

• §5.1.9 and §5.1.10: "The existence of these keys is asserted in Evidence, Reference Values, or Endorsements." what does "assert" means in this context. also, those are quite different CMs, how does the "assertion" materialise in each CM?

• §5.1.9: "certificate path construction & verification" -- should be "building & validation" instead?

• §5.1.9 and §5.1.10: "The Verifier SHOULD verify keys contained in Device Identity triples." what does it mean to "verify keys"? If a normative SHOULD is what we want, we should also say under which conditions the SHOULD can be ignored. Maybe this is "expected to" instead? Would that depend on the nature of the key(s)?

• §5.1.9: "device identity challenges," what are they? can we provide an example? More generally, the entire sentence is unclear.

• §5.1.9 and §5.1.10: the prose on key restrictions is odd: does it only applies to the mentioned case? If not, make a more general statement and use the specific case as an example.

• §5.1.9: "Attester's Claim set" (also in §5.1.10) should be "Appraisal Claims Set (ACS)"

• §5.1.9: "Claims are asserted with the joint authority of the Endorser (CoRIM signer) and the Verifier." <- "[...] and the Verifier is not possible anymore.

• §5.1.9: re: environment. "[...] identify the target Evidence or Reference Value". unclear what that is supposed to mean

• §5.1.9: re: environment. "[...] condition used [...]" what does "condition" mean?

• §5.1.9: Semantics of authorized-by are also unclear: "list of [...] keys that identifies the authorities that asserted the key-list in the target Evidence or Reference Values." What does "assert" means in this context? What is "target Evidence"? What does "target [...] Reference Values" represent?

• §5.1.10: "path construction and validation" align with §5.1.9

• figure 1 is not referenced in §9. it is referenced in §2, quite enigmatically... remove that ref?

• §9: figure 1 is hanging in void, add some prose around it

• §9, second para: why is this sentence here? add "in the reminder of this section..." or something, to contextualise

• §9, second para: ARS is not used

• §9.1, first para: say which CMs are inputs and which are outputs

• §9.1, second para: consistency: s/Environment Claim/Environment-Claim/ (but see next)

• §9.1, second para: ECT is already introduced in §9

• §9.1, second para: maybe "The conceptual messages ... are broken down into individual elements, each of which is then transformed into an ECT."

• §9.1, second para: "external conceptual messages"? "external" doesn't seem to carry any relevant meaning, it should just be "Conceptual Messages"

ECT definition in the glossary "[...] values that describe a Target Environment" should be "[...] values that identify a Target Environment". Also, for verification keys, the identification is that of an attesting environment, isn't it?

• §9.1.1, first para: s/Environment-Claims Tuples/Environment-Claim Tuples/ (but see next)

• §9.1.1, first para: it's the n-th time this is expanded

• §9.1.1, first para: there are now 7 attributes. Just say "the following attributes" and avoid numbering

• §9.1.1, "trustees" is missing from the list

• §9.1.1, "environment" could just reference the glossary and the env-map description. The reference to mkey is confusing, we should remove it. the mention to domain-id could also removed (there is a related discussion on the aliasing between domain-type and environment-map: why is the indirection needed?)

• §9.1.1, "elements" we should define what we mean by that and refer to that definition here (see also "environment" which talks about mkey as "element identifier" without a frame of reference).

• §9.1.1, "elements" is a profiled measurements-map -- with the optional authorised-by removed and the other fields renamed.. this should be made clear because the renaming feels quite arbitrary and the aliases choice is confusing. could we call it instead abbreviated-measurement-map or similar?

• §9.1.1, "authority" cumbersome...but probably ok

• §9.1.1, "members" should also include DDT I believe

• §9.1.1, "cm-type" doesn't apply to domain-member and trustee, since those are not CMs in the first place

• §9.1.1, "profile" is it always the embedding corim's profile or can it be evidence's also?

• §9.1.1, in general, I suggest we deal with ECT similar to what we do for other data model items definitions: CDDL and associated description of the fields.

elements seem to correspond to EAT MC "objects" -- should we align terminology?

• §9.1.1: ECT is a kitchen sink. in particular, DDT and DMT stretch its semantics to the limits (i.e., CM types, elements, make no sense in that context. Conversely, trustee, domain-members have zero meaning in the context of of real CMs's ECTs. we should distinguish domain-related ECTs from CM-related ECTs.

• §9.1.2: this information should be in 9.1.1 alongside the related fields description

• §9.1.3.1: reflow the description: "Attestation Evidence is represented using the ae relation as a collection of ECTs extracted/transformed from the to-be-appraised Evidence."

• §9.1.3.1: also, "relation" seems like a term of art whose definition needs to be clearly understood. in the ae context what is the relation? what are the objects that are related?

• §9.1.3.1: "The addition is a list of ECTs with Evidence to be appraised." => "The addition is a list of ECTs with Evidence Claims to be appraised."

• §9.1.3.1: "A Verifier may maintain multiple simultaneous sessions to different Attesters. [...]:" not clear why this (a general observation on the ACS) is "hidden" here (a specific description of evidence

• §9.1 (general): the internal representation data items could be prefixed with intrep- or similar + could be given more meaningful names than (ambiguous) acronyms -- e.g., ae coudl be expand to "attesting environment" ...

• §9.1.3.1: unclear what "Evidence tuple" refers to.

• Table 3: "ECT Type" in the heading is used but not introduced anywhere. IIUC, ECT "types" are condition, selection, addition. This should be introduced in §9.1

• Table 3: cmtype is not just mandatory, it's evidence, we should say that. Even better we should describe what the profiled ECT for evidence looks like in CDDL:

ECT-evidence = {
  environment: environment-map
  element-list: [ + element-map ]
  authority: [ + $crypto-key-type-choice ]
  cmtype: &(evidence: 2)
  ? profile: $profile-type-choice
}

• §9.1.3.2 "Evidence is transformed from an external representation to an internal representation as specified in Section ...". "as specified in" seems to refer to the transformation, but it instead it refers to the internal representation. Rephrase for clarity, e.g.: "Evidence is transformed using a suitable evidence transformation algorithm into the internal representaion described in Section ...""

• §9.1.3.2: "If the Evidence does not have a value for the mandatory ae fields, the Verifier MUST NOT process the Evidence." => "if any of the ECTs obtained from the transformation of evidence doesn't have all the mandatory fields populated => abort appraisal"

• §9.1.3.2: "The handling of Evidence transformation algorithms is out of scope for this document." unsure what "the handling of" refers to.

• §9.1.3.2: add ref to rats-evidence-trans spec (as an example of well-known)

• §9.1.3.2: "[...] or supplied dynamically" unclear what "supplied dynamically" refers to

• §9.1.3.2 (fix hardcoded ref to Section 4.14)

• §9.1.4: remove useless "Upon processing of CoRIMs containing Reference Value Triples, the RV Triples are transformed to an internal representation."

• §9.1.4.1: maybe start with "When CoRIMs containing reference value triples are processed, the triples are transformed into an internal representation using rv

• §9.1.4.1: "which is a list of ECTs that contains possible states and a list of ECTs that contain actual states asserted with RVP authority." is not an accurate description of the rv "relation" data item.

• §9.1.4.1: why is rv condition-addition? also, "actual state" coming from RVs seems inappropriate (or at the very list artificial)? It should say that the actual state (addition) part starts empty, and only when "corroborated" the actual state is populated with the matching "elements"

• §9.1.4.1: "possible state" should be "reference state" to align with rats-endorsements and §1.1 Terminology: "This document uses the terms "actual state" and "reference state" as defined in Section 2 of [I-D.ietf-rats-endorsements]."

• Table 4: in the condition ECT, shoud cmtype==evidence ? (note: profile is a bit pesky to match...)

• Table 4: "Reference Values tuple" what "tuple" is this referring to?

• §9.1.4.2 is a bit borked:

0. define input and output upfront with names and types
1. the "rv list entry is allocated" should be given a name that can be used
2. Step 3: rv (type) is used as a name for the list entry (which is another, anonymous, type)
3. Step 3: element-map and measurement-map can't be copied as-is because they are different types: It should be:

FOREACH e IN rvt.ref-claims:
    em := NEW(element-map)
    IF e.mkey {
        COPY(e.mkey, em.element-id)
    }
    COPY(e.mval, em.element-claims)
    rv-list-entry.condition.element-list.APPEND(em)

• §9.1.4.2 as well as all the other transformations apart from the key triples and CES triple seems to ignore authorized-by is there any reason?

• §9.1.5, title: it's a mouthful. s/Endorsed Value Triple, Conditional Endorsement Triple & Conditional Endorsement Series Triples/Endorsed Values/ and then in the body say what we mean by "Endorsed Values". Also, perhaps it's also a misnomer because it's only about the internal representation rather than generic "processing"

• §9.1.5.1: "the additions that are added" ... proposed reflow: "The internal representation of Endorsed Values uses the ev and evs relations, which are lists of ECTs that describe the matching conditions and additions if these conditions are met. The ev relation applies to Endorsed Values (EV) and Conditional Endorsement (CE) triples. The evs relation applies to Conditional Endorsement Series (CES) Triples."

• §9.1.5.1: "Note, when ev relation is for EV Triple, then the element-list inside condition is Optional while it is Mandatory for CE Triple." why optional? it should be empty since EV triples have a simple environment, not a stateful environment.

• Table 5: condition element-list Mandatory is wrong

• Table 5: addition cmtype MUST be endorsement

• §9.1.5.2: remove unnecessary nesting

• §9.1.5.2.1: the algorithm seem to describe a single triple transformation

• §9.1.5.2.1: Step 3.ii is not entirely correct (type mismatch)

• §9.1.5.2.2: the algorithm seem to describe a single triple transformation

• §9.1.5.2.2: Steps 3.{i,ii} are not entirely correct (type mismatch)

• §9.1.5.2.3: ditto

• §9.1.6: state clearly that keys are treated as endorsements => they are mapped into ev

• §9.1.6.2: title "Key Verification Triples Transformation" misleading "Key Verification Triples" are undefined

• §9.1.6.2, Step 3.ii: keylist should be key-list

• §9.1.6.2, Step 3.ii: the key should be appended to the intrep-keys not copied

• §9.1.6.2, Step 3.iii and Step 3.iv should be under Step 3.ii

• §9.1.6.2, Step 4: "Identity or Attest Key Endorsement conceptual message" <- those are not conceptual messages

• §9.1.7.1: I like the use of groups (we should use the same in the other intreps)

• §9.1.7.1: if "Domain Membership is expressed in a single ECT" what's the reason for multiplicity in dm ? Is it per-triple?

• §9.1.7.1: definition is unclear. isn't this similar to DDT def in §9.1.8.1?

• §9.1.7.2, Step 2.i: it's not a copy, it's an assign

• §9.1.7.2, Step 3.i: it's not a copy, it's an assign

• §9.1.7.2, Step 4.ii: unclear what DMT.members[e] means. Also COPY doesn't look appropriate: Should it be "APPEND(e, domain.members)" instead

• §9.1.8: typo: "ECT trustees list" => "ECT trustees list"

• §9.1.8: "The cmtype is inclusive of trustee", it's confusing because cmtype is not cumulative. Maybe simplify to "The cmtype is set to trustee"

• §9.1.8, Step 5.i: unclear what dde.trustees[e] means. Also COPY doesn't look appropriate: Should it be "APPEND(e, dde.trustees)" instead

• §9.1.8: missing check: the graph MUST have no cycles and is directed (this is probably also true for the DMT graph)

• §9.2: "After context initialization, additional inputs are held back until appraisal processing has completed." unclear which "additional inputs" is this referring to?

• §9.2.1.1: it says: "revoked by an authorized source." but what is the CoRIM revocation method this alludes to is unclear

• §9.2.1.1: it says: "Any CoRIM that has been secured by a cryptographic mechanism that fails validation MUST be discarded. An example of such a mechanism is a digital signature." what other examples exist? This can be rewritten more straightforwardly as: "If a CoRIM is digitally signed and the signature cannot be verified, it MUST be discarded."

• §9.2.1.2: this can be merged into the part of 9.2.1.1 that talks about crypto protection and authorized sources

• §9.2.1.4: this should be before 9.2.1.3 because it directly influences the way "the verifier chooses tags from the selected CoRIMs"

• §9.2.2: "Discovery of Evidence sources is untrusted. Verifiers may rely on conveyance protocol specific context to identify an Evidence source, which is the Evidence input oracle for appraisal." unsure what this is supposed to mean. In general evidence can be collected by relying party and forwarded to the verifier, or collected by the verifier directly from the attester via API exposed by the attester (background check), or submitted by the attester to the verifier via verifier provided API (passport). I suggest either dropping it or replacing it with something less nebulous.

• §9.2.2.1: no need to sub-section this. suggest merging it with the parent section.

• §9.2.2.1, second para: add ref to UCCS sec-cons

• §9.2.2.1: would benefit from some simple editorial work, but it's otherwise quite good.

• §9.2.2.1: "Once Evidence is validated it is transformed into an internal representation as given in Section 9.1.3." can be dropped: the next section is literally "Input Transformations"

• §9.2.3: drop ", or Policies"

• §9.2.3: "as given below. See Section 9.2.4" drop and merge with 9.2.3.1

• §9.2.4: title: "Internal Representation of Appraisal Claims Set (ACS)" is confusing since there is no external repr of ACS

• §9.2.4: unclear why this is its own section rather than being part of §9.2.3

• §9.2.4: it looks like a fragment rather than a cohesive piece of info. maybe it could go somewhere else, not sure, but as-is it doesn't look right

• §9.2.4: typo: "Table Table 8"

• §9.2.4, Table 8: ECT type should be "all" rather than "n/a" -- alt. the column could be dropped altogether

• §9.3: "[...] CoRIM Appraisal Context and an Evidence Appraisal Policy are used by the Verifier to find CoMID triples which match the ACS". I have a few issues with this sentence:

  1. "Evidence Appraisal Policy" == "Appraisal Policy for Evidence"? (if so, no need to use new terms)
  2. I don't think Appraisal Policy should be part of the phases 2,3,4

• §9.3: "Triples that specify an ACS matching condition will augment the ACS with Endorsements if the condition is met." I don't think this is the case for reference value triples.

• §9.3, second para: first and second sentence don't seem to be correlated (However?)

• §9.3, second para: third sentence: "If a triple condition does not match, then the Verifier continues to process other triples." this is true also if the condition match though...

• §9.3.1: there is no new information here. drop it?

• §9.3.1.1: "The ACS contains Evidence ECTs (from Attesters) and Endorsement ECTs (e.g. from endorsed-triple-record)." and not reference values?

• §9.3.1.1: "CoMID Reference Values will be matched against the ACS following the comparison rules in Section 9.4." this reads like a stray sentence.

• §9.3.1.1: third para: "Each Endorsement ECT contains the environment and internal representation of measurement-maps as extracted from an endorsed-triple-record. When an endorsed-triple-record is transformed to Endorsements ECTs 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." is incomprehensible.

• §9.3.1.1: fifth para: "Each Claim is encoded as an ECT. The environment-map, the mkey or element-id, 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." doesn't apply to key- and domain-related claims

• §9.3.1.1: seventh para: "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." unclear what these two sentences mean

• §9.3.1.1: general comment: there are only three requirements in a section with title "ACS Processing Requirements". What is the rest of it doing?

• §9.3.1.1: "If Evidence or Endorsements from different sources has the same environment-map and authorized-by then the measurement-values-maps are merged." unclear what this refers to

• §9.3.1.1: what is a "state-triple" ?

• §9.3.1.1: last two paragraphs talk about "merged measurement-values-map" but it's not clear "merging" works

• §9.3.1.1.1: why is this its own subsection? Can it be merged with the parent section?

• §9.3.1.1.1: "Triples interface with the ACS" they don't: the internalised ECT does.

• §9.3.1.1.1: "Most triples use an environment-map field to select the ACS entries to match ..." most? what are the exceptions?

• §9.1 (general): the shape of ae

ae = [
  addition: [ + ECT ]
]

is different from rv

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

should instead be:

ae = [ + {
  addition: ECT
} ]

however, endorsed values relations

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

look more like evidence (which sort-a makes sense)
however, should that be wrapped in an (anonymous) object? like

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

• §9.4.6. typo in title: Measurement values map map Comparison

cross check Sergei's review https://github.com//issues/506

we need to clarify the semantics of 1-to-n triples in matching. and (related) to evidence ingestion and transformation. is 1-to-n just compression, or does it carry matching semantics (i.e., the "sibling" measurements need to be matched en-bloc?)