corim delegation (was: corim-creator doesn't appear to have an entity)

[nedmsmith]

PR#17 added corim-creator, but it isn't clear which entity map should include it. The unsigned-corim has a singleton entity instance 'signer' which should always (I think) be corim.signer.

It isn't clear if there is a use case for corim.creator and if so which entity map should include it or if there is a broken schema.

If it is added to concise-mid-tag, then possibly it should be added to all tags' entity maps or possibly only one (the first?) entity maps? Alternatively, the unsigned corim should have another entity map for corim.creator?

[nedmsmith]

Additionally, the naming of the role names should not overload or confuse the namespace names (e.g. corim-signer should be corim.manifest-signer and corim.manifest-creator instead of corim.corim-signer and corim.corim-creator).

For example, possibly unsigned-corim-map should have an entity-map containing the module-creator. (e.g. corim.creator => corim.entity-map); where the corim.$role value is 'corim.manifest-creator'?

Additionally, corim.$role.entity-name and comid.$role.entity-name should be a '-type-choice' instead of 'text' to accommodate future entity IDs such as 'URI' and 'DID'.

comid.$role-type-choice /= comid.tag-creator   
comid.$role-type-choice /= comid.module-creator   
comid.$role-type-choice /= comid.module-distributor   
comid.$role-type-choice /= comid.module-licensor   
comid.$role-type-choice /= comid.module-maintaner 

comid.tag-creator = 1  
comid.module-creator = 7 
comid.module-distributor = 8 
comid.module-licensor = 9
comid.module-maintaner = 10 

corim.$role-type-choice /= corim.manifest-signer   
corim.$role-type-choice /= corim.manifest-creator 

corim.manifest-signer = 11
corim.manifest-creator = 12

Note: using code point numeric assignments as defined in PR#17

[thomas-fossati]

@nedmsmith I'm not sure, does #23 close this?

[thomas-fossati]

Yesterday, in f2f discussion we seem to have reached consensus around the fact that we don't need licensor and distributor. We also questioned the need of maintainer, and more generally what is the semantic of the "role" associated with a CoMID.

[thomas-fossati]

Actions:

• Thomas: remove licensor and distributor from the CDDL
• Yogesh: document a use case to justify maintainer
• Ned and Thomas: write a para to state our position on supply chain delegation (we don't support it ATM but one can build it by extending $concise-tag-type-choice with a COSE_Sign'ed -- i.e., w/ multiple signatures -- CoMID.

[nedmsmith]

@thomas-fossati if '$concise-tag-type-choice' is expanded in the future to allow 'signed-corim-map' that contains a comid tag where the tag creator is the same entity as the corim signer. Then the role delegation path is dis-intermediated by the top-level corim signer. The verifier can observe that the corim signer entity is the same as the comid creator entity and look to an appropriate credential that authorizes delegation of these respective roles.

The top-level corim signer countersigns the nested signed-corim-map.

[thomas-fossati]

I was thinking of a COSE_Sign(concise-mid-tag) where the signers are associated (e.g., via thumbprint, DID or whatever) with the entities listed inside the CoMID and their respective roles, so that they all need to agree on the content of the CoMID -- which includes the "hat" they are wearing -- before sealing.

[nedmsmith]

The challenge with having a signature per tag is the tag creator might author a hand full of tags (think in terms of a DICE layering or a 'composite-device' pattern). If he signs at the corim (unsigned-corim-map) then there is a list of tags that all are signed together. This benefits both the signer and verifier by minimizing the number of sign/verify operations. Signing at the concise-mid-tag level would require n sign and n verify operations for n tags. Signing at the corim level would require 1 sign and 1 verify operations for n tags.

[thomas-fossati]

the exact model of delegation is rather unclear to me at the moment. However, I am pretty sure that once the picture is crisp we can come up with a design that is computationally and operationally efficient. One way is to let CoRIM to be recursive (i.e., include other CoRIMs), with different signers at different level of the delegation path, each one sealing as much as it is possible with a single operation.

[thomas-fossati]

Maybe we could move this discussion into a future "delegation" work item?

[yogeshbdeshpande]

Follow up on the Action: Yogesh: document a use case to justify maintainer Following text can be added to the TCG Documentation for Maintainer:

Following description highlights the two roles Module Creator and Module Maintainer. Please note that the two roles could be carried out by the same entity or different entities depending upon individual use cases and deployment needs.

1. Module Creator: Entity that is responsible for creation of initial (first) revision of a Module (Hardware or Firmware).

2. Module Maintainer: Once the Module is deployed in the field, it needs maintenance:

(a) Module needs improvement in terms of security patches, bug fixes or minimal improvements. TCG Endorsement Architecture model provisioning of such improvements by an Endorser by issuing a new CoMID tag.

(b) In addition to this, during the lifecycle of a module, new features get added to the existing module. Typical enhancements, major optimizations fall into this category. TCG Endorsement Architecture model provisioning of such enhancements by an Endorser by issuing a new CoMID tag.

For above cases, when a new CoMID tag is issued, comid.entity is assigned with the following settings, within module-entity-map • The name of the module maintainer is encoded in comid.entity-name • role is encoded in comid.role by setting $module-role-type-choice as comid.maintainer