CoRIM simplification structure

[deeglaze]

We discussed in today's meeting that next time we will go over a PR or slides about simplification to CoRIM as a standard to a Core and some other bits.

Here's what I think ought to be addressed:

1. CoRIM is a closed CDDL without extension points.
2. All extensibility of representation and interpretation is relegated to the CoRIM profile.
3. Profiles for standard attestation technologies may choose to go through IETF standardization to allocate CBOR tags through IANA, but this is not required for profiles.
4. The CoRIM working group may define reference value types with "matching" semantics that can be reused by other profile definitions. This should help extend the composability of the initially standardized notions of reference values. The policy should be, but still at the WG's discretion, that reference values are not given privileged CBOR representation through tag allocation without being applicable to at least 2 standard profiles. The applicability of the generalization must be concrete to give clear motivation behind the representation and semantics.
5. The ACS discussion should not use CDDL because it confuses the conceptual with the serializable. It should use an ABNF to describe an algebra of claims and sets of claims. All reference value and endorsement types must have a defined operation to reflect into the algebra. Claims can be partially ordered in order to define simplification through subsumption. A set of claims must therefore contain pairwise incomparable claims. By defining this algebra, the standard may give a clear definition to word "match" for composition and reuse, but it does not limit what profiles are definable–it is merely scaffolding. The algebraic notion of Claim is extensible by any profile, but each type of Claim is defined and owned by the standard/profile that defines it.
6. A CoRIM either fails to "match" an accepted claim set, or it augments individual claims in the ACS with "authorized-by" tags.
7. Evidence Appraisal should be defined explicitly as an operation to translate an octet string into a claim set.

For all of this, we've boiled the representation down to profile * profile-defined octet string. The algebra is a communication tool for specifying the semantics for composable standardized profile components.

All of the schema that is specified in the current document can be interpreted as, "if your profile's representation structurally matches profiles defined in RFCs, then it must semantically mean the same". You can keep TPM, PSA, and DICE following the same schema if you'd like as a way to provide a baseline for expected expressiveness.

But by doing this, you need to have reserved indices for the standard to grow and safe regions that custom profiles are allowed to define themselves. For example, * $$corim-map-extension allows for anyone to define index 6 or higher, but that is not desirable unless this type really should be considered "closed" from the standards body's perspective. If it's open, then say 0-1000 and [2^31, 2^32) are reserved for the specification to allow for custom profiles to use small indices without giving up a value space for the standard.

The reserved indices should be assigned by IANA for each following RFC, but the core CoRIM spec defines the value space for standard extension.

Do folks find this reasonable?

[nedmsmith]

Verifier Theory of Operation v3.pdf describes a theory of operation that applies to the currently documented (in corim and other I-Ds or industry specs) conceptual messages that could be mapped to a Verifier internal representation. The theory of operation isn't exclusive to the objective of "simplifying" the CoRIM structure, but may inform that objective.

[nedmsmith]

you need to have reserved indices for the standard to grow and safe regions that custom profiles are allowed to define themselves

The corim design team as discussed (if not documented) the convention that code points in the positive integer range are reserved for specification defined allocation. Code points in the negative integer range are for profile specific use.

[deeglaze]

The description in the slides says that different verifiers can share partial ACSes, which makes me wonder if the CDDL that's used for explanation purposes only might actually be specifying an interchange format between verifiers? Can we say that's not the intention?

[nedmsmith]

the CDDL that's used for explanation purposes only might actually be specifying an interchange format between verifiers? Can we say that's not the intention?

The I-D already tries to say that there is an internal representation and that if we use CDDL to describe the internal representation, that it isn't for the purpose of defining an interchange format.

There has been a thread in the CCC related to conceptual message types and attestation results formats which focuses on interchange formats. The theory of operations mentions the concept so that it is understood that for a distributed Verifier architecture the verifiers need to agree on a common internal representation.

[henkbirkholz]

1. CoRIM is a closed CDDL without extension points.
2. All extensibility of representation and interpretation is relegated to the CoRIM profile.

I am trying to align these two requirements and this seems to break with any CDDL convention introduced in IETF specification text introduced in the recent past.

In order to enable profiles to the "core CoRIM spec" we will add CDDL extension points to the base CoRIM spec. How would you integrate IANA registrations for well-known extensions and create standardized global interoperability otherwise? It seems to me that I am missing a vital piece of concept here. What am I missing?

