Signer ID required in IAT by PSA-SM?

[stevew817]

@athoelke the documentation in this repo states that the signer ID of a claimed software component in the IAT does not need to be present in the token, though adhering to the PSA-SM would require that field being present. Since the PSA-SM doesn't have that many implementation specs, that phrase was surprising to us. Could you elaborate on where in the PSA-SM this requirement is presented?

https://github.com/ARM-software/psa-api/blame/5f2148fa55c61dc64abbe63eba16057fdd2338fe/doc/attestation/overview/report.rst#L140-L147

[athoelke]

Background

The interaction between the Attestation API and the PSA Security Model [PSM] has some history. Early versions of the Security Model (1.0-alpha) were more prescriptive/normative in relation to the requirements on an implementation, including the information provided by the Attestation service. The most recent version (1.1 Beta - the PSA Certified copy is here), has relaxed the language in this area, and is more informative than normative regarding what an attestation report looks like.

In addition, some of the early thinking about the use cases for the API, resulted in wanting the token definition in the API to provide more flexibility than the [PSM] requirements. Hence the optional claims, but with comments about requirement for [PSM] compliance. Those use cases are actually not in scope for a system that is implementing this API in order to be compliant with PSA Certified requirements.

The combination of these factors now results in an API specification that uses [PSM] as a normative reference for aspects that are no longer mandatory in the latest [PSM] document.

Current situation

The token format described by this part of the specification is being superseded by the PSA Attestation token format defined in datatracker.ietf.org/doc/draft-tschofenig-rats-psa-token. Issue #7 is about updating the API to use the new format. Resolving the question of what claims are mandatory in a PSA Attestation token should probably happen within the IETF document project.

If some deployments demand claims that are optional in that base specification, perhaps that needs to be specified in other documents or profiles?

For this particular claim, the question is whether there are use cases where reporting which key was used to authorize a specific firmware image is essential, not just reporting that the specific firmware image was authorized by one of the trust anchors on the device.