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> 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
<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> 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>
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>, Hannes Tschofenig
<Hannes.Tschofenig@gmx.net>, Mathias Brossard
<Mathias.Brossard@arm.com>, Mathias Brossard
<mathias.brossard@arm.com>, Simon Frost <Simon.Frost@arm.com>, Simon
Frost <simon.frost@arm.com>, Thomas Fossati
<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
https://www.ietf.org/mailman/listinfo/rats

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