make instance claims a special case of class claims

[thomas-fossati]

This is a proposal to move away from top-level instance types and have them subsumed by their class-scoped siblings (i.e., reference- and endorsed- claims). The trick is to extend element-names to also allow per-instance granularity.

Related to #57 and a somewhat natural evolution of the work done in #53 and #51

[nedmsmith]

I don't think it makes sense to merge the instance-value-group-choice with element-value-group as this removes the primary objective of segmenting based on class vs. instance. I also don't think it makes sense to combine (authenticatable) identity claims with other claims. We need the CDDL to encode the class/instance semantics or we should add a flag variable (which was the original proposal). I prefer encoding the semantics in CDDL however. I will make a CDDL proposal that does some of what is captured in #60 but doesn't loose the class/instance encoding.

[nedmsmith]

Information model diagram

claims-map = non-empty<{
  ? comid.reference-claims => one-or-more<reference-claim-map>
  ? comid.endorsed-claims => one-or-more<endorsed-claim-map>
  ? comid.identity-claims => one-or-more<identity-claim-map>
  * $$claims-map-extension
}>

deleted: ? comid.reference-instance-claims => one-or-more ? comid.endorsed-instance-claims => one-or-more

endorsed-claim-map = non-empty<{
  ? comid.element-name => element-name-map  /' could be element-name-group to be consistent with element-value-group '/
    class-or-instance-claims-group
}>

reference-claim-map = {
 ? comid.element-name => element-name-map /' could be element-name-group to be consistent? '/
    class-or-instance-claims-group
}

class-or-instance-claims-group = (
  ? comid.class-claims => class-claims-map 
  ? comid.instance-claims => instance-claims-map
)

class-claims-map = non-empty<{
     element-value-group
  * $$class-claims-map-extension
}>

instance-claims-map = non-empty<{
     element-value-group
  ? $$instance-value-group-choice
  * $$instance-claims-map-extension
}>

Note that the encoding of whether the data are instance or class is in the CDDL when the class-claims-map or instance-claims-map is the chosen encoding.

This doesn't mix instance-value-group-choice with claims that are encoded as class info.

[yogeshbdeshpande]

Information model diagram

claims-map = non-empty<{
  ? comid.reference-claims => one-or-more<reference-claim-map>
  ? comid.endorsed-claims => one-or-more<endorsed-claim-map>
  ? comid.identity-claims => one-or-more<identity-claim-map>
  * $$claims-map-extension
}>

deleted: ? comid.reference-instance-claims => one-or-more ? comid.endorsed-instance-claims => one-or-more

endorsed-claim-map = non-empty<{
  ? comid.element-name => element-name-map  /' could be element-name-group to be consistent with element-value-group '/
    class-or-instance-claims-group
}>

reference-claim-map = {
 ? comid.element-name => element-name-map /' could be element-name-group to be consistent? '/
    class-or-instance-claims-group
}

class-or-instance-claims-group = (
  ? comid.class-claims => class-claims-map 
  ? comid.instance-claims => instance-claims-map
)

class-claims-map = non-empty<{
     element-value-group
  * $$class-claims-map-extension
}>

instance-claims-map = non-empty<{
     element-value-group
  ? $$instance-value-group-choice
  * $$instance-claims-map-extension
}>

Note that the encoding of whether the data are instance or class is in the CDDL when the class-claims-map or instance-claims-map is the chosen encoding.

This doesn't mix instance-value-group-choice with claims that are encoded as class info.

Yogesh:

This looks more aligned with the principles of keeping instance claims different from class claims.

One comment: Inside reference-claim-map and endorsed-claim-map, comid.element-name could be replaced by class-or-instance-id-group.

Then any specific identifiers for instance like: ? comid.device-id => $device-id-type-choice can be properly modelled.

[thomas-fossati]

Information model diagram

👍

claims-map = non-empty<{
  ? comid.reference-claims => one-or-more<reference-claim-map>
  ? comid.endorsed-claims => one-or-more<endorsed-claim-map>
  ? comid.identity-claims => one-or-more<identity-claim-map>
  * $$claims-map-extension
}>

deleted: ? comid.reference-instance-claims => one-or-more ? comid.endorsed-instance-claims => one-or-more

👍

endorsed-claim-map = non-empty<{
  ? comid.element-name => element-name-map  /' could be element-name-group to be consistent with element-value-group '/
    class-or-instance-claims-group
}>

