When endpoint claims KEY_EX but not MAC capabilities libspdm should only prevent secure messages, not stop negotiation

[lordaule]

A vendor claims their implementation is compliant with DSP0274, but libspdm is failing to accept their Capabilities response:

Received 13 bytes
00000000 05 11 61 00 00 00 0a 00 00 56 d2 00 00 : ..a......V...
SPDM negotiation failed (ret 0x80010005)

libspdm validate_responder_capability() currently has this code:

        if ((key_ex_cap == 1) || (psk_cap != 0)) {
            /* While clearing MAC_CAP and setting ENCRYPT_CAP is legal according to DSP0274, libspdm
             * also implements DSP0277 secure messages, which requires at least MAC_CAP to be set.
             */
            if (mac_cap == 0) {
                return false;
            }

By returning false above, the library prevents all future communication with the endpoint. Instead of preventing negotiation, libspdm instead could just clear the SPDM_GET_CAPABILITIES_RESPONSE_FLAGS_KEY_EX_CAP and PSK_CAP bits from the negotiated response, or set some other flag, to prevent sending secure messages but still allow Challenge, Measurements, etc.

[steven-bellock]

Similar to what is done for the OpaqueDataFmt

libspdm/library/spdm_requester_lib/libspdm_req_key_exchange.c

Lines 328 to 333 in e660843

	if (libspdm_get_connection_version(spdm_context) >= SPDM_MESSAGE_VERSION_12) {
	if ((spdm_context->connection_info.algorithm.other_params_support &
	SPDM_ALGORITHMS_OPAQUE_DATA_FORMAT_MASK) != SPDM_ALGORITHMS_OPAQUE_DATA_FORMAT_1) {
	return LIBSPDM_STATUS_INVALID_STATE_PEER;
	}
	}

the check can be deferred to when KEY_EXCHANGE is initiated.