search

ietf-rats / ietf-corim-cddl

This repository is abandoned. The adopted I-D can be found at:
https://github.com/ietf-rats-wg/draft-ietf-rats-corim/
2 stars 0 forks source link

Restructure CDDL based on the "triples discussion" #70

Closed thomas-fossati closed 3 years ago

thomas-fossati commented 3 years ago

This implements the following triples:

NOTE: This is not built as a patch to the previous CDDL to avoid diff madness

nedmsmith commented 3 years ago

I concur with Thomas’s sentiment. But we left open the question of group-id use case. Not part of the current feature set. If we plan to address it later, would we modify the environment-map directly or do it as an extension? Alternatively, the instance-id can have group semantics. For example, the group identifier in EPID is a UUID. It just has group properties. If we defined group-id the same as instance-id would CBOR encode them identically?

I thought the end result of the conversation was: "we don't want to water down the triple semantics by allowing extensibility of the subject", but maybe I misinterpreted the outcome. In any case I hold no strong opinions, so I'm happy either way.

yogeshbdeshpande commented 3 years ago

I concur with Thomas’s sentiment. But we left open the question of group-id use case. Not part of the current feature set. If we plan to address it later, would we modify the environment-map directly or do it as an extension? Alternatively, the instance-id can have group semantics. For example, the group identifier in EPID is a UUID. It just has group properties. If we defined group-id the same as instance-id would CBOR encode them identically?

What about other Identities like Alias Identifiers, which are neither class or group?

I think we simply do not have knowledge of other identities in question. So not providing the extension seems a bit reducing the scope here???

nedmsmith commented 3 years ago

ned: Extension points could be used in non-standard ways but risks being clobbered by a standard extension that happens to use the same code points. Otherwise, the process for using the extension point is controlled by a standard.

Maybe it is OK to allow an extension point here, but I don’t know that it will be needed. In the exercises there was a difference between an environment and a module. Modules were physical protection domains whose protection properties were known via Endorsed values (only). The composition of an environment with a module allows verifiers to bind (late binding) the endorsed properties with the reference value properties. Right now we’re requiring the environment to be synonymous with (hardware) module. It’s probably OK since we can always add 6x triples that describe the binding (composition).

So, I think its OK if environment (subject) isn’t extensible. If just implies we could have more triples in the future vs. more flexible but fewer triples.

I don’t have a strong opinion other than reaffirming the need to freeze features.

yogesh: As per my understanding the water tight implementation was that Class and Instance does not need extensibility so that not to confuse the verifier? We should certainly keep scope for identifiers which does not fall into Class and Instance scope and let them use the model. One specific example is "Group" and perhaps there may be many more hidden. Blocking them here does not seem to be the right approach here!

nedmsmith commented 3 years ago

Alias identifiers could be addressed with a new triple where subject is the alias of object.

The design trade-off is more triples vs. more flexible but fewer triples.

-Ned

From: Yogesh Deshpande @.> Reply-To: ietf-rats/ietf-corim-cddl @.> Date: Tuesday, June 22, 2021 at 9:06 AM To: ietf-rats/ietf-corim-cddl @.> Cc: "Smith, Ned" @.>, Review requested @.***> Subject: Re: [ietf-rats/ietf-corim-cddl] Restructure CDDL based on the "triples discussion" (#70)

I concur with Thomas’s sentiment. But we left open the question of group-id use case. Not part of the current feature set. If we plan to address it later, would we modify the environment-map directly or do it as an extension? Alternatively, the instance-id can have group semantics. For example, the group identifier in EPID is a UUID. It just has group properties. If we defined group-id the same as instance-id would CBOR encode them identically? From: Thomas Fossati @.> Reply-To: ietf-rats/ietf-corim-cddl @.> Date: Tuesday, June 22, 2021 at 8:51 AM To: ietf-rats/ietf-corim-cddl @.> Cc: "Smith, Ned" @.>, Review requested @.***> Subject: Re: [ietf-rats/ietf-corim-cddl] Restructure CDDL based on the "triples discussion" (#70https://github.com/ietf-rats/ietf-corim-cddl/pull/70) @thomas-fossatihttps://github.com/thomas-fossati commented on this pull request. ____ In comid-triples.cddl<#70 (comment)https://github.com/ietf-rats/ietf-corim-cddl/pull/70#discussion_r656357210>: +verification-key = {

What about other Identities like Alias Identifiers, which are neither class or group?

I think we simply do not have knowledge of other identities in question. So not providing the extension seems a bit reducing the scope here???

— 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/70#issuecomment-866117771, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABPMCSEJLMBKU5IAZ4CVT5LTUCX3RANCNFSM46VNFF7Q.

yogeshbdeshpande commented 3 years ago

Restructure CDDL based on the "triples discussion" (#70) I concur with Thomas’s sentiment. But we left open the question of group-id use case. Not part of the current feature set. If we plan to address it later, would we modify the environment-map directly or do it as an extension? Alternatively, the instance-id can have group semantics. For example, the group identifier in EPID is a UUID. It just has group properties. If we defined group-id the same as instance-id would CBOR encode them identically? What about other Identities like Alias Identifiers, which are neither class or group? I think we simply do not have knowledge of other identities in question. So not providing the extension seems a bit reducing the scope here???

I am still not clear Ned:

You can link a Alias to actual Class or Instance in one of the Triple.

However How would one explicitly represent the Alias ID in the system to say that this is an Alias ID? The intention is not to pollute the Class and Instance Identifiers ? When one wants to associate Reference Values or Endorsement Values to a Alias ID?

nedmsmith commented 3 years ago

ned: I think the triple would be something like: Subject: environment-A Object: environment-B

The class-id of A might be oid:…3.2.1 The class-id of B might be oid:…30.20.10

The predicate asserts that these oids refer to the same environment.

You could also map different forms of class-id-type-choice: Class-id of A might be oid:…3.2.1 Class-id of B might be (model, ns-auth): “widget-x”, “Acme.com”

The predicate asserts they refer to the same environment.

For instance-id cases The class-id of A might be uuid:FFFE… The class-id of B might be uuid:0001…

The predicate asserts they refer to the same instance of environment.

Alias identifiers could be addressed with a new triple where subject is the alias of object. The design trade-off is more triples vs. more flexible but fewer triples.

I concur with Thomas’s sentiment. But we left open the question of group-id use case. Not part of the current feature set. If we plan to address it later, would we modify the environment-map directly or do it as an extension? Alternatively, the instance-id can have group semantics. For example, the group identifier in EPID is a UUID. It just has group properties. If we defined group-id the same as instance-id would CBOR encode them identically?

I thought the end result of the conversation was: "we don't want to water down the triple semantics by allowing extensibility of the subject", but maybe I misinterpreted the outcome. In any case I hold no strong opinions, so I'm happy either way.

yogesh: What about other Identities like Alias Identifiers, which are neither class or group? I think we simply do not have knowledge of other identities in question. So not providing the extension seems a bit reducing the scope here??? I am still not clear Ned:

You can link a Alias to actual Class or Instance in one of the Triple.

However How would one explicitly represent the Alias ID in the system to say that this is an Alias ID? The intention is not to pollute the Class and Instance Identifiers ?