reference-claim-map = {
 ? comid.element-name => element-name-map /' could be element-name-group to be consistent? '/
    class-or-instance-claims-group
}

class-or-instance-claims-group = (
  ? comid.class-claims => class-claims-map 
  ? comid.instance-claims => instance-claims-map
)

There appears to be a missing // to create the "alternative" semantics -- also why are they both optional?

Maybe what you meant is:

   class-or-instance-claims-group //= ( comid.class-claims => class-claims-map )
   class-or-instance-claims-group //= ( comid.instance-claims => instance-claims-map )

? NMS> Yes maybe that is what I meant.

class-claims-map = non-empty<{
     element-value-group
  * $$class-claims-map-extension
}>

instance-claims-map = non-empty<{
     element-value-group
  ? $$instance-value-group-choice
  * $$instance-claims-map-extension
}>

1. keeping these two extensible code-point spaces adjacent complicates the IANA allocation because it makes the two registries interrelated (they need to be aware of each other actual and pending allocations) NMS> Is this referring to the lack of expressiveness in CDDL or something else?

   ? $$instance-value-group-choice
   * $$instance-claims-map-extension

2. It is not clear how we can use this model to convey measurements that are associated to an instance? NMS> Are you saying the extension point can't be extended with information that isn't instance info?

Note that the encoding of whether the data are instance or class is in the CDDL when the class-claims-map or instance-claims-map is the chosen encoding.

This doesn't mix instance-value-group-choice with claims that are encoded as class info.

I am still failing to understand the need to create the splitting. To me the scoping is not inherent in the kind of attributes (at least for most of the cases), it's rather a local decision that can be conveyed using an element-name with class[:instance] identifiers.

NMS> Are you suggesting that for each attribute (e.g. Mac-addr-type-choice) there should be a [:instance] qualifier? My thought was the added layer of nesting (e.g. class-claims-map / instance-claims-map) would provide the qualifier for the set of attributes, all of which have instance / class semantics. If a single attribute is instance data then there would be a single attribute in instance-claims-map.

[nedmsmith]

See comments inline. It seems there is general agreement but disagreement about how extensibility for instance claims should work (due to the way CDDL represents name spaces).

[thomas-fossati]

See comments inline. It seems there is general agreement but disagreement about how extensibility for instance claims should work (due to the way CDDL represents name spaces).

Yes, I agree.

The crux to me seems to be in whether we want to allow element identifiers (element-name-map) to have per-instance scope?

If we allow that, then everything else follows quite naturally.

I think we should discuss this point in our next call.

[nedmsmith]

element-name-map was intended to have class scope as it defines the taxonomy of the device / component. We describe it as the 'key' in key-value pairs where 'value' attributes such as element-value-map, device-id, and instance-value-group bring in measurements that can have instance scope.

Maybe it is better to define a separate claim for 'is-instance' and include it in element-value-map. This would accomplish the overall objective without having to re-think the entire data model.

[thomas-fossati]

element-name-map was intended to have class scope as it defines the taxonomy of the device / component. We describe it as the 'key' in key-value pairs where 'value' attributes such as element-value-map, device-id, and instance-value-group bring in measurements that can have instance scope.

Yes, that's the disconnect. In my mind I picture a CoMID as a collection of "endorsement statements". These statements break down into a subject (the element-name) and a predicate (the element-value).

What has become apparent to me in the last few weeks, while working on the consolidation of the CDDL, is that a subject (which semantically represents a RATS Attester, or some of its sub-parts) has whatever "scope" we want to give it: class scope, instance scope, and ideally anything in between (e.g., if we use group identifiers for privacy or other reasons).

I don't think this is in conflict with your "taxonomy" metaphor though: to me the result of granting instance scope to subject's is just to make the taxonomy multi-layered: on the base class layer one can overlay multiple instance layers and slice as needed.

Maybe it is better to define a separate claim for 'is-instance' and include it in element-value-map. This would accomplish the overall objective without having to re-think the entire data model.

[yogeshbdeshpande]

I just want to state the fact mentioned in ATWG Spec, which I agree to: Section 9.1:

