Re: [Rats] Partial Profiles (was Re: New Version Notification for draft-tschofenig-rats-psa-token-13.txt)

"lgl island-resort.com" <lgl@island-resort.com> Tue, 05 September 2023 17:51 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D07C151983 for <rats@ietfa.amsl.com>; Tue, 5 Sep 2023 10:51:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RNQBwdc9leP for <rats@ietfa.amsl.com>; Tue, 5 Sep 2023 10:51:52 -0700 (PDT)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2106.outbound.protection.outlook.com [40.107.220.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ECDCC151711 for <rats@ietf.org>; Tue, 5 Sep 2023 10:51:52 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=arQpoGDrdC2/iVFz7iM+rCgk4bbLUc/t/vWJOhJS6B0Kezdh/gMrPa1DkhLRqQuhZbHM+rZVfGCCBRiIQqOyfWCVgvfYAu7dAVFI9zMB23Av0vRxgY8F+CVoZNP7yxJruLt4vsZVRL1Jv27p/8bhnWqt1Fi8x0+Mafg3xHBjCMCXOgU3dsf2xBUVBfelAsS5oqnhIwaZzj48LCqmQqF/I3/oQ0wx6mXjo5JTB3B1kBpmK4f/1VrBPWmFpXQE+4cBDJ+efNMpOxLtyT4SMksp8VHyN1Zva2lwsC7+xLhCfKMRMWN6lImUYDKy0wfpt5smbD4HhwJZgDjcysXIIpeUgg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IAlickMWjmMBYeZ9rC5p/WQBfSVTU934N+1IRSqTlfo=; b=Ofr7TAyUyg/CaasVA1X+OUDaly5sv+rnVaijNrxSIt1CxmVBZn1zBU/Y+192qVlyoW7ppFqDwqK7ViyeOv2R4lYsRicudc8nZS0JNzZhnmChFfJROy292De9yM5mk0s2HAZcIkDUzeV82qnwvEaYvlSwuuDXkjL/+Hhqk0SokieU+LNV2lZNv5BvDpJOyZ7MryfPAmPv8/TRVBYahqbGljLSBPK1negr3xlG0X7qZwE4hd3cx7FikQoUKHHQgT441FGoFuVm06M8HEBfXCaJ/PzsHCM9SkkE4meYXQ/lYXFTVgbXk9FXKgXP5ZlOOHoPZ7yDesTmSQN796Qfu+1q4Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=island-resort.com; dmarc=pass action=none header.from=island-resort.com; dkim=pass header.d=island-resort.com; arc=none
Received: from PH7PR22MB3092.namprd22.prod.outlook.com (2603:10b6:510:13b::8) by BY5PR22MB2017.namprd22.prod.outlook.com (2603:10b6:a03:23e::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6745.33; Tue, 5 Sep 2023 17:51:47 +0000
Received: from PH7PR22MB3092.namprd22.prod.outlook.com ([fe80::f317:e4d1:7e1e:3934]) by PH7PR22MB3092.namprd22.prod.outlook.com ([fe80::f317:e4d1:7e1e:3934%3]) with mapi id 15.20.6745.030; Tue, 5 Sep 2023 17:51:47 +0000
From: "lgl island-resort.com" <lgl@island-resort.com>
To: Simon Frost <Simon.Frost@arm.com>
CC: Thomas Fossati <thomas.fossati@linaro.org>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Partial Profiles (was Re: New Version Notification for draft-tschofenig-rats-psa-token-13.txt)
Thread-Index: AQHZ3v+ZmUjvT23FSk2M66Kq8JX+cLAK/g4AgAFwKICAABb+AA==
Date: Tue, 05 Sep 2023 17:51:47 +0000
Message-ID: <3B885601-A3A7-40FF-BCCA-490480337839@island-resort.com>
References: <169358319952.22584.5522382198109168002@ietfa.amsl.com> <CA+1=6yf4YmduV-V_9_tLKJtDV5erRKHW6JzZt1w4Y4kKw2A-Qg@mail.gmail.com> <31907C23-3C21-4070-AB4D-6D045EEAB578@island-resort.com> <CA+1=6ycaA_tUa-WA9r+B=JE9BhLHjMfJ=_GOyTjNnb5wdDo-=Q@mail.gmail.com> <8BC9CCA6-110C-4478-9041-01E6CEB09958@island-resort.com> <AS8PR08MB6677C8B4C6D8FC0046B45C81EFE8A@AS8PR08MB6677.eurprd08.prod.outlook.com>
In-Reply-To: <AS8PR08MB6677C8B4C6D8FC0046B45C81EFE8A@AS8PR08MB6677.eurprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=island-resort.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH7PR22MB3092:EE_|BY5PR22MB2017:EE_
x-ms-office365-filtering-correlation-id: dd74542d-ece6-4118-537a-08dbae38c67a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 8u7P4ym3t6kmB/7SfnPHSacEyN9nYMw/lvnQZi07/NQUgUFdSA2CWzcz1s566V5yvGrsDtl+XADB0ZVYtolSeSs4x0s/PextCTNzfmhnwyZXAnjNJ2fQ2tKbZwZEolqS3X13nFd6kCTmeSVlYf8RrDsZFuGuCy2tJDtmkygk8JwqLpW7VKJbx8aoBnEAlfMi04VKIRBjQugedJtgGrIOFWL9N6NcHgEFRyKpLThfGJAF7Dq8ED+nyk1oGabivN8pHYGcJOC415FRsjsy4EB5jJ1wKenKNua9//Ry2f5wLqgtcOM1eB6GOYhhmhZznMykYyMdEaT9q+UATgBcA2c8P3k53AkDIV2nX15HdMU7xV31Q+ZiODghY7cHtTlfSWqkLTnH7utui0Ke2racJoEAs/9Vg692fjXhT1Oe5wvvZu6MEdaJFpVHS3DKYTcEHUKCIu7HeePwrCrlV0HROgCJngO6xiXj67kzpiO7/TkQcNDSRswbXlGANCLer/L8dDPNERz+p+1ofG0X5llAA2S8+1Gj+pnL9/v5qusIsFoTy+P+fkf7Q/YQeQBAYw7bRplV4clYrE6PYhietGs05HOhJslZA1l8Kiexpn2elwD0sixPVaXmbxYQqkUg8I4WGZN+93tuAwOY7ZgDJAkxqX0Tbkzt4qLJy8+9CjUT8C2nOVo=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH7PR22MB3092.namprd22.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366004)(39830400003)(346002)(396003)(136003)(376002)(186009)(451199024)(1800799009)(66899024)(15650500001)(2906002)(66574015)(30864003)(38100700002)(38070700005)(33656002)(36756003)(86362001)(166002)(122000001)(41300700001)(6512007)(6506007)(6486002)(53546011)(54906003)(6916009)(316002)(66476007)(64756008)(66446008)(66946007)(66556008)(8936002)(4326008)(8676002)(76116006)(2616005)(966005)(478600001)(91956017)(71200400001)(83380400001)(26005)(5660300002)(21615005)(21314003)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 4Tg9lZ7al12nhlc1Vtbf8sDBg278H/Ew31oxKey39mldeRR45C3eiwDoO2M3ASvdGB3KqIU8wPUrN4s5lyI0GtL7ncT9cwfPpaWv85z5hDud5LfZ/5f7ZvdaiunESljgeJkQEjk75YmajcJgDfSQ11GvlLUKCQ5Yc/1so1dE3jWqc8G/fY5s1OiwVPh16jGMF9UNxHMd4LAq7b5AYMlEY0s/jytJYebXvHmqr89/V7iFc8WKh+xbCuw2whNqtwZDIJbAbnkWndMT45Xjq++MR2dCeL5xbO9nKzEWkSxHlQo/KL3k9bkpZqZoz8uyna4n5YH3MH6T8U0nBSQpXdoSkwxa1kTU2wX+BgJRuSzC5/M7nV2saGjjqYJcRggCVnPlQy7wuVaoWZcJKbueRUL6dDaZSMTPx2d/rHXB5v96xv+xQtGaQrPJaL6zqcWQMFv/8JLXzRtI5cw1FrNTVayWmdZu9/IP3pb8E1mssWngBXbK1MKDS+vF6dP2qlrCMNAfisxt5z2DwNZo80Im7mpLgbuOQK5C/FKw5hbdsQ2PH9Wfmu0UEF1woUwEfO3oiUHmhUOaOhpqCqCvy8V8OHvPwRc2lDUpuGPjLCJVaeDELNeBd8lRWiMWH26jipUXt977AvB1/eXCrKl283dfYgky8tiWx8pJ2HZ2RY7JIh+tgChw6BZaDG/r7oRpiYtWBJuYHFnu/9HqLbTLGYDdg1LWo9tGHum8ARV+UmoqPP9c3UxmyxJvP7vaq7Dj7NIxpTLrGvBNEhc6Ue2QQY+OhHf5GtGIItwa4bBi4BnGNTARCFQ5QQj1NU8+XU7Cv3tqEibN7qt3P+cyQ+r/wHv250iEzFHD3a4aC+CVkAvFcbSC0Hk2MY4mxDjr7lv5weDqWYXlS0SbUcLQdO4Ik2Q12ZZavS3/LrQqnY8yu/zH0BnSw7MnVQt1MHQb64nwpbmk+MdiG38rY6ial3r7C5PgJWJB0Akb8O6xHdWmuXkt7hadHbpK/HvzgsIebY3nR+zZDXhsIGuQxsiseE+6jkXX1axDY5Hd8Ws0+CPS6zDiSlXMCpglUf1rCnUyLVM2ZLmLe43C0HCMpAttWUzgVdQGVeB5eM8UppPb+noZWbFratKQHPxxl0Ua0Nc5UdSUHb+Mo373V7MBXFglzPRGO7X6Y0CBb4IVpipcFBRDmuPxHpgXcwY8C52l5OwWfzwiZmG9vhe93/zjjrComA6yi7OrRTq24DJd8v01lc2U0rolIhCThyh7BLpcVqBiFgWc/sb26EP9HWW5FaiFOLC/YVUJikeAeVq0XGPKO/Ym1watJnEWOnyiJDwqfc+xePRmBiXBYLd+FsEVCUZ+COhX6gY4bZR66UpDxA8+0LFRviJzZA6uPCJuPDECVP5p9Kp7M461osHCFPY9XhTNZic5fe9sYEpGT2Jp2gKrPxteIEpdK2eUraxzbv7XBFq6nNlGQU9FwmxsjnwNI45Z9SwXXWEUBFOjmEZpNWpHvVD8Z+hV+q3NpvMa6nGgnBpYwr6UbXaFMS8+96pyZ4F7khbhVmlHcUL8wNUcbxVVWyoewb4s+FBajvx+2ceBOHnhV1Py9m+qMsCB48EdzrXEvJsqGU5eVkemvQ==
Content-Type: multipart/alternative; boundary="_000_3B885601A3A740FFBCCA490480337839islandresortcom_"
MIME-Version: 1.0
X-OriginatorOrg: island-resort.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH7PR22MB3092.namprd22.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dd74542d-ece6-4118-537a-08dbae38c67a
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2023 17:51:47.3952 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ad4b5b91-a549-4435-8c42-a30bf94d14a8
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8+BzwIOLnnHa2peJ/r7EECfBAOxqFgHkxKYXKk8+t+W+AoUVk69FmQHlAYqz/v71rqdJ1icQ+LywFyuMdzEh1g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR22MB2017
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/ybCMvSnDGn2nfqmtECwiwblB2Xw>
Subject: Re: [Rats] Partial Profiles (was Re: New Version Notification for draft-tschofenig-rats-psa-token-13.txt)
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Sep 2023 17:51:57 -0000

Hi Simon,

So we’re in agreement that there are both:
   - Partial / (abstract) baseline profiles
   - Full / interop-ready profiles

That’s the most important part for me. The question is whether we modify EAT to include those definitions or not.

It seems OK to have partial profiles if needed. (I do hope they wouldn’t have profile identifiers though. If so we might have to make the profile ID an array so you could name all profile layers).

However if it were me, I’d define it like this:

NIST ECDSA Profile
- All the claims are per section 4 and 5
- CBOR COSE_Sign1
- The sender can use ES256, ES384 or ES512 and the receiver must accept all
- The signing key is identified by the Instance ID claim
- http://arm.com/psa/2.0.0/ECDSA

HMAC Profile
- All the claims are per section 4 and 5
- CBOR COSE_Mac0
- The sender can use HMAC256, HMAC384 or HMAC512 and the receiver must accept all
- The signing key is identified by the Instance ID claim
- http://arm.com/psa/2.0.0/HMAC

Future profiles may be constructed with different crypto algorithms, key identification and freshness mechanisms, but they should not diverge from the rules about claims in section 4 and 5.

I think it’s a really big service to customers to define implementation-ready profiles. Ten years ago, I was primarily an implementor of standards, not a designer. When you encounter something not defined in a standard that you have to design, it can really knock you back.


But the big question for me is still whether we modify the EAT document to define full and partial (or whatever we call them). I don’t know how much delay this change would cause.

LL





On Sep 5, 2023, at 9:29 AM, Simon Frost <Simon.Frost@arm.com> wrote:

Hi Laurence,

I appreciate the interop concern but have some defence for the partial profile: when it is intended to be a baseline for others to base specific profiles upon. Taking the PSA doc as an example, it is intended to be specific in all claim and constraint descriptions with the deliberate exception of token signing, acknowledging the likely variance of regulatory etc pressure upon an actual deployment. If instead there were multiple copies of the profile, tied to a set of algorithms then I’m concerned that there is no common basis for future instantiations and that the profiles might appear to be a closed set to a future implementor.

The definition for a profile could be expanded to (always) include whether it is baseline or interop-ready, with a baseline profile being discouraged for deployment. A convention could also be given where the value of the profile claim reflects this e.g. that if it ends in a hyphen then it is viewed as baseline. That would be less disruptive than adding to the claim set to clarify (in the interest of EAT progress).

Thanks
Simon

From: lgl island-resort.com<http://island-resort.com/> <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Sent: Monday, September 4, 2023 7:32 PM
To: Thomas Fossati <thomas.fossati@linaro.org<mailto:thomas.fossati@linaro.org>>
Cc: rats@ietf.org<mailto:rats@ietf.org>
Subject: Re: [Rats] Partial Profiles (was Re: New Version Notification for draft-tschofenig-rats-psa-token-13.txt)

I’ve create a PR for EAT discussing full and partial profiles<https://github.com/ietf-rats-wg/eat/pull/404> (text pasted in below).

I think it is fairly important and a good thing to add, but I fear it is significant that it might delay EAT because it is more than just procedural correction.

I think it is fairly important because there is not good clarity about interoperation of protocols like CBOR, COSE, CWT and EAT in the IETF.

LL


A "full" profile is one that fully guarantees interoperability when a sender and receiver both adhere to it. A "partial" profile doesn't provide that guarantee.

For example, a profile that allows the use of signing algorithms by the sender that the receiver is not required to support is a partial profile. The sender might choose a signing algorithm that some receivers don't support. A full profile requires the receiver to support every signing algorithm a sender can choose.

A full profile doesn't require that the receiver be able to process absolutely everything that might be sent, but it should guarantee the essentials will operate. For example, signing and freshness are critical and should be guaranteed. Many claims are not and do not have to be guaranteed.

Partial profiles are discouraged. It is better to define several full profiles perhaps derived from each other. That way each profile is actually usable. It is relatively easy and inexpensive to define profiles as they don't have to be standards track and don't have to be registered anywhere. For example, rather than leaving the signing algorithms unspecified perhaps to accommodate post-quantum algorithms, a profile can specify the NIST signing algorithms. When the post-quantum algorithms are selected, a derived profile that adds the new algorithms can be specified. The derived profiles can be as simple as stating "the 'Xxx PQ' profile is the same as the 'Xxx' profile with the addition that the receiver must implement the 'yyy' post-quantum algorithm."

A "eat_profile" claim SHOULD NOT be used to identify partial profiles.




On Sep 4, 2023, at 12:15 AM, Thomas Fossati <thomas.fossati@linaro.org<mailto:thomas.fossati@linaro.org>> wrote:

Hi Laurence,

This is awesome feedback, thank you so much!

To track your review I have opened:

* https://github.com/thomas-fossati/draft-psa-token/issues/89
* https://github.com/thomas-fossati/draft-psa-token/issues/90
* https://github.com/thomas-fossati/draft-psa-token/issues/91

We will need to sit down and discuss among co-authors what to do about
this "partial profile" item.

In the meantime, we can continue the conversation on GitHub.

Cheers & thanks again!

On Sun, 3 Sept 2023 at 20:50, lgl island-resort.com<http://island-resort.com/>
<lgl@island-resort.com<mailto:lgl@island-resort.com>> wrote:


Hi Thomas, here’s my comments

1) Preferred encoding
There is no requirement of preferred serialization. Particularly integer and integer arguments do not have to be in the shortest form. I think it should probably require it like the EAT Constrained Device Standard Profile

2) Base on EAT Constrained Device Standard Profile?
When PSA token started there was no EAT Constrained Device Standard Profile. Now there is. You could rebase the document to be a variant of EAT Constrained Device Standard Profile. You’d just say “PSA Token is the same as the EAT Constrained Device Standard Profile with these differences”. The differences are 1) any algorithm can be use, 2) claims Client ID, Secure Lifecycle,… are added, 3) freshness model allows epoch handles. Just a thought.

