Re: [Rats] EAT Review Comments

[Hannes Tschofenig <[e-mail]>]

Let me answer the last point in my email below, namely how do we deal with the claims in our implementation.

We have two places where we store our code for the attestation functionality used by the attester. One is in the Trusted Firmware-M, which is used on M-class devices, and another one is in Trusted Firmware-A, which is used in A-class devices. The architecture of A and M class is different but we managed to use the same codebase in both projects but there are a few differences, namely
* how the interaction between the normal and the secure world works, and
* how the underlying software (bootloader and low level OS) exposes the measurements of software up to the attestation service.

The attestation service, in both cases, waits for incoming requests to provide an EAT back to the calling party. The request comes with a nonce and that nonce is included in the EAT. The attestation service then populates the EAT with claims, as we describe in https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-08. This document describes how to populate the claims so that they make sense in the A- and M-class environment.

Could an implementer add another claim to our implementation? Sure. For example, a location claim would be an option. Obviously it only makes sense if you have a GPS receiver attached to your device and that GPS receiver is accessible to the attestation service. This would not be something most devices have but some may. We don't provide an implementation for it right now and a developer would have to enhance the code.

Here is the code for the trusted services in TF-A:
https://git.trustedfirmware.org/TS/trusted-services.git/?h=integration
(Note the branch "integration")

Here is the code for TF-M:
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/

There are several other services included in these two repos besides the attestation service. I have spoken about the bigger picture at this event: https://www.youtube.com/watch?v=rqbYig3aXg0

Ciao
Hannes

PS: FWIW Our code uses t_cose, qcbor and the PSA Crypto API under the hood.

-----Original Message-----
From: Hannes Tschofenig
Sent: Friday, December 10, 2021 8:58 AM
To: Henk Birkholz <[e-mail]>; Laurence Lundblade <[e-mail]>
Cc: [e-mail]
Subject: RE: [Rats] EAT Review Comments

Hi Henk,

You write:

> My biggest point of concern is the scope creep into JWT.

> EAT was intended to be a CWT (more on that detail below). The
> implementation complexity of including JWT now is kind of mind-boggling.
> I have been for a while and will continue to be in strong support of
> moving JSON encoding related normative text out of the EAT core
> doucment to supplemental EAT document.

> Fundamentally, I am still opposed to EAT being a CWT. It allows to
> include any kind of CWT claims from an increasingly growing CWT Claims
> registry. I am allowed to include a nonce and a cnonce Claim
> simultaneous due to that. Or simply mix an exi Claim in. How shall an
> implementation act on that? That is a valid EAT composition. Is
> "ignore what you do not understand" the strategy here? That is not a
> really useful approach, if your goal is to establish an interoperable
> way to assert trustworthiness. I'd very much prefer a better scoped
> usage scenario for EAT for RATS by making an EAT something more
> specialized than a CWT (on the CBOR tag level). Maybe someone can
> explain to my why this is not an implementer's nightmare as I might
> miss something obvious here.

We are long past the point of deciding that an EAT is a CWT with special claims. Companies have spend a lot of resources implementing it that way. Practically, there is no problem since you will not randomly add claims to an EAT. As stated in the draft, a profile needs to determine what claims must be present and what to do with optional claims. Then, this is not an issue at all.

Can you have a look at how this works in existing implementations and why this is not a problem at all.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.