If Endorsement structures combine instance- and class-based values, then the scalability and maintainability benefits of class-based structures are lost. If appraisal need only consider class attributes, but the class attributes are only available via instance Endorsement structures, then a Verifier cannot benefit from the reduced number of signature verify operations required for class-based attributes (since the each instance Endorsement structure would need to be individually authenticated). Hence, Endorsement structure designs should avoid mixing class-based values with instance-based Endorsement structures.

Perhaps it is better to leave the model as it is today: considering the fact that it isolates Class and Instance Reference Claims clearly with no ambiguity ?

[nedmsmith]

I think the options are: 1) no change - keep 5 buckets for claims where ref and endorsed buckets are bifurcated according to class and instance. 2) flip the buckets - move to 3 buckets for ref, endorsed and identity claims but bifurcate according to class and instance within the buckets. 3) add an 'is-instance' claim to element-value-map 4) mix all the claims into a common set (similar to the way it is done in EAT), but apply one of the above 3 options for instrumenting instance / class semantics.

I'm not sure the value of 4 as it changes the basic idea of having a fixed set of attributes that are the 'subject' / 'key' and are intended to contain only class values so that it doesn't undermine the intention of being able to have a class-only manifest. It also doesn't directly address the original request to somehow instrument the intent that there are instance values in the data set.

Option 3 seems workable, but unnecessary since CDDL can accomplish the goal more elequently.

Option 1 and 2 are simply stylistic choices whether to rely on encoding with two code points per claim (i.e. bucket and class-or-instance) vs. one code point but there are more of them (backet-class-or-instance).

Option 1 seems to be the most compact encoding.

[thomas-fossati]

the basic idea of having a fixed set of attributes that are the 'subject' / 'key' and are intended to contain only class values so that it doesn't undermine the intention of being able to have a class-only manifest.

There is nothing in the current model that prevents us from building a manifest that mixes reference/endorsed claims with istance claims and therefore to create a manifest that is not class-only.

On the other hand, in the model that I am proposing a class-only manifest can be constructed quite straightforwardly: it's one where all the element-name's have class scope.

It also doesn't directly address the original request to somehow instrument the intent that there are instance values in the data set.

I think this depends on what we mean by "directly". To me the intent that a predicate has instance scope is communicated quite unambiguously by an associated instance subject.

I just want to state the fact mentioned in ATWG Spec, which I agree to: Section 9.1:

If Endorsement structures combine instance- and class-based values, then the scalability and maintainability benefits of class-based structures are lost. If appraisal need only consider class attributes, but the class attributes are only available via instance Endorsement structures, then a Verifier cannot benefit from the reduced number of signature verify operations required for class-based attributes (since the each instance Endorsement structure would need to be individually authenticated). Hence, Endorsement structure designs should avoid mixing class-based values with instance-based Endorsement structures.

Perhaps it is better to leave the model as it is today: considering the fact that it isolates Class and Instance Reference Claims clearly with no ambiguity ?

But note that this isolation doesn't prevent us from building a mixed bag. I still don't get the value proposition here.

[nedmsmith]

Given today element-name only has class scope. What would be an example of element-name having instance scope? In other words which of the five element-name attributes would change such that it has instance scope and why is that useful?

[thomas-fossati]

Given today element-name only has class scope. What would be an example of element-name having instance scope? In other words which of the five element-name attributes would change such that it has instance scope and why is that useful?

The current set of element-name attributes remains untouched. My proposal adds a further (optional) instance-id field (parallel to the existing class-id) that, in combination with class-id and any other relevant identifier (model, layer, etc.), would define an instance "subject" for the endorsement predicate described in the associated element-value.

[yogeshbdeshpande]

As I am not able to meet tomorrow for the discussion, my vote is with Option 2: With a slightly cleaner distinction in CDDL for individuals setting the values for endorsements/ref-claims. Something on similar lines,

reference-claim-map = non-empty<{
    class-or-instance-name-group 
    class-or-instance-claims-group
}>

class-or-instance-name-group  //= (
comid.element-name => element-name-map,
comid.instance-name => instance-name-map,
)

instance-name-map = non-empty<{
  ? comid.element-name => element-name-map
  ? comid.device-id => $device-id-type-choice
  * $$instance-name-map-extension
}>

class-or-instance-claims-group = (
  ? comid.class-claims => class-claims-map 
  ? comid.instance-claims => instance-claims-map
)

class-claims-map = non-empty<{
     element-value-group
  * $$class-claims-map-extension
}>