[henkbirkholz]

3. Profiles for standard attestation technologies may choose to go through IETF standardization to allocate CBOR tags through IANA, but this is not required for profiles.

You can always chose the way of custom extensions as long as they do not collide with IANA registered extensions. Okay

[henkbirkholz]

4. The CoRIM working group may define reference value types with "matching" semantics that can be reused by other profile definitions. This should help extend the composability of the initially standardized notions of reference values. The policy should be, but still at the WG's discretion, that reference values are not given privileged CBOR representation through tag allocation without being applicable to at least 2 standard profiles. The applicability of the generalization must be concrete to give clear motivation behind the representation and semantics.

I can follow define reference value types with "matching" semantics that can be reused by other profile definitions. This should help extend the composability of the initially standardized notions of reference values. Okay

CBOR tags are there to help and not to constrain. If you choose not to use CBOR tags, you must provide coherent CDDL or might fall back to very comprehensive and fool-proof English text (which I am not sure of that that is a thing). But CBOR tags should not be the only way to deal with CDDL defined CBOR structures. If that is what you mean, okay. I would not block CBOR tag allocation by forcing at least two profiles to use said tags. That seem to be violating POLS/POLA and I would strongly advise not to do that.

[henkbirkholz]

5. The ACS discussion should not use CDDL because it confuses the conceptual with the serializable. It should use an ABNF to describe an algebra of claims and sets of claims. All reference value and endorsement types must have a defined operation to reflect into the algebra. Claims can be partially ordered in order to define simplification through subsumption. A set of claims must therefore contain pairwise incomparable claims. By defining this algebra, the standard may give a clear definition to word "match" for composition and reuse, but it does not limit what profiles are definable–it is merely scaffolding. The algebraic notion of Claim is extensible by any profile, but each type of Claim is defined and owned by the standard/profile that defines it.

The ACS discussion should not use CDDL because it confuses the conceptual with the serializable is an interesting point. I think it is done so it is intuitive to the reader on the one hand. OTOH, it seem way off to suddenly use ABNF here. I do not know what the middle ground should look like. How about we stick with CDDL with for now (although it is not necessarily serialized in CBOR internally) and go to the CBOR WG with that questions after we agreed on the more pressing issue about the "core CoRIM spec" itself?

[henkbirkholz]

6. A CoRIM either fails to "match" an accepted claim set, or it augments individual claims in the ACS with "authorized-by" tags.

I think I might need more input for this, as an ACS (also a name we should revisit maybe, but that is not important now) is build based on the input of one or more CoRIMs, for examples via a CoMID's measurement-map acting as a condition to also add endorsed values. So, what does "CoRIM fails to match an ACS" mean?

[henkbirkholz]

7. Evidence Appraisal should be defined explicitly as an operation to translate an octet string into a claim set.

I think I might need more context to grasp what means. It could mean: Evidence Appraisal requires policy to compare bytes to create Attestation Result Claims. Does that match your thinking?

[henkbirkholz]

The description in the slides says that different verifiers can share partial ACSes, which makes me wonder if the CDDL that's used for explanation purposes only might actually be specifying an interchange format between verifiers? Can we say that's not the intention?

That is a really cool summary. It is yet more content, but I strongly suggest that we do not loose track of @deeglaze suggestion here.

[nedmsmith]

different verifiers can share partial ACSes

This implies the different verifiers must agree on a common representation of internal structures such as the ACS.

[deeglaze]

1. CoRIM is a closed CDDL without extension points.
2. All extensibility of representation and interpretation is relegated to the CoRIM profile.

I am trying to align these two requirements and this seems to break with any CDDL convention introduced in IETF specification text introduced in the recent past.

Which text would that be? I'm saying that CoRIM is an envelope for providing information to a Verifier, where information is interpreted according to the profile. This allows for maximum flexibility for the profile definer to use the envelope format. I should clarify that I still intend for the pair of profile and payload to be within a COSE_Sign1 envelope. With that, you have the absolute bare minimum for authentication, semantic interpretation, and information.

In order to enable profiles to the "core CoRIM spec" we will add CDDL extension points to the base CoRIM spec. How would you integrate IANA registrations for well-known extensions and create standardized global interoperability otherwise? It seems to me that I am missing a vital piece of concept here. What am I missing?

