Differentiate between mandatory claims and extensions

[fitzthum]

When I serialized my EAR token, I was surprised to see that fields like annotated_evidence are actually veraison extensions. This is clear from the spec, but it's not clear from the docs. It would be good to have a note about this, or to have these members behind a feature. Beyond that, it's odd that there is a separate extensions field in the struct while the struct also includes members that represent extensions.

More fundamentally, I think this field (and possibly key_attestation) should be part of the Appraisal itself rather than being extensions. I want to use both of these fields with Trustee, but I don't want the token we generate to have Veraison extensions in it (nothing against the project; it is just confusing to find them when you aren't using Veraison). I could register my own extensions (although the extensions thing doesn't quite work yet; see #19), but that would eliminate any remaining hope of interoperability.

[thomas-fossati]

When I serialized my EAR token, I was surprised to see that fields like annotated_evidence are actually veraison extensions. This is clear from the spec, but it's not clear from the docs. It would be good to have a note about this, or to have these members behind a feature. Beyond that, it's odd that there is a separate extensions field in the struct while the struct also includes members that represent extensions.

Hmm, annotated evidence is a tricky one. And that's because (for non-JSON evidence formats) the claims' names depend on the JSON serialisation choices made by the attestation evidence library that the verifier calls to parse/serialise the claims set. To create the result EAR, the veraison service calls its packages (say, veraison/psatoken, veraison/ccatoken depending on what evidence type is appraised) and these provide their stable JSON serialisations. For example, for PSA see claims_p2.go.

Unless these claim names are also standardised for each attestation evidence format which doesn't serialise to JSON natively, I am not sure how an RP could reliably know that to access Arm CCA platform's instance identifier, it needs to use "arm.implementation-id", or "impl-id", or something else.

One way to approach this is to do some "bottom-up standardisation" :-) by agreeing on the names to use among Trustee and Veraison. Then we reach out to other projects and align.

More fundamentally, I think this field (and possibly key_attestation) should be part of the Appraisal itself rather than being extensions. I want to use both of these fields with Trustee, but I don't want the token we generate to have Veraison extensions in it (nothing against the project; it is just confusing to find them when you aren't using Veraison). I could register my own extensions (although the extensions thing doesn't quite work yet; see #19), but that would eliminate any remaining hope of interoperability.

I have been pondering on this for a while and reckon that the key attestation claim could be promoted to the standard claims set given its "popularity" - we also used it in attested TLS. We'd need to work on that in the EAR spec first though. WDYT?

[fitzthum]

Unless these claim names are also standardised for each attestation evidence format which doesn't serialise to JSON natively, I am not sure how an RP could reliably know that to access Arm CCA platform's instance identifier, it needs to use "arm.implementation-id", or "impl-id", or something else.

How does this work with the current extension implementation?

In the prototype for Trustee, the annotated claims are consumed by the policy, which is user-defined, so there is some flexibility here.

I have been pondering on this for a while and reckon that the key attestation claim could be promoted to the standard claims set given its "popularity" - we also used it in attested TLS. We'd need to work on that in the EAR spec first though. WDYT?

I think the more claims that can be settled in the spec, the better. This will make it easier to swap between different verifiers.

I guess the downside is that this will take some time. With Trustee we don't have a huge window for making invasive changes, like the switch to the EAR, but the spec is going to be a draft for a while. I'm not totally sure how to reconcile that.

[thomas-fossati]

Unless these claim names are also standardised for each attestation evidence format which doesn't serialise to JSON natively, I am not sure how an RP could reliably know that to access Arm CCA platform's instance identifier, it needs to use "arm.implementation-id", or "impl-id", or something else.

How does this work with the current extension implementation?

For the time being, this is a Veraison deployment-specific extension. So it's under Veraison's responsibility to expose the claims consistently. This is done using serialisers defined by the veraison libraries.

If we want to up-level this, which I'm ok with, we need to agree on the JSON representations of the claims set. A tentative summary of the potential sources of truth:

Evidence format	Spec
AMD SEV-SNP	Trustee
Intel TDX	https://datatracker.ietf.org/doc/draft-kdyxy-rats-tdx-eat-profile/ ?
Intel SGX	Trustee
Arm CCA	Veraison

In the prototype for Trustee, the annotated claims are consumed by the policy, which is user-defined, so there is some flexibility here.

Sure, but the idea is that we want to completely avoid any coupling between the verifier with the RP.

I have been pondering on this for a while and reckon that the key attestation claim could be promoted to the standard claims set given its "popularity" - we also used it in attested TLS. We'd need to work on that in the EAR spec first though. WDYT?

I think the more claims that can be settled in the spec, the better. This will make it easier to swap between different verifiers.

👍

I guess the downside is that this will take some time. With Trustee we don't have a huge window for making invasive changes, like the switch to the EAR, but the spec is going to be a draft for a while. I'm not totally sure how to reconcile that.

That's the slightly unpleasant side of the standardisation process. It's another parameter you need to fit into your release schedule.

[fitzthum]

If we want to up-level this, which I'm ok with, we need to agree on the JSON representations of the claims set. A tentative summary of the potential sources of truth:

With Trustee part of the annotated evidence is the so-called init-data (maps onto host data for SEV-SNP), which is user-defined. We do have a spec for how the user should format this and I guess we could add CBOR stuff to that, but fundamentally the relying party won't know what values are there. The init-data is meant to be consumed by the policy, which is user-defined, rather than by the RP itself.

I guess maybe it makes sense to have a Trustee extension for annotated-evidence, since the results are scoped to the verifiers in the Trustee project, but I think there will universal need for this type of flexible data. In some ways it's not so different from the raw evidence field, which is totally opaque to the RP.

[thomas-fossati]

If we want to up-level this, which I'm ok with, we need to agree on the JSON representations of the claims set.

@yogeshbdeshpande and I will be looking at this at the IETF hackathon this weekend. We plan to work on claim sets for Intel [ST]DX, Arm CCA and AMD SEV-SNP. If there are further evidence formats that we should tackle, please let us know.

[yogeshbdeshpande]

@fitzthum : You mentioned, With Trustee part of the annotated evidence is the so-called init-data (maps onto host data for SEV-SNP), which is user-defined.

Do you have a document that has the mapping for the SEV-SNP ?

[fitzthum]

Do you have a document that has the mapping for the SEV-SNP ?

It's not very rigorous but we have a doc that lists the claims that we currently return from each verifier.

[yogeshbdeshpande]

Do you have a document that has the mapping for the SEV-SNP ?

It's not very rigorous but we have a doc that lists the claims that we currently return from each verifier.

@fitzthum Thank you very much, I will review it ! Just an FYI : We now have a Wiki Now, where I am collating the evidence claims from various technologies which could percolate in EAR.

This is just initial ground work! The link is https://github.com/thomas-fossati/draft-ear/wiki/Eat-Attestation-Results-Claim-Sets

[kallal79]

Hi @fitzthum, I’ve been following the discussion around annotated_evidence and key_attestation with interest. I’d be glad to contribute toward clarifying the distinction between mandatory claims and extensions, and help improve documentation or propose struct-level changes that better reflect spec intent and interoperability goals.

Could you please assign me to this issue so I can begin contributing?

Thanks! —Kallal Mukherjee

[Sukuna0007Abhi]

Hi @fitzthum sir @thomas-fossati sir@yogeshbdeshpande I am also eager to work on this along with @7908837174 if this suiatable for us for working, so that we can both put efforts, thanks 👍
-Abhijit Das