instance-claims-map = non-empty<{
     element-value-group
  ? $$instance-value-group-choice
  * $$instance-claims-map-extension
}>

[nedmsmith]

Regarding Thomas's comment:

The current set of element-name attributes remains untouched. My proposal adds a further (optional) instance-id field (parallel to the existing class-id) that, in combination with class-id and any other relevant identifier (model, layer, etc.), would define an instance "subject" for the endorsement predicate described in the associated element-value.

It might make sense to think through the use use case for when someone would want to put identity claims in a manifest. Given there are say 100K widgets manufactured of type (element-name) there would be 100K distinct device-ID, key-material pairs. One approach is to issue 100K certificates or CWTs if the goal is to ship a separate credential for each device - maybe they're being shipped to 100K different customers. In another approach there may be a single customer that buys all 100K widgets in which case it is OK to create a single credential that has all 100K (device ID, key-material) tuples. In the latter case, it might make sense to use a corim.

Nevertheless, the corim is still used to contain the class description of the device. Possibly, the customer onboards all 100K devices and issues separate CWT credentials for each device. Verifiers may therefore still want to see only the class-only tag omitting the identity tag as there are customer issued CWTs that fill the same purpose.

The current identity claim structure allows for a class tag to be matched to an identity tag using (element-name) where element-name is only class attributes. The identity claim structure consists of two subjects and a predicate. There is a class subject (element-name) and an instance subject (device ID) and the predicate (key-material). If there is a tag for the class description of the widget (element-name, element-value) then the element-name in the class tag can be compared with the class-subject in the tag containing an identity-claim. It would not be the case that the instance-subject would ever exist in the class tag therefore it would never be used to match the instance tag's element-name. If the identity tag has a subject that includes device-id (possibly as the only subject) then it would be impossible to match based on class information. If the identity tag has a element-name that includes both class and identity claims then there is confusion in the matching algorithm whether to match on just the class attributes in element-name ignoring the instance claims (aka device-id) or whether a correct match should apply to all the attributes in element-name.

However, since the current identity claims structure already has semantics for separating the class-subject from the instance-subject there is not ambiguity in how to match a class tag to an identity tag based on element-name. The verifier just matches all of the attributes in element-name.

Another complication associated with adding instance-attributes to element-name is that module-name is intended to be a class identifier. If we add an instance attribute to element-name (e.g. device ID) then it becomes possible (enticing?) for mfg to include device ID in module-name. If that happens then many of the assumptions for how module name are use become muddied. Verifier has to have special considerations for excluding/including the element-name attributes that have instance semantics when matching other tags' element names.

This doesn't seem like a desirable direction IMO.

The use case for instance data that isn't a subject but only a predicate is the one we want to consider IMO. In that use case, the predicates could either contain class or instance values. If the tag creator knows the predicate data has instance semantics, there should be a convenient way to capture that. The current set of proposals put that encoding outside of the predicate (element-value-map) but possibly we should focus on just the predicate structure instead of confusing it with the subject (element-name)?

[nedmsmith]

In response to yogesh's post

class-or-instance-claims-group = (
? comid.class-claims => class-claims-map 
? comid.instance-claims => instance-claims-map
)

class-claims-map = non-empty<{ element-value-group

• $$class-claims-map-extension }>

instance-claims-map = non-empty<{ element-value-group ? $$instance-value-group-choice

• $$instance-claims-map-extension }>

I agree with the direction to focus on 'class-or-instance-claims-group', as it is the predicate. Based on my understanding of the use cases, only the predicate will contain instance information (the exceptional case is the identity claim, but that has its own claim set definition already).

[yogeshbdeshpande]

Based on my understanding of the use cases, only the predicate will contain instance information (the exceptional case is the identity claim, but that has its own claim set definition already).

Thanks for the comment! However, my understanding is that if a Reference Value pertains to an Instance, should we not un-ambiguously identify instance subject for which the instance reference claim pertains to? If a reference value (not an Identity claim) belongs to a device identifier or a new instance identifier, how would that be represented then?

[nedmsmith]

Reference Value pertains to an Instance, should we not un-ambiguously identify instance subject for which the instance reference claim pertains to?

No. The verifier follows the same algorithm for identifying the device which is based on the ‘currently connected device’. This could be authenticated using a certificate, CWT/JWT, CoMID.identity-claim or some other credential. The credential could be a group credential such as EPID/DAA and hence isn’t necessarily an instance identifier.

