Hi Tamas,

 

Thanks a lot for bringing it up.

 

It can a bit risky but I’d prefer to switch to new claim key values immediately.

Some rough thoughts on this topic:

 

Best regards,

Hu Ziji

 

From: Tamas Ban via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Monday, May 9, 2022 6:21 PM
To: Andersson, Joakim <Joakim.Andersson@nordicsemi.no>; tf-m@lists.trustedfirmware.org
Subject: [TF-M] Re: Attestation token new spec

 

Hi,

 

Sorry 2nd link was broken. Here is the working version:

 

https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#table-1

 

Tamas Ban

From: Andersson, Joakim <Joakim.Andersson@nordicsemi.no>
Sent: 2022. május 9., hétfő 12:14
To: Tamas Ban <Tamas.Ban@arm.com>
Subject: RE: Attestation token new spec

 

Is te second link broken? I get a 404 error code.

 

-Joakim

 

From: Tamas Ban via TF-M <tf-m@lists.trustedfirmware.org>
Sent: mandag 9. mai 2022 11:31
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] Attestation token new spec

 

Hi,

 

the initial attestation token implementation is aligned with this specification:

https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-05

 

This spec is still evolving and there is a newer version which changes the key values of the claims in the token:

https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#table-1

 

This can cause combability issues between token issuer (device) and token verifier (some remote verification service).

This is an ABI  change between token issuer and consumer.

The breaking effect would be manifest in unaccepted IAT tokens by the verifier.

 

On-device side I see these options to make the transition:

- A build-time option could be introduced which determines which range of key numbers to use. The default value would be the new range. To not let new users pick up the old values accidentally.  Existing users can notice the incompatibility issue during the integration test and adjust their build command accordingly. However, the old range would be announced as deprecated in the next TF-M release, then will be removed in the next release after.

- Immediate switch over to the new range, without supporting the old range anymore. On the verification service side, an SW update can handle the transition and might be accepting both ranges for a while. I assume the verification service can be updated more easily than remote devices therefore better to handle the compatibility issue there.

- Keeping the support for both ranges for the long term and letting users choose by build time.

 

Please share your thoughts on:

- Are you aware that the attestation service is used in deployed devices where this transition can cause incompatibility?

- From the above list which option would you vote to support the transition?

 

Best regards,

Tamas Ban