Clarification on duplicate SMDataID elements and secured message version negotiation #3934

Hello,

We are testing KEY_EXCHANGE requests containing multiple opaque data elements and would like to clarify how duplicate SMDataID values should be handled.

In our test, multiple DMTF opaque elements have the same ID (0x00), VendorIDLen (0), SMDataVersion (0x01), and SMDataID (0x01, supported secured message versions). Each element contains a SecuredMsgVers structure with one version in its VersionsList.

In an earlier libspdm-based integration, the request was accepted and the last matching element was used. After an update, the first matching element was used instead. The current main implementation of libspdm_get_sm_data_element_from_opaque_data() also appears to return the first matching element.

We have two questions:

1. Should duplicate SMDataID elements be rejected?

Within the same DMTF opaque data namespace and SMDataVersion, is it valid for a single KEY_EXCHANGE request to contain multiple elements with SMDataID = 0x01?

If this is not allowed, should the responder reject the request, for example with InvalidRequest, rather than use the first or last matching element?

2. If duplicates are allowed, are these two representations equivalent?

The following examples are schematic; lengths and padding are omitted. All elements use the common header values described above.

Case A — One element containing multiple versions:

TotalElements = 1
OpaqueList:
  - SMDataID = 0x01
    SecuredMsgVers:
      VersionCount = 2
      VersionsList = [1.2.0, 1.1.0]

Case B — Multiple elements with the same SMDataID, each containing one version:

TotalElements = 2
OpaqueList:
  - SMDataID = 0x01
    SecuredMsgVers:
      VersionCount = 1
      VersionsList = [1.2.0]
  - SMDataID = 0x01
    SecuredMsgVers:
      VersionCount = 1
      VersionsList = [1.1.0]

Thank you.