With the more open envelope type structure, the rest of the document could then start to stand as it currently is, but I have an issue with its presentation. I think every addition on the envelope should be justified with standard profiles that illustrate the concept, if not completely relegated to the profile spec that introduces the concept. The culmination of all the specs can be a supplemental appendix with references to the RFCs that define a concept.

If there are no uses, they should be relegated to an extension RFC for when they are used. Examples then become case studies. I'm not saying any specific piece of the spec is contrived, I'm saying a lot feels unjustified as generalizations over an unknown set of profiles.

When the spec says "base schema" it's talking about core profile elements that ought to be easily adopted by a Verifier's implementation of a profile that follows the core. The points about extensibility should be higher up in the document and stand out more typographically. I didn't now about the negative integer map extension convention, and I felt it was buried in section 3.2.1.

I find it hard to determine why some pieces are extensible while others aren't. That's maps and type choices. Why are some type choices are so spoiled for choice when the type is extensible for other profiles? Why use a closed map when you can use a struct?

For specific presentational choices, I'd recommend to

• move all the optional keys in an extensible map out of the initial CDDL and into their own sections as extensions of the $$MAP-NAME-extensions code point. This allows every addition to get specifically justified with prose to explain what concept it embodies, and how it solves a particular problem.
• pick one preferred alternative to present in the introduction of any $NAME-type-choice. Move the others to a Standard Extensions Library section.
• Even with the typographical convention of $ or $$ prefix, do say in prose that a particular type is extensible or not.

This keeps the spec more digestible and lets me know that this schema is more of a menu than a requirement. When there are large selections of optional representations, you're making life harder both for the Verifier implementors and the profile authors that don't know what representation to pick.

Closed types that don't make sense to me to stay closed:

• corim-locator-map: A uri is one way to reference something, but as I noted in another issue, we may want to reference specific UEFI variables like in the TCG PFP Rev 1.06 for the SP800-155 event's rimLocatorType.
• svn-type-choice: X or >=X aren't the only conditions an endorser may want to express.
• role-type-choice: Not actually closed, but a variable in a CDDL generic that is typographically confusing given the NAME-type-choice, $NAME-type-choice notational convention called out at the beginning of the document. Since no instantiation in the document uses a closed type, please change to the $NAME-type-choice naming for the generic variable.
• class-map: The class-id is allowed to be a tagged-bytes to encode something as its own notion of extension to class, so I'd say allow this map to be extensible. Again the vendor/model/layer/index options should be in their own section to introduce the concept they represent (clearly a DICE thing).

Required map keys that aren't justified as to why they're required:

• corim-map's id and tags keys are the only required pieces, but the type is extensible. What is the "tag" concept that makes it a requirement? Why does a RIM /require/ a document identity? Can the CoSWID and CoBOM type choices be left to a separate document or much farther down?
• entity-map's role

The spec should explain why any closed type is closed.

• ip-addr-type-choice: Supports ipv4 and ipv6. No other IP address standards exist today, and it's not vendor-extensible concept.
• mac-addr-type-choice: Similar to ip-addr.
• tagged-concise-rim-type-choice: Sort of obvious that an open type allows a corim to mean absolutely anything, but given the call to justify all types, this still should be explained.
• environment-map: This needs hard justification to stick to just the class/instance/group breakdown, since you severely limit what concepts express what environments you're describing. Every value is an extensible type (except class-map, which should be extensible), so just like class-map, why keep it closed? You could still recommend sticking to the existing concepts by giving ample examples of their use in the standard extension library sections.

Then there are types that aren't named -type-choice but are also required representational choice in a concept (actually I only see the one)

• tag-version-type: The optional version as the only other component and only as a uint makes different kinds of versioning schemes unusable. What is the property you need on the version type for its semantic interpretation? Can we spec a type choice required property like "has a partial order" or "has a total order"?
• version-map's version value is text only, but has an extensible scheme type?
• entity-map's reg-id uri type: so many extensible identity types elsewhere, but this is only a URI?

Types that I just don't understand the implied concept for

• tag-identity-map: Probably I'm just missing the concept explanation for this. $tag-id-type-choice is extensible but the text says it's a universally unique identifier. An extensible choice doesn't just mean different ways of representing a UUID. If you don't mean a UUID, then say an identifier type that should be universally unique. What is the purpose? The linked-tag-map concept is not well-justified.

I'll leave it at that for now.