Certificate Shadow Slots

[steven-bellock]

According to the SPDM 1.2 specification (given below) the certificates returned by the Responder must be consistent with the negotiated ALGORITHMs, and apparently this also holds for 1.0 and 1.1, even though it was never explicitly stated in those specifications. libspdm does not comply with this, as it does not check the certificate type when processing a DIGESTS or CERTIFICATE response, technically making this a bug.

With the successful completion of the ALGORITHMS message, all of the parameters of the SPDM connection have been determined. Thus, all SPDM message exchanges after the VCA messages shall comply with the selected parameters in ALGORITHMS, with the exception of GET_VERSION and VERSION messages, or unless otherwise stated in this specification. To explain this behavior, suppose a Responder supports both RSA and ECDSA asymmetric algorithms. For an SPDM connection, the Responder selects the TPM_ALG_RSASSA_2048 asymmetric algorithm in BaseAsymSel and the TPM_ALG_SHA_256 hash algorithm in BaseHashSel. If the Requester on that same connection issues a GET_DIGESTS, the Responder returns TPM_ALG_SHA_256 digests only for those populated slots that can provide a TPM_ALG_RSASSA_2048 signature for a CHALLENGE_AUTH response. The Responder would violate this requirement if the Responder returns one or more digests of populated slots that perform ECDSA signatures or uses a different hash algorithm.

Unless otherwise stated in this specification and with the exception of GET_VERSION, if a Requester issues a request that violates one or more of the negotiated or selected parameters of a given connection, the Responder shall either silently discard the request or return an ERROR message with an appropriate error code.

[jyao1]

it does not check the certificate type

Would you please be more specific on what check is needed?

[steven-bellock]

That the public key algorithm of the leaf certificate returned in CERTIFICATE is the same as ALGORITHM.BaseAsymSel. Alternatively, this could be left entirely to the libspdm integrator; ie, after VCA the integrator determines the negotiated BaseAsymSel algorithm and only supplies certificates that are consistent with that algorithm.

[jyao1]

Ah, this is early detection before digital signature verification in CHALLENGE_AUTH or KEY_EXCHANGE. In case there is issue, it can be found earlier.
We still need rely on final signature verification to prove the integrity of certificate.

[steven-bellock]

Since this is now part of the specification, libspdm could force the integrator to specify the public key algorithm during libspdm_set_data(LIBSPDM_DATA_LOCAL_PUBLIC_CERT_CHAIN). libspdm would then check the slot's public key algorithm against BaseAsymSel during the DIGESTS and CERTIFICATE responses. This way libspdm can enforce the specification, rather than leaving it entirely to the integrator.

[jyao1]

It could be implementation change. No API change. Remove STABLE tag.