Hi,
Sorry 2nd link was broken. Here is the working version:
https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tabl...
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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: mandag 9. mai 2022 11:31 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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-05https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tschofenig-rats-psa-token-05&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7Ca1f0d63ce9bd4bc7d63308da319eb07a%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637876855625751018%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=s1D%2BiajhyLFyWj9oCT1hwfl4Iz%2BNSclFpWHZyzQCKb0%3D&reserved=0
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#tabl...https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-tschofenig-rats-psa-token-09.html%2523table-1&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7Ca1f0d63ce9bd4bc7d63308da319eb07a%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637876855625751018%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Gemk%2FOXBxXksoIVLXsAkcC82hdu8rMMRrtgGx6KSvGw%3D&reserved=0
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
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:
* I agree that it can be easy to update the verifier on remote sever to recognize both claim key values, to support backward compatibility. Therefore, if devices switch to new key values immediately, the cost of updating verifier side can be small. * The build config can make attestation more flexible. On the other hand, the claim key values are usually transparent to end users. Users might be confused by the different claim key value configurations. It might cost users additional port effort to understand the background, which, however, is likely to be irrelevant to actual usage scenarios. * Eventually the build config will be deprecated later. The backward compatibility issue will be brought up again and might become more complex if more use cases are deployed. I'd suggest to solve the compatibility issue sooner than later.
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#tabl...
Tamas Ban From: Andersson, Joakim <Joakim.Andersson@nordicsemi.nomailto:Joakim.Andersson@nordicsemi.no> Sent: 2022. május 9., hétfő 12:14 To: Tamas Ban <Tamas.Ban@arm.commailto: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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: mandag 9. mai 2022 11:31 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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-05https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tschofenig-rats-psa-token-05&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7Ca1f0d63ce9bd4bc7d63308da319eb07a%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637876855625751018%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=s1D%2BiajhyLFyWj9oCT1hwfl4Iz%2BNSclFpWHZyzQCKb0%3D&reserved=0
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#tabl...https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-tschofenig-rats-psa-token-09.html%2523table-1&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7Ca1f0d63ce9bd4bc7d63308da319eb07a%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637876855625751018%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Gemk%2FOXBxXksoIVLXsAkcC82hdu8rMMRrtgGx6KSvGw%3D&reserved=0
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
Hi,
The changes to support the updated attestation spec is on review: https://review.trustedfirmware.org/q/topic:%22attest-psa-2-0-0-profile%22+(s...)
The plan to switch over to the PSA 2.0.0 profile is the following:
* upstream the PSA 2.0.0 profile to be available for experimenting and let partners be aware that change is coming. * Make the profiles build time configurable * but keep PSA-IOT-PROFILE-1 as the default attestation profile * in case of PSA 2.0.0 profile there is still a few moving bits: * IANA registration is not yet finished, * Minor changes might still coming in PSA 2.0.0 * PSA attestation functional API is still describes the PSA-IOT-PROFILE-1 profile * When the PSA 2.0.0 is settled down * deprecation of the PSA-IOT-PROFILE_1 will be announced in the coming tf-m release * in the subsequent release make PSA-2.0.0. as the default: * update psa-arch-tests repo test suite * might completely remove the support of PSA-IOT-PROFILE-1 from tf-m and psa-arch-tests
The last bullet can be controversial because the attestation verification service must be updated to support PSA 2.0.0.
Reviews and comments are welcome!
Best Regards, Tamas Ban
From: David Hu David.Hu@arm.com Sent: Wednesday, May 11, 2022 2:03 PM To: Tamas Ban Tamas.Ban@arm.com; Andersson, Joakim Joakim.Andersson@nordicsemi.no; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: Attestation token new spec
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:
* I agree that it can be easy to update the verifier on remote sever to recognize both claim key values, to support backward compatibility. Therefore, if devices switch to new key values immediately, the cost of updating verifier side can be small. * The build config can make attestation more flexible. On the other hand, the claim key values are usually transparent to end users. Users might be confused by the different claim key value configurations. It might cost users additional port effort to understand the background, which, however, is likely to be irrelevant to actual usage scenarios. * Eventually the build config will be deprecated later. The backward compatibility issue will be brought up again and might become more complex if more use cases are deployed. I'd suggest to solve the compatibility issue sooner than later.
Best regards, Hu Ziji
From: Tamas Ban via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Monday, May 9, 2022 6:21 PM To: Andersson, Joakim <Joakim.Andersson@nordicsemi.nomailto:Joakim.Andersson@nordicsemi.no>; tf-m@lists.trustedfirmware.orgmailto: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#tabl...
Tamas Ban From: Andersson, Joakim <Joakim.Andersson@nordicsemi.nomailto:Joakim.Andersson@nordicsemi.no> Sent: 2022. május 9., hétfő 12:14 To: Tamas Ban <Tamas.Ban@arm.commailto: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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: mandag 9. mai 2022 11:31 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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-05https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tschofenig-rats-psa-token-05&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7Ca1f0d63ce9bd4bc7d63308da319eb07a%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637876855625751018%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=s1D%2BiajhyLFyWj9oCT1hwfl4Iz%2BNSclFpWHZyzQCKb0%3D&reserved=0
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#tabl...https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-tschofenig-rats-psa-token-09.html%2523table-1&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7Ca1f0d63ce9bd4bc7d63308da319eb07a%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637876855625751018%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Gemk%2FOXBxXksoIVLXsAkcC82hdu8rMMRrtgGx6KSvGw%3D&reserved=0
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
Hi, is there a planned or anticipated date for deprecation and removal of the PSA-IOT-PROFILE_1?
Regards, Brian
From: Tamas Ban via TF-M tf-m@lists.trustedfirmware.org Sent: Friday, July 15, 2022 8:21 AM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [EXTERNAL] [TF-M] Re: Attestation token new spec
Hi,
The changes to support the updated attestation spec is on review: https://review.trustedfirmware.org/q/topic:%22attest-psa-2-0-0-profile%22+(s...)
The plan to switch over to the PSA 2.0.0 profile is the following:
* upstream the PSA 2.0.0 profile to be available for experimenting and let partners be aware that change is coming. * Make the profiles build time configurable * but keep PSA-IOT-PROFILE-1 as the default attestation profile * in case of PSA 2.0.0 profile there is still a few moving bits: * IANA registration is not yet finished, * Minor changes might still coming in PSA 2.0.0 * PSA attestation functional API is still describes the PSA-IOT-PROFILE-1 profile * When the PSA 2.0.0 is settled down * deprecation of the PSA-IOT-PROFILE_1 will be announced in the coming tf-m release * in the subsequent release make PSA-2.0.0. as the default: * update psa-arch-tests repo test suite * might completely remove the support of PSA-IOT-PROFILE-1 from tf-m and psa-arch-tests
The last bullet can be controversial because the attestation verification service must be updated to support PSA 2.0.0.
Reviews and comments are welcome!
Best Regards, Tamas Ban
From: David Hu <David.Hu@arm.commailto:David.Hu@arm.com> Sent: Wednesday, May 11, 2022 2:03 PM To: Tamas Ban <Tamas.Ban@arm.commailto:Tamas.Ban@arm.com>; Andersson, Joakim <Joakim.Andersson@nordicsemi.nomailto:Joakim.Andersson@nordicsemi.no>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: RE: Attestation token new spec
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:
* I agree that it can be easy to update the verifier on remote sever to recognize both claim key values, to support backward compatibility. Therefore, if devices switch to new key values immediately, the cost of updating verifier side can be small. * The build config can make attestation more flexible. On the other hand, the claim key values are usually transparent to end users. Users might be confused by the different claim key value configurations. It might cost users additional port effort to understand the background, which, however, is likely to be irrelevant to actual usage scenarios. * Eventually the build config will be deprecated later. The backward compatibility issue will be brought up again and might become more complex if more use cases are deployed. I'd suggest to solve the compatibility issue sooner than later.
Best regards, Hu Ziji
From: Tamas Ban via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Monday, May 9, 2022 6:21 PM To: Andersson, Joakim <Joakim.Andersson@nordicsemi.nomailto:Joakim.Andersson@nordicsemi.no>; tf-m@lists.trustedfirmware.orgmailto: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#tabl...
Tamas Ban From: Andersson, Joakim <Joakim.Andersson@nordicsemi.nomailto:Joakim.Andersson@nordicsemi.no> Sent: 2022. május 9., hétfő 12:14 To: Tamas Ban <Tamas.Ban@arm.commailto: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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: mandag 9. mai 2022 11:31 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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-05https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tschofenig-rats-psa-token-05&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7Ca1f0d63ce9bd4bc7d63308da319eb07a%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637876855625751018%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=s1D%2BiajhyLFyWj9oCT1hwfl4Iz%2BNSclFpWHZyzQCKb0%3D&reserved=0
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#tabl...https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-tschofenig-rats-psa-token-09.html%2523table-1&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7Ca1f0d63ce9bd4bc7d63308da319eb07a%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637876855625751018%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Gemk%2FOXBxXksoIVLXsAkcC82hdu8rMMRrtgGx6KSvGw%3D&reserved=0
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
Hi Brian,
The PSA token document is with the RFC editor at the moment: https://datatracker.ietf.org/doc/draft-tschofenig-rats-psa-token/
The publication can be expected somewhere in 2024. When that happens the TF-M project can decide when to deprecate the old profile and make the new one the default. It won't happen immediately for sure there will be a notice period.
First, we need to wait (3-12 month) until the spec is going to be published.
BR, Tamas
From: Quach, Brian via TF-M tf-m@lists.trustedfirmware.org Sent: Tuesday, December 12, 2023 6:38 PM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Re: Attestation token new spec
Hi, is there a planned or anticipated date for deprecation and removal of the PSA-IOT-PROFILE_1?
Regards, Brian
From: Tamas Ban via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Friday, July 15, 2022 8:21 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: [EXTERNAL] [TF-M] Re: Attestation token new spec
Hi,
The changes to support the updated attestation spec is on review: https://review.trustedfirmware.org/q/topic:%22attest-psa-2-0-0-profile%22+(s...)
The plan to switch over to the PSA 2.0.0 profile is the following:
* upstream the PSA 2.0.0 profile to be available for experimenting and let partners be aware that change is coming. * Make the profiles build time configurable * but keep PSA-IOT-PROFILE-1 as the default attestation profile * in case of PSA 2.0.0 profile there is still a few moving bits: * IANA registration is not yet finished, * Minor changes might still coming in PSA 2.0.0 * PSA attestation functional API is still describes the PSA-IOT-PROFILE-1 profile * When the PSA 2.0.0 is settled down * deprecation of the PSA-IOT-PROFILE_1 will be announced in the coming tf-m release * in the subsequent release make PSA-2.0.0. as the default: * update psa-arch-tests repo test suite * might completely remove the support of PSA-IOT-PROFILE-1 from tf-m and psa-arch-tests
The last bullet can be controversial because the attestation verification service must be updated to support PSA 2.0.0.
Reviews and comments are welcome!
Best Regards, Tamas Ban
From: David Hu <David.Hu@arm.commailto:David.Hu@arm.com> Sent: Wednesday, May 11, 2022 2:03 PM To: Tamas Ban <Tamas.Ban@arm.commailto:Tamas.Ban@arm.com>; Andersson, Joakim <Joakim.Andersson@nordicsemi.nomailto:Joakim.Andersson@nordicsemi.no>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: RE: Attestation token new spec
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:
* I agree that it can be easy to update the verifier on remote sever to recognize both claim key values, to support backward compatibility. Therefore, if devices switch to new key values immediately, the cost of updating verifier side can be small. * The build config can make attestation more flexible. On the other hand, the claim key values are usually transparent to end users. Users might be confused by the different claim key value configurations. It might cost users additional port effort to understand the background, which, however, is likely to be irrelevant to actual usage scenarios. * Eventually the build config will be deprecated later. The backward compatibility issue will be brought up again and might become more complex if more use cases are deployed. I'd suggest to solve the compatibility issue sooner than later.
Best regards, Hu Ziji
From: Tamas Ban via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Monday, May 9, 2022 6:21 PM To: Andersson, Joakim <Joakim.Andersson@nordicsemi.nomailto:Joakim.Andersson@nordicsemi.no>; tf-m@lists.trustedfirmware.orgmailto: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#tabl...
Tamas Ban From: Andersson, Joakim <Joakim.Andersson@nordicsemi.nomailto:Joakim.Andersson@nordicsemi.no> Sent: 2022. május 9., hétfő 12:14 To: Tamas Ban <Tamas.Ban@arm.commailto: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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: mandag 9. mai 2022 11:31 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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#tabl...https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html%23table-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
tf-m@lists.trustedfirmware.org
-
David Hu -
Quach, Brian -
Tamas Ban