LIBSPDM Measurement Opaque Data Callback doesn`t provide the Requester NONCE as input parameter.

[fdamato]

The SPDM GetMeasurements Response includes the OpaqueData field, which allows the responder to provide additional data to the requestor. In certain scenarios, the responder may want to sign the data within the opaque field separately from the Message Signature, which typically requires the entire L1/L2 transcript for authentication.

Currently, the libSPDM calls back to a user-implemented API to populate the "Opaque Data" field. However, the existing API does not include a NONCE as an input parameter, preventing the user from signing the content of the Opaque Data in an anti-replay protected manner.

To address this, I propose one of the following changes:

• Introduce an additional parameter (NONCE) in the libspdm_measurement_opaque_data function, which may result in backward compatibility issues.

• Attach the nonce (or more generally, the request message) to the context and make it accessible to libspdm_get_data for retrieval.

[steven-bellock]

preventing the user from signing the content of the Opaque Data in an anti-replay protected manner.

The Responder itself can generate a nonce and embed it into the opaque data. That should be sufficient for replay protection, no?

Attach the nonce (or more generally, the request message) to the context and make it accessible to libspdm_get_data for retrieval.

Presumably the Integrator has access to the Responder's scratch/receive buffer, so if the libspdm_measurement_opaque_data is called the Integrator can assume that the GET_MEASUREMENT request is sitting in the scratch/receive buffer. But yes, having a pointer parameter would make things more uniform. Let me think about this.

[fdamato]

The Responder itself can generate a nonce and embed it into the opaque data. That should be sufficient for replay protection, no? While a Responder-generated nonce can ensure operation freshness, its effectiveness is heightened when combined with a Requestor nonce. In an attestation scheme like a background check, the verifier (located behind the requestor) can indirectly provide the nonce to the responder, ensuring its use in signing the OpaqueData for a complete full-trip process (verifier->requestor->responder->requestor->verifier)

[steven-bellock]

After discussing this with @jyao1 sounds like a pointer to the request itself would be best, as it would future-proof against needing to add other parameters. In particular the Requester's context or opaque data might be needed.