Use PSA Attestation Token as the format for initial attestation reports

[athoelke]

Update the API to use the PSA attestation token, defined in https://datatracker.ietf.org/doc/draft-tschofenig-rats-psa-token.

The token and report format, CDDL definition, and example token are no longer required in this specification - these are all provided by the PSA Attestation Token specification.

Fixes #7

[athoelke]

I would welcome feedback from @thomas-fossati @mathias-arm @SimonFrost-Arm @adrianlshaw @hannestschofenig

[thomas-fossati]

I would welcome feedback from @thomas-fossati @mathias-arm @SimonFrost-Arm @adrianlshaw @hannestschofenig

@athoelke, thanks for the heads up!

• Is a reference to the external token/report format sufficient?

Yes, I think so. Especially when the draft becomes an RFC (which should be "soon"), the referenced document will have very strong guarantees in terms of stability. RFCs are not live documents and cannot move one bit (except for Errata) once they are given a number in the series.

• Are there specific claim-construction guidelines that should be included in this document, where not provided in the PSA Token specification itself (PSM is too vague to be of any value)?

From the point of view of the API user, the only claim they can control is eat_nonce. Apart from §4.1.1 and §5.1.2, the recommendations for eat_nonce are the same as §4.1 of EAT. In particular, "An EAT nonce MUST have at least 64 bits of entropy.".
Note that the draft makes no recommendations about using nonce in chained constructions (as mentioned in the PSM). This may be an area worth elaborating on in the API doc.

• How much direction should we provide to the legacy format (in the v1.0 specification)?

Backwards compatibility is described in §4.6. The gist is:

• attesters should move to the new profile
• verifiers will take care of absorbing legacy

• Is it worth describing the differences between the legacy and new formats? - or is §4.6 Backwards Compatibility Considerations in the PSA Token spec adequate?

A pointer to that section should be enough.

[SimonFrost-Arm]

I agree with Thomas' replies to the general queries. I've made a couple of responses to the inline Issues.

[athoelke]

• Are there specific claim-construction guidelines that should be included in this document, where not provided in the PSA Token specification itself (PSM is too vague to be of any value)?

From the point of view of the API user, the only claim they can control is eat_nonce. Apart from §4.1.1 and §5.1.2, the recommendations for eat_nonce are the same as §4.1 of EAT. In particular, "An EAT nonce MUST have at least 64 bits of entropy.". Note that the draft makes no recommendations about using nonce in chained constructions (as mentioned in the PSM). This may be an area worth elaborating on in the API doc.

Note that the API specification is important for implementers as well as users of the API.

The v1.0 spec stated that the Instance ID claim must be constructed as H(IAK) for asymmetric IAK, and H(H(IAK)) for symmetric IAK (using a justification that is not immediately obvious from the citation). This is information is not repeated in the PSA Attestation Token spec, which only describes the H(IAK) construction, and PSM has nothing of value to add.

My question regarding claim construction guidance, is partly triggered by this specific description of the Instance ID claim. Is the additional info in v1.0 (choose one):

• Still correct: to be documented in PSA Attestation Token spec?
• Still correct: to be documented in PSA Attestation API (this spec)?
• No longer valid: drop from this spec?
• Not important: does not justify providing different/additional information about the attestation token content/format in this spec?

[thomas-fossati]

• Are there specific claim-construction guidelines that should be included in this document, where not provided in the PSA Token specification itself (PSM is too vague to be of any value)?

From the point of view of the API user, the only claim they can control is eat_nonce. Apart from §4.1.1 and §5.1.2, the recommendations for eat_nonce are the same as §4.1 of EAT. In particular, "An EAT nonce MUST have at least 64 bits of entropy.". Note that the draft makes no recommendations about using nonce in chained constructions (as mentioned in the PSM). This may be an area worth elaborating on in the API doc.

Note that the API specification is important for implementers as well as users of the API.

Ah, thanks for the clarification. I thought this was only for the user side.

My question regarding claim construction guidance, is partly triggered by this specific description of the Instance ID claim. Is the additional info in v1.0 (choose one):

• Still correct: to be documented in PSA Attestation Token spec?
• Still correct: to be documented in PSA Attestation API (this spec)?
• No longer valid: drop from this spec?
• Not important: does not justify providing different/additional information about the attestation token content/format in this spec?

The double-hash construction of the ImplID for symmetric keys is still valid and should be documented here.

[athoelke]

The double-hash construction of the ImplID for symmetric keys is still valid and should be documented here.

Thank you. The follow-up to this specific query, is the generalised question that I originally posed (but with insufficient context to make clear):

• Are there [other] specific claim-construction guidelines that should be included in this document, where not provided in the PSA Token specification itself? - perhaps only relevant to the use of the token within this API?

[thomas-fossati]

The double-hash construction of the ImplID for symmetric keys is still valid and should be documented here.

Thank you. The follow-up to this specific query, is the generalised question that I originally posed (but with insufficient context to make clear):

• Are there [other] specific claim-construction guidelines that should be included in this document, where not provided in the PSA Token specification itself? - perhaps only relevant to the use of the token within this API?

It seems that a major concern for API users is how to securely use the challenge/nonce in the IAT to create chained attestation schemes. To help those who need to build the "Attestation End-Point (AEP)", it would be helpful to convert Section 7.3 of the PSM into actionable information.

[thomas-fossati]

One thing that I forgot to mention previously is that users may be interested in checking the security & privacy considerations of the PSA token document. In particular: making sure they trust the challenger, and knowing what potentially privacy-sensitive info they are exposing by using the IAT.

[athoelke]

One thing that I forgot to mention previously is that users may be interested in checking the security & privacy considerations of the PSA token document. In particular: making sure they trust the challenger, and knowing what potentially privacy-sensitive info they are exposing by using the IAT.

I think that this information could be part of the SRA? (see #132)

[athoelke]

It seems that a major concern for API users is how to securely use the challenge/nonce in the IAT to create chained attestation schemes. To help those who need to build the "Attestation End-Point (AEP)", it would be helpful to convert Section 7.3 of the PSM into actionable information.

The use cases section currently describes more of the high level ideas around attestation. Not sure if it would be better if this is more aligned with the discussion of the context in the PSA Attestation Token spec (or just defer to that description?)?

I can see that providing more guidance on how the initial attestation API can be used as part of an attestation protocol, including chained schemes, could be beneficial here.

I've tried capture the need to review that material in #133.

[athoelke]

The double-hash construction of the ImplID for symmetric keys is still valid and should be documented here.

Can anyone shed light on exactly what the second+third sentence actually means in:

When using a symmetric key for the IAK, it is recommended that the Instance ID is a double hash of the key - InstanceID = H(H(IAK)). This eliminates risks when exposing the key to different HMAC block size. For further information, read RFC 2104.

RFC 2104 is the definition of HMAC. But this construction of Instance ID is not using HMAC.

[thomas-fossati]

Can anyone shed light on exactly what the second+third sentence actually means in:

When using a symmetric key for the IAK, it is recommended that the Instance ID is a double hash of the key - InstanceID = H(H(IAK)). This eliminates risks when exposing the key to different HMAC block size. For further information, read RFC 2104.

RFC 2104 is the definition of HMAC. But this construction of Instance ID is not using HMAC.

The thinking behind the double hashing was captured here.

[thomas-fossati]

LGTM, thanks!

[athoelke]

Oops. Broken rebase was force-pushed... but recovered now.