GET_CERTIFICATE Handling Missing Strict Responder Gate for SLOT_SIZE_REQUESTED Without SET_CERT_CAP

[czwolak]

The responder path for GET_CERTIFICATE/CERTIFICATE does not explicitly enforce a strict capability check that ties SLOT_SIZE_REQUESTED usage to negotiated SET_CERT_CAP. In other words, when SET_CERT_CAP is not negotiated, there is no explicit responder-side rejection path for requests using SLOT_SIZE_REQUESTED.

Observed Behavior

Request processing does not include an explicit strict gate for SLOT_SIZE_REQUESTED against negotiated SET_CERT_CAP.
Behavior may rely on tolerant parsing/implicit handling instead of deterministic reject logic.
Expected Behavior

If SET_CERT_CAP is not negotiated, responder should explicitly reject GET_CERTIFICATE requests that set/use SLOT_SIZE_REQUESTED (with protocol-appropriate error handling).
Impact

Spec-compliance and interop ambiguity.
Inconsistent behavior across implementations during negative/strict conformance testing.
Severity
Medium (non-security protocol compliance gap, unless project policy requires strict reject semantics).

Suggested Fix
Add an explicit responder-side validation gate:

Check SLOT_SIZE_REQUESTED usage in GET_CERTIFICATE.
Verify SET_CERT_CAP negotiation state.
Return defined protocol error when the flag is used without capability negotiation.
Add unit tests for both allowed and rejected combinations.

[steven-bellock]

@czwolak where in the specification do you see a strict binding between SET_CERT_CAP and SlotSizeRequested, such that if SET_CERT_CAP is not set then setting SlotSizeRequested would result in an error?

[jyao1]

I don't think we should return error.

We have discussed in https://github.com/DMTF/SPDM-WG/pull/4292.

• If the Responder supports SET_CERTIFICATE, then the Responder shall return the maximum size of a certificate chain that can be provisioned into this slot.
• If the Responder does not support SET_CERTIFICATE and this slot already has a certificate chain, then the Responder shall return the size of the certificate chain.
• If the the Responder does not support SET_CERTIFICATE and this slot does not have a certificate chain, then the Responder shall return 0 as the size.

[czwolak]

Thank you. I think third case is not reachable, because responder still rejects when no certificate chain is present before reaching the size-return logic. it this ok ?

libspdm/library/spdm_responder_lib/libspdm_rsp_certificate.c

Lines 124 to 128 in 43c8754

	if (spdm_context->local_context.local_cert_chain_provision[slot_id] == NULL) {
	return libspdm_generate_error_response(
	spdm_context, SPDM_ERROR_CODE_INVALID_REQUEST,
	0, response_size, response);
	}

[steven-bellock]

I will look at this this week. Ideally, whether or not the Responder supports SET_CERT_CAP should not affect SlotSizeRequested. In libspdm we have libspdm_get_cert_chain_slot_storage_size(), which is a HAL function. We made it, as a convenience, so that an Integrator did not have to implement this if they did not support SET_CERTIFICATE.

libspdm/library/spdm_responder_lib/libspdm_rsp_certificate.c

Lines 202 to 207 in 43c8754

	#if LIBSPDM_ENABLE_CAPABILITY_SET_CERT_CAP
	if ((spdm_request->header.spdm_version >= SPDM_MESSAGE_VERSION_13) &&
	(spdm_request->header.param2 & SPDM_GET_CERTIFICATE_REQUEST_ATTRIBUTES_SLOT_SIZE_REQUESTED)) {
	remainder_length = libspdm_get_cert_chain_slot_storage_size(spdm_context, slot_id);
	}
	#endif /* LIBSPDM_ENABLE_CAPABILITY_SET_CERT_CAP */

[czwolak]

thanks for clarifying.
That makes sense. I agree the intended behavior should make SlotSizeRequested independent of SET_CERT_CAP.
My concern is that in current behavior the “no chain in slot” path appears to be rejected before size-return logic is reached, so the “return 0” case may not be reachable.
I suggest we align on expected behavior first (especially empty slot semantics), then I can update defect wording to focus on that mismatch.