annotated-evidence vs evidence-claims and verifier-claims

[dkumar-nv]

I have two types of claims to be added to EAR-appraisal

1. evidence-claims: These are claims from evidence that verifier passes through (or may re-format and pass through). Ex: hwmodel, dbgstat, akpub, eat_nonce.
2. verifier-claims: These are claims generated by verifier that are not part of evidence. Ex: evidence-nonce-match, rim-cert-chain-valid, corim-env-match-list.

Does annotated-evidence as defined by project veraison cover both the above type of claims or just evidence-claims?

Additionally, is it possible to standardize the two types of claims listed above (or annotated-evidence instead of leaving it to every project to define a name)?

[thomas-fossati]

Does annotated-evidence as defined by project veraison cover both the above type of claims or just evidence-claims?

Yes, the “annotations” come from the Verifier, while the “evidence” comes from the Attester.
Currently, there is no way to distinguish between the two categories. Ultimately, annotated-evidence just reflects the Attester's actual state as seen from the Verifier's perspective.

Additionally, is it possible to standardize the two types of claims listed above (or annotated-evidence instead of leaving it to every project to define a name)?

This is a good point. There are several ways to approach this issue (e.g., continuing on the path we started working on here, providing a JSON serialisation of the CoRIM ACS, etc.), and it would be helpful if we could agree on a solution that everyone can support.

[dkumar-nv]

Thanks @thomas-fossati.

1. Do you expect the spec to differentiate between the two categories of claims?
2. I looked at Eat-Attestation-Results-Claim-Sets. Perhaps I wasn't clear in what I meant by "every project to define a name". I was referring to the name of the container such as annotated-evidence which are already present in the EAR spec. As an example, I already see teep-claims which is a different name from annotated-evidence but with seemingly similar purpose and both are present in EAR spec.

[thomas-fossati]

Thanks @thomas-fossati.

1. Do you expect the spec to differentiate between the two categories of claims?

My personal preference is a data structure that provides complete transparency over the appraisal process. The CoRIM ACS, which has already been mentioned, seems like the perfect fit.

Returning to the comment upthread, do you have a preference?

3. I looked at Eat-Attestation-Results-Claim-Sets. Perhaps I wasn't clear in what I meant by "every project to define a name". I was referring to the name of the container such as annotated-evidence which are already present in the EAR spec. As an example, I already see teep-claims which is a different name from annotated-evidence but with seemingly similar purpose and both are present in EAR spec.

Thanks for the clarification.

[dhawalfs1]

@thomas-fossati ,
Is your intention to treat annotated-evidence as essentially the ACS of the CoRIM? If so, what about claims that are either (a) generated by verifier and not explicitly part of evidence or (b) part of evidence but not compared to any reference value?

Some example of (a) are

1. CoRIM acquired
2. CoRIM parsed
3. CoRIM cert status (expiry date, OCSP status, etc. of each of the certs in the chain)
4. EOL date of the SW/FW
5. Device cert status similar to CoRIM cert status
6. Purpose / Device Mode (see this issue for more)

Some example of (b) are the following and may be used for RP policy or debug. The claims below don't appear under any environment-map in the evidence

1. oemid, hwmodel and other top level EAT or JWT claims excluding the measurements claims -> Since these are not under measurements claim, there is no environment-map in evidence corresponding to these (unless we get verifier to create an environment to wrap these for sake of inserting into ACS)
2. Serial number from end entity cert using DMTF OID for otherName as per SPDM spec -> part of cert chain and hence there is no corresponding environment-map in evidence
3. Extended Key Usage for cert used to sign CoRIM -> Similar to item 2.

[thomas-fossati]

As discussed face-to-face, we need to:

• understand the requirements (what kinds of annotations do we need?)
• define the precise semantics of the claim, and
• define a syntax that is rich enough yet still simple to produce and consume.

We agreed to start a design thread on the wiki for this.

[thomas-fossati]

Following further discussion and input from @dkumar-nv, the requirement is as follows:

• Allow an RP to distinguish between evidence claims as-is, and claims made by the verifier during appraisal, that is, split the current "veraison.annotated-evidence" into two distinct buckets: "evidence-claims" and "verifier-claims". Using CoRIM's ECT analogy, this amounts to separating the claims with "attester" authority from those with "verifier" authority. The former would go in an "evidence-claims" object/map containing a human-readable rendering of raw-evidence, and the latter in a "verifier-claims" object/map.

[ryeluri1]

thanks Thomas. This clarifies it perfectly