Questionable `KEY_UPDATE.VerifyNewKey` behavior

[steven-bellock]

When Requester sends KEY_UPDATE.VerifyNewKey libspdm expects that the previous KEY_UPDATE request be either UpdateKey or UpdateAllKeys. However the specification does not forbid multiple VerifyNewKey operations in a row. Presumably the first VerifyNewKey discards the keys but the subsequent ones are benign.

libspdm/library/spdm_responder_lib/libspdm_rsp_key_update.c

Lines 193 to 200 in bf90209

	case SPDM_KEY_UPDATE_OPERATIONS_TABLE_VERIFY_NEW_KEY:
	if ((prev_spdm_request->header.param1 != SPDM_KEY_UPDATE_OPERATIONS_TABLE_UPDATE_KEY) &&
	(prev_spdm_request->header.param1 !=
	SPDM_KEY_UPDATE_OPERATIONS_TABLE_UPDATE_ALL_KEYS)) {
	return libspdm_generate_error_response(spdm_context,
	SPDM_ERROR_CODE_INVALID_REQUEST, 0,
	response_size, response);
	}

[steven-bellock]

@xiaoyuruan might be able to shed some light.

[steven-bellock]

This was discussed at the SPDM WG meeting today, and libspdm's behavior is considered acceptable.