Numbers

[thomas-fossati]

@cabo has made a proposal for managing CBOR numbers in Internet-Drafts, which we should consider.

[nedmsmith]

This implies changing code point names from: &(mylabel: 0) => ... to: &(mylabel-CPA: -1) => ...

until the draft reaches RFC status then the labels would be changed to: &(mylabel: 0) => ...; or whatever is the right code point to be assigned.

I'm not sure it makes sense to do this for most of the base CoRIM structures as it is the prerogative of the base specification to use whatever code points it chooses. Additionally, there is a public TCG spec Endorsement Architecture for Devices that assigns code points to base spec map structures.

The Cabo proposal only makes sense for extensions to a base spec where the extensions intend to become part of a new base spec and therefore require positive integer code point values.

[nedmsmith]

One additional note regarding extensibility within the measurement-values-map structure. Here the use of code points is qualified by the environment-map where the entity that specifies the environment-map determines which measurement-values-map measurements are appropriate. Hence, if a vendor-A defines code-point values (-1, ..., -10) as pertaining to structures A - J, vendor-B could define code-point values (-1, ..., -10) as pertaining to structures Q - Z. Since the verifier knows that environments from a Vendor-A environment-map are different from a Vendor-B declared environment. The measurement code point assignments will be vendor-specific. Since the verifier relies on the vendor (Endorser/RVP) to supply it with correct RIMs, the CDDL for the measurement-values-map is assumed to be correct for the specified environment-maps.

[thomas-fossati]

The Cabo proposal only makes sense for extensions to a base spec where the extensions intend to become part of a new base spec and therefore require positive integer code point values.

I think it is a bit wider than that. ISTM that the intent is to cover for the time span until the registration is made by IANA, so the proposal applies to all the code-points that will eventually be registered -- either into a new or an existing registry.

It is also true that for CoRIM the backing TCG spec provides some level of stability that other protocols don't necessarily enjoy, and therefore it's less critical for us.

So, the conclusion seems to be: wontfix. Right?

[cabo]

I don't understand the negative number discussion (thanks for clarifying this), but I think if we get through with the "earmarking" you'll have a level of control over the number assignment within the earmark, so you don't need this (but you still need to coordinate within IETF, DICE, etc.).

I did ask for a change in the document in a separate message, though.

[nedmsmith]

We want the CoRIM spec to set the expectation that a negative code point. Add to IANA considerations section.