[Rats] draft-birkholz-rats-corim-02 review

[Carl Wallace <[e-mail]>]

I know this is not yet a working group draft, but since working group adoption post-recharter seemed likely based on last IETF session, I sent the review here. I read this in tandem with draft-fdb-rats-psa-endorsements as suggested.

General
- COSE references point to RFC7231 throughout and should point to RFC8152.
- Would CoMID work better in standalone spec (or at least a more prominent section and separate schema in this doc)?
- The phrase "This rule and its constraints MUST be followed when generating or validating a XXX" appears often. What does validating mean here and what is the rule? There's not much in the way of prose describing how to process values, so it seems like "validating" may mean parsing and the "rule" is the schema snip each section with these words. Maybe substitute parsing for validating or just drop these statements if this is correct as adhering to schema definitions can be assumed.

Section 1
- The last paragraph states the draft defines a "Concise Manifest Revocation" but the concept of revocation does not appear later in the draft. Is this referencing the comid.replaces or something different (or not yet written)?

Section 2
- Change singed to signed and change temper-evidence to tamper-evidence.
- CoMID is said to be an extension to CoSWID but in the schema appears as an alternative to CoSWID. None of the CoSWID sockets are extended here. What parts extend CoSWID? 
- In the third paragraph, should "must be signed" be "MUST be signed"?

Section 3.1
- The definition of COSE-Sign1-corim here does not match the one in the schema. Neither header map defined in this section appears in the schema.
- Section 3.1.1 should include some words re: corim.signature-validity relationship to public key validity and maybe mention the potential for revocation. Ditto relationship to rim-validity later in the draft.

Section 3.2
- Why limit the MUST to unsigned?
- It may be worth stating whether rim-validity should be < signature-validity or if wholly independent.
- Why are "dependent-rims" said to be "possibly dependent"? What does dependent mean here?
- Must the dependent-rims (and their dependent-rims) all be processed and verified to satisfy the MUST statement re: validation? How would loops be handled? Must processing fail if a corim-locator-map thumbprint is different from calculated value (even if it verifies)? Why use a hash (i.e., suppose something in unprotected changes)? Is the $concise-reference-integrity-manifest-type-choice the expected type when retrieving a dependent RIM or should it be signed-corim only? What would "other associated resources" be?
- Is a corim-profile only necessary where the profile extends CoRIM or is this expected to be generally used?
- Same comment re: rim-validity as for signature validity.
- What relationship should be expected between corim.entities and corim.signer in the corim-meta-map and the kid in the COSE layer?
- What is expected to be in the bytes for oid-type: DER encoded with tag and length, DER without tag and length, something else?
- The opening paragraph for 3.2.1 seems misplaced. The section provides info about an entity, not origin and purpose.
- In 3.2.2, is the data downloaded assumed to be a CoRIM (as the name implies) or is it any file or record (as the text suggests)?

Section 3.4
- How does the identity-map enable one to "anticipate required capabilities"? 
- It may be worth adding some words that the tag ID type is the same as CoSWID (despite use of different type aliases in the respective definitions).

Section 3.5
- Some words describing each of the three roles would be helpful, for example, describe the difference between tag-creator and creator.

Section 3.6
- Are the linked tags expected to be in the same CoRIM? If so, why would one supplement or replace a tag with a sibling tag instead of just using the value from the linked tag directly? If not, where would they be and how is this envisioned to work?
- Where replacement is used and if in same CoRIM, ought some fields (as defined in 3.3) be required to be absent (i.e., why express what may be verbose triples that are OBE)?

Section 3.7
- Should there be some language to prohibit the same environment from appearing more than one time in a triple list? The psa-endorsement profile states a "single reference-triple-record SHALL completely describe the updatable PSA RoT". Ought this requirement go in the CoRIM spec instead?
- I am curious what it means for this spec that the first profile of it wound up defining several new extension structures. It makes sense that the certification claims in the PSA profile would be unique to that profile, but the need to extend class-id-type-choice, measured-element-type-choice and triples-map-extension may suggest the mechanisms in this spec are not sufficiently general purpose.

Section 3.11
- When would the key material not be a public key? How would verifier know? It seems like this field may need something to indicate type of key, i.e., to inform how to parse the DER encoded blob. In absence of a type, SubjectPublicKeyInfo seems like the right structure, but not if this may not convey a public key.
- I suggest adding "with the last certificate verified by a trust anchor" to the end of the comid.keychain text.
- Why require base64 for certificates instead of binary DER-encoded?

Section 4
- corim-map does not appear in the schema. Are both corim-map and unsigned-corim-map needed?
- Adding a comment to restrict language-type to the IANA language tag set would be nice (to echo the restriction on the field where the type is used in 3.3). Or maybe just drop the language-type type a la CoSWID.
- Why is the full CoSWID schema present here? I think the only structure referenced is concise-swid-tag. If it must be here, it would be nice to keep all comments from CoSWID schema and denote the start and stop of the copy and paste with comments.