docs: Add subsection on environment uniqueness in the query structure

[paulhowardarm]

Provides rationale for modelling environments somewhat differently from CoRIM.

Signed-off-by: Paul Howard paul.howard@arm.com

[thomas-fossati]

LGTM, thanks!

[DhanusML]

I am not sure if I understand this correctly. Uniqueness of these identifiers across profiles may not be important, since the query contains a profile field.

[paulhowardarm]

Thanks, let me think about the wording a bit. The intention here was not to imply that there could be name collisions between different specific profiles (which I would agree is not a concern). The intention was to say that some profiles might employ identifier types that do not guarantee uniqueness by themselves.

[DhanusML]

Thanks @paulhowardarm for adding this section.

[gmandyam]

This seems overly restrictive as written. Consider a query with group and class, where class only includes the vendor. Then there could be a subset of attesters in the group that correspond to the designated vendor. Why should such a query be prohibited?

[paulhowardarm]

This seems overly restrictive as written. Consider a query with group and class, where class only includes the vendor. Then there could be a subset of attesters in the group that correspond to the designated vendor. Why should such a query be prohibited?

Hi @gmandyam - are you tracking any use cases where this would occur in practice, or is it more of a theoretical concern? I'm worried about complicating the query structure. It works well for use cases that we know about, and it makes queries simple to construct. It would be quite disruptive to both the draft and to implementations to make invasive changes to the query model, so we would want to make sure that we have clear motivation for that. The case that you mention here, if it actually occurred, could probably be handled with some light post-processing of the result set. See also my comments on the original issue that gave rise to this PR.

[gmandyam]

This seems overly restrictive as written. Consider a query with group and class, where class only includes the vendor. Then there could be a subset of attesters in the group that correspond to the designated vendor. Why should such a query be prohibited?

Hi @gmandyam - are you tracking any use cases where this would occur in practice, or is it more of a theoretical concern? I'm worried about complicating the query structure. It works well for use cases that we know about, and it makes queries simple to construct. It would be quite disruptive to both the draft and to implementations to make invasive changes to the query model, so we would want to make sure that we have clear motivation for that. The case that you mention here, if it actually occurred, could probably be handled with some light post-processing of the result set. See also my comments on the original issue that gave rise to this PR.

Consider a CCA implementation using a GUK [1]. The GUK will correspond to a set of instances. The CPAK ID could correspond directly to a Group-ID, but the class-ID is defined by a vendor/model. There could be multiple GUKs associated with the same vendor/model.

[1] https://developer.arm.com/documentation/DEN0096/latest/.

[paulhowardarm]

[...]
Consider a CCA implementation using a GUK [1]. The GUK will correspond to a set of instances. The CPAK ID could correspond directly to a Group-ID, but the class-ID is defined by a vendor/model. There could be multiple GUKs associated with the same vendor/model.

[1] https://developer.arm.com/documentation/DEN0096/latest/.

I want to make sure I'm understanding these scenarios correctly. They seem mostly to be focused on the cardinality of relationships between instances, groups and classes. But the purpose of a CoSERV query is not to locate a set of instances. The purpose of the query is to locate endorsements/RVs that are relevant to the attester's environment. I'm not sure why it would matter that there could be multiple groups to a class.

In practice, the expectation is that a group ID or an instance ID would always have UUID/UEID semantics and hence uniqueness. Whether searching by instance or searching by group, the result would be unambiguous regardless of vendor/class. Situations where this is not the case seem to be hypothetical/theoretical.

Another thing to remember is that we can make more than one CoSERV query. In fact, I would expect this to be common. Endorsements (such as trust anchors for the AK) would normally be located by instance/group, whereas RVs would more typically be located by class. We see exactly this pattern in the Arm CCA prototype here, which makes a query based on the instance ID to get the AK endorsement, and a second query based on the implementation ID to get the platform RVs. Group IDs are not used in this demo, but I wouldn't expect them to present any kind of problem if they were.

It's also okay for a query to return multiple results. The environment matching semantics of the CoRIM verification algorithm would still apply to ensure that verification and appraisal are conducted only against the relevant artifacts. So IMO it's okay for the CoSERV query language to be a slighter blunter tool, so I'd argue against complicating it unless we have a demonstrable scenario where it fails in practice.

[paulhowardarm]

Tagging @gmandyam - just want to make sure you saw the comment above. Does it make sense? Would be good to close on this PR if possible to unblock follow-up work. Note that we've also raised #110 to enable a new query style for specific artifacts.

[gmandyam]

In practice, the expectation is that a group ID or an instance ID would always have UUID/UEID semantics and hence uniqueness. Whether searching by instance or searching by group, the result would be unambiguous regardless of vendor/class. Situations where this is not the case seem to be hypothetical/theoretical.

That makes sense, but it is not clear from the current text, and the collected CDDL does not appear to support the above statement either. C The text below from the proposed PR doesn't quite cover the above concept either:

"Where globally unambiguous identifiers are not guaranteed, a CoSERV provider SHOULD be scoped such that any identifier used in a query remains unambiguous within that provider."

I think changing 'unambiguous' to 'unique' would work.