3) Partial Profile
(I get beat up when I make comments like this, but here goes…) This is a partial profile. It doesn’t guarantee interoperability because it doesn’t lock down algorithms, key identification or freshness. The EAT Constrained Device Standard Profile is not a partial profile like this because it does lock these down. If you leave it as a partial profile, I think you have to call this out. You have to say “further profiling is needed for real client-server interoperation”. Also, if you leave it as is, I think the EAT profile identifier should be removed because it doesn’t identify anything useful.

My suggestion to deal with the partial profile issue is to define one or more full profiles. Lock down the algorithms and key identification and such for one or more profiles. This doesn’t preclude a future PQ token and such. A PQ token is just a different profile to be defined in the future. It can be easily described as the PSA Token profile with PQ algs.

Basically, I’d like to discourage partial profiles that don’t interoperate. Maybe the EAT draft should be more clear on this. Maybe it should say that profiles with profile identifiers MUST NOT have any variability that would allow for non-interoperable implementations.

LL





On Sep 1, 2023, at 8:52 AM, Thomas Fossati <thomas.fossati@linaro.org<mailto:thomas.fossati@linaro.org>> wrote:

Hi folks,

We have just published -13 of the PSA token, which we reckon is really
close to final.

So, given EAT is progressing towards publication, we are planning to
submit the PSA draft to the ISE shortly.

Whilst we tried hard to tick all the boxes in §6 of EAT, we'd love to
get some more eyeballs on it because it's one of the first EAT
profiles and as such it might become a blueprint for others.
Therefore it's quite critical that we make it as good as possible.

Thank you very much,
cheers!


---------- Forwarded message ---------
From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Date: Fri, 1 Sept 2023 at 17:46
Subject: New Version Notification for draft-tschofenig-rats-psa-token-13.txt
To: Adrian Shaw <adrianlshaw@acm.org<mailto:adrianlshaw@acm.org>>, Hannes Tschofenig
<Hannes.Tschofenig@gmx.net<mailto:Hannes.Tschofenig@gmx.net>>, Mathias Brossard
<Mathias.Brossard@arm.com<mailto:Mathias.Brossard@arm.com>>, Mathias Brossard
<mathias.brossard@arm.com<mailto:mathias.brossard@arm.com>>, Simon Frost <Simon.Frost@arm.com<mailto:Simon.Frost@arm.com>>, Simon
Frost <simon.frost@arm.com<mailto:simon.frost@arm.com>>, Thomas Fossati
<thomas.fossati@linaro.org<mailto:thomas.fossati@linaro.org>>


A new version of Internet-Draft draft-tschofenig-rats-psa-token-13.txt has
been successfully submitted by Thomas Fossati and posted to the
IETF repository.

Name:     draft-tschofenig-rats-psa-token
Revision: 13
Title:    Arm's Platform Security Architecture (PSA) Attestation Token
Date:     2023-08-31
Group:    Individual Submission
Pages:    32
URL:      https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-13.txt
Status:   https://datatracker.ietf.org/doc/draft-tschofenig-rats-psa-token/
HTML:     https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-13.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token
Diff:     https://author-tools.ietf.org/iddiff?url2=draft-tschofenig-rats-psa-token-13

Abstract:

 The Platform Security Architecture (PSA) is a family of hardware and
 firmware security specifications, as well as open-source reference
 implementations, to help device makers and chip manufacturers build
 best-practice security into products.  Devices that are PSA compliant
 are able to produce attestation tokens as described in this memo,
 which are the basis for a number of different protocols, including
 secure provisioning and network access control.  This document
 specifies the PSA attestation token structure and semantics.

 The PSA attestation token is a profiled Entity Attestation Token
 (EAT).

 This specification describes what claims are used in an attestation
 token generated by PSA compliant systems, how these claims get
 serialized to the wire, and how they are cryptographically protected.



The IETF Secretariat

_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats

_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats

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.