CoRIM Meeting 09-11-2024

[thomas-fossati]

Actions:

• Thomas: review Section 8.3 to 8.6
• Ned: write Section 8.7 - 8.9 "conclusions" - collapse into one section
• Andy: propose text for 8.11
• Andy and Ned to review 8.10

[thomas-fossati]

Thomas's review

S8.3

• S8.3: what was initially (https://github.com/ietf-rats-wg/draft-ietf-rats-corim/wiki/Notes-on-the-appraisal-flow) “Appraisal Context Iniitlialization” has been renamed to "Input Validation and Transformation” but some of the original terms are still here, which creates confusion. Then in S8.3.3.1 the term “appraisal context” re-surfaces. Maybe we should go back and call Phase 1 “Appraisal Context Initialization”?
  [nms] Agree.

• S8.3: “[i]s loaded with various conceptual message inputs” <- are these the raw tags or the transformed?
  [nms] It assumes the raw inputs have been authenticated and transformed already.

• Subsequent S8.3.3.1 implies the latter.z
  [nms] maybe the introductory paragraph should highlight the need to authenticate and transform the various input forms into an internal representation? The "Appraisal Context" is realized as an internal representation.

• S8.3.2 “Evidence Collection” appears in the middle of S8.3 without being announced - especially at the beginning of S8.3. In S8.1, when describing Phase 1, it is probably implicitly included in the CM inputs bucket, but it should be made clearer.
  [nms] Agree. Maybe move §8.2.3 to §8.3.1 and call it "CM Collection" which includes evidence collection. The current §8.3 intro seems to describe CM Collection sans evidence collection. Maybe some of these words could be moved into the new 8.3.1?

• S8.3.1.2 crates unwarranted nesting. It can be merged with the text above.
  [nms] The line "The Verifier chooses tags from the selected CoRIMs - including CoMID, CoSWID, CoBOM, and CoTS." can be moved into §8.3.1.1, but the rest of the text is describing CoMID and CoSWID extraction. Maybe change the heading to "CoMID and CoSWID Extraction"? Possibly add a line to §8.3.1.1 that says "See [CoTS] (https://...) for details regarding CoTS extraction."?

• S8.3.1: the title is both too generic (“input” instead of “CoRIM”) and misleading (“validation” instead of “collection”). We could call it “CoRIM Collection”
  [nms] OK
  and get rid of the nesting introduced by S8.3.1.1.
  This would also create symmetry with the following “Evidence Collection”.
  [nms] Consider my suggestions above.

• S8.3.2. "During the Evidence collection phase” <- it is not an explicit phase.
  R/During the Evidence collection phase/During phase 1/

• S8.3.2: “which is the Evidence input oracle for appraisal” <- it is unclear what this piece adds. suggest removal.
  [nms] OK.

• S8.3.2: It is not clear what part of this section is in scope: ISTM that only the “transformation” part is, which is already covered in S8.3.3. Should we remove it?
  [nms] §8.3.1.2 is conflating tag extraction topic with cryptographic validation topic. §8.3.2.1 shouldn't move to §8.3.1 with "Evidence Collection", but rather should be repurposed as a CM Validation section. Maybe some of the wordiness can be minized?

• S8.3.2.1: s/“depends on the specific Evidence collection method used.”/“may vary”.
  [nms] Agree.

• S8.3.3: remove Policies, they are not in scope
  [nms] Maybe that's OK. Policies could be applied at multiple points across the phases, so that seems to explode the text if we were to do it right.

• S8.3.3.3: unclear text:

• “Evidence is divided up into one or more ev relations”
  [nms] The first two paragraphs in §8.3.3.3 describe ACS initialization. Maybe it makes sense to move it up to follow §8.3.3.1 or combine with §8.3.3.1 which describes both Appraisal Context and ACS initialization? The wording should capture the idea that there is an ACS for each source of evidence.

• “If the Verifier maintains multiple Attester sessions, the Verifier session may be identified using an ECT.”
  [nms] This is trying to say that there is an ACS for each source of evidence.

S8.4 and S8.5

• S8.4.1.1: “authorized-by” is a misnomer, there is no authorization in the RFC4949 sense. Should be “authority”
  [nms] Agree. Title should be "The Authority Field in ACS".
• S8.4.1.1: “at the head of each key chain which signed that Evidence.”<- unclear what is meant by “head”?
  [nms] I think I disagree with the text. The text suggests for a given signature over a CM object (rim, evidence) to record the root of trust / CA key rather than the direct signing key. I think this isn't right. It should record the direct signing key (and optionally? to path constriction to resolve to a CA). The full path is actually the authority.
• S8.4.1.1: “ This key is often the subject of a self-signed certificate” <- unusual definition. I guess “trust anchor” is what is intended here
  [nms] See previous comment.
• S8.4.1.1.: “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.” <- why is it presented at this level of detail? Isn’t this part of the matching rules? “is part of the matching criteria” should be enough at this level.
  [nms] Yes. The condition matching section should describe how to do authority matching then this paragraph can be removed.
• S8.4.1.1: “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” <- unclear what the requirement is.
  [nms] It is saying the external representation of authority should be mapped to an internal representation of authority so that there is consistency within the internal representation. Possibly, this text can be removed since we're rewriting the sections on external to internal mapping or this paragraph is the placeholder for that rewrite?
• S8.4.1.2: “However, the ACS state may change as a result of processing a triple” <- remove “However”. It seems that the augmentation is the expected result rather than an exception.
  [nms] OK.
• S8.4.1.3: As you already know, allowing the matching context to be READ|WRITE and not READ only is problematic.
  [nms] We need to describe quantization of inputs, possibly this belongs in the CM Initialization section(s)? The idea is that inputs are staged based on some quantum that is out of scope for this spec. All processing logic the follows occurs within that quantum. That way we avoid the READ/WRITE inconsistency problem.
• S8.5: “If any reference-triple-record in the Reference Value triple does not match the ACS then the entire triple is ignored.” <- unclear what the difference between rv-triple-record and Reference Value triple is.
  [nms] The version of the document I'm looking at says: "If any reference-triple-record in the Reference Value triple does not match the ACS then the entire triple is ignored." This seems like a reasonable statement. But it also seems redundant given the previous paragraph.

[thomas-fossati]

@nedmsmith @andrew-draper @henkbirkholz @deeglaze @yogeshbdeshpande ⬆️ for discussion