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

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