The attestation evidence is relative to the currently connected device. It recognizes the device based on its class identity (class-id in element-name). If the attestation evidence (element-value, instance-value-group-choice) has instance attributes, the verifier must find a tag that contains reference values that match (based on the class-id). There could be 100K matches given each contains instance data, but the goal of the manifest isn’t to create a database index. The verifier can do that. Given a database index over the 100K tags it is a simple query to find the one tag that contains the reference values for the evidence that has instance data.

The verifier knows to build a database index on instance data by parsing the tag and observing that the tag contains reference instance data. Th tag schema just needs a way to flag it as instance data. The instance-value-group-choice already does this, the element-value-map doesn’t. We really just need an a element-value-instance-map structure that wraps the element-value-map (aka element-value-group).

-Ned

From: Yogesh Deshpande @.> Reply-To: ietf-rats/ietf-corim-cddl @.> Date: Wednesday, May 12, 2021 at 9:58 AM To: ietf-rats/ietf-corim-cddl @.> Cc: "Smith, Ned" @.>, Review requested @.***> Subject: Re: [ietf-rats/ietf-corim-cddl] make instance claims a special case of class claims (#60)

Based on my understanding of the use cases, only the predicate will contain instance information (the exceptional case is the identity claim, but that has its own claim set definition already).

Thanks for the comment! However, my understanding is that if a Reference Value pertains to an Instance, should we not un-ambiguously identify instance subject for which the instance reference claim pertains to? If a reference value (not an Identity claim) belongs to a device identifier or a new instance identifier, how would that be represented then?

— You are receiving this because your review was requested. Reply to this email directly, view it on GitHubhttps://github.com/ietf-rats/ietf-corim-cddl/pull/60#issuecomment-839940943, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABPMCSEGVQVCOIYO6YT5JZTTNKXTFANCNFSM44JSN2VQ.

[yogeshbdeshpande]

r identifying the device which is based on the ‘currently connected device’. This could be authenticated using a certificate, CWT/JWT, CoMID.identity-claim or some other credential. The c

Yogesh: Perhaps needs to understand your use case better! What I am pondering over is a use case where a Provisioner is constructing a CoRIM/CoMID to provision Reference Values specific to a set of instances (10/100/100K) ?? Each Reference value is unique to a specific instance, similar to Identity claims... How would such provisioning be possible if specific instance id's are not provided ??

like Device Instance #1 : Mac Address XYZ Device Instance #2 Mac address PQR

[nedmsmith]

If the use case treats each device as having a unique MAC Addr then for 100K devices there will be 100K MAC addresses. The provisioner could (a) issue 100K tags (one per device) or it could (b) issue one tag with 100K instance claims. For (a) the provisioner would use the same module-name for all 100K tags. This would be the device class name aka class-id = "MyFancyDevice". There would be one claim that omits the element-name unless there is a component within the device that has the mac address maybe element-name is "my-FPGA-that-looks-like-a-NIC". The measurement (aka "instance measurements" would have a single instance-value-group-choice for MacAddr=XYZ. For (b) the provisioner has a single tag with module-name "MyFancyDevice" and multiple (one-or-more) instance measurements. If it is a device with an element "my-FPGA-that-looks-like-a-NIC" then there is an element-name with a class-id for that and 100K entries of MAC addresses (XYZ, PQR,...). Since MACAddr is being used as an instance identifier only one mac address is permitted per device.

The use case where each device has multiple MAC addresses (c) the identity claim should be used to disambiguate which MAC addresses belong to which device. Lets say there are 100K device and 200K mac addresses - 2 per device. And one of the MAC addresses doubles as a device identifier. Then identity claim would have a 'device-id' with value XYZ and two entries in the 'instance measurements' one with XYZ and another with PQR. The other 99K would use something other than XYZ and PQR. It wouldn't make sense to have multiple (100K) Identity Claims entries, one for each device and 200K instance claims, one for each MAC address because verifier wouldn't know which MAC addresses belong to which devices. This can be resolved by using 100K tags, each having a different Identity Claim and only two MAC address claims.

The current schema for Identity Claim makes 'key-Set' mandatory. That would pose a problem for use case (c) if the device didn't have a root of trust design. It was just an unsecure device using MAC address as its identifier. (For what ever that is worth). Therefore, it might make sense to make 'keyset' optional in Identity Claim.