Verification Flow needs to consider both profile in CoRIM and Evidence

[yogeshbdeshpande]

The section of Verification does cover a reference to profile for performing appraisal procedure.

However the sections only addresses profiles in terms of CoRIM Profiles. However,

1. There are actually two profiles, one in Endorsements (Reference Values and Endorsed Values) and the other in Evidence.
2. Evidence profile is associated to Endorsement profile and there is a linkage between the two ( there could be 1:N relationship between them) and they are not identical.
3. Also not all Evidence are carried out as CoRIM as well.

Considering all the above aspects the Verification sections which describes profile based Verification needs to clearly set the context in which profiles are referred.

One suggestion is to use another term: known as "Attestation Format" OR "Attestation Scheme" which maps to a unique scheme for Appraisal considering CoRIM Endorsement + Evidence Profile into consideration!

[andrew-draper]

I am not convinced we need profile in Evidence. The profile applies to a CoRIM file, and my assumption is that the profile is a short-cut way for a CoRIM author to tell a Verifier either:

• If you don't understand feature F then you won't be able to process this file
• There are two ways to process feature G, I want you to process the feature using G1

[nedmsmith]

I see the relationship between profile between evidence and reference in a more fundamental way. In order for the Verifier to parse evidence it needs to know if it is capable of parsing the rest of the evidence. This is Andy's bullet number 1, but applied to parsing not just processing. The SPDM table of contents header, in the TCG Concise Evidence binding for SPDM spec, is there to ensure the parser knows which profile was used to construct the evidence found in the consise-evidence field. This allows the Verifier to find a suitable parser before trying and failing to parse something that is specific to a profile. That spec sets the precedent that the conceptual message wrapper containing concise-evidence will define the profile if one is needed. Anything that is based on the default behavior (e.g., DICE layering) doesn't require a profile.

I'm not certain there is (should be) a 1:N relationship between profiles for Evidence and Reference Values. (BTW: 9334 separates Endorsers from RVPs - the terminology in Yogesh's bullet 2 seems to combine them). The reasoning why there is a 1:1 relationship between evidence and reference value profile is that it will be difficult to ensure combinatorics of supporting multiple profiles doesn't result in a security error. This was the reason we dialed back the multiplicity of profile in the current comid schema to be a singleton. There is an assumption that the CoMID profile id/name should be the same as the evidence profile id/name. Maybe this should be clarified in prose?

In cases such as DICE X.509 certificates as Evidence and for SPDM indirect cases. There is a pre-step assumed that maps the DiceTcbInfo format into a concise-evidence format. Since DICE is the default profile no explicit profile name is needed.

There is also a profile in EAR / Concise Attestation Results schemas. There are similar dependencies on parsing as well as processing. If the AR profile differs from the comid profile, there is an assumption that the AR profile includes semantics for selecting an appropriate comid profile. This could be expressed as prose in the profile. Ideally, they are the same profile id/name to avoid combinatoric disconnect.