In device sample, assoc_cert_slot_mask not consistent with slot certs or DIGESTS per-slot KeyPairID #3638

Location: os_stub/spdm_device_secret_lib_sample/key_pair.c
(libspdm_init_key_pair_info, the m_key_pair_info[index].assoc_cert_slot_mask
assignments) versus library/spdm_responder_lib/libspdm_rsp_digests.c:155 and
the emu configuration in
spdm-emu/spdm_emu/spdm_responder_emu/spdm_responder_spdm.c:566–:569.

Spec basis: The key-pair⇄slot association is a single device property viewed
from two messages, and the two views must agree:

• KEY_PAIR_INFO.AssocCertSlotMask (Table 111, §3346) — "a bit mask
  representing the currently associated certificate slots" for a given
  KeyPairID.
• DIGESTS.KeyPairID[slot] (Table 9, lines 1473/1475) — "shall be the
  KeyPairID of the key pair associated with … CertSlot[slot]", present when
  MULTI_KEY_CONN_RSP is true.

These are inverse mappings of the same relation, so for every slot X,
DIGESTS.KeyPairID[X] must equal the KeyPairID whose AssocCertSlotMask has
bit X set, and that key pair's CurrentAsymAlgo must match the algorithm of the
certificate actually installed in slot X.

What the sample/emu actually do — three independent, contradictory sources:

1. KEY_PAIR_INFO (HAL table). Each key pair is mapped to one distinct slot
   via a single-bit mask whose bit index equals KeyPairID - 1, and each key
   pair carries a different CurrentAsymAlgo:

   KeyPairID	CurrentAsymAlgo	assoc_cert_slot_mask	→ slot
   1	RSA2048	0x01	0
   2	RSA3072	0x02	1
   3	RSA4096	0x04	2
   4	ECC256	0x08	3
   5	ECC384	0x10	4
   6	ECC521	0x20	5
   7	SM2	0x40	6
   8	Ed25519	0x80	7
   9 / 10–12	Ed448 / ML-DSA	0x00	none

2. DIGESTS (responder). libspdm_rsp_digests.c:155 fills each slot's
   KeyPairID from local_context.local_key_pair_id[slot], a separate array.
   The responder emu sets it to 0xA0 + slot_index
   (spdm_responder_spdm.c:566–:569); the requester emu uses 0xB0 + slot_index.
   Unset, it defaults to 0.

3. Slot certificate contents. Every populated slot holds a certificate chain
   for the single negotiated algorithm (e.g. all ECC384 in a typical run), and
   the emu reports CertificateInfo = DeviceCert for each.

The contradictions:

• For slot 3, KEY_PAIR_INFO claims KeyPairID 4, while DIGESTS reports
  KeyPairID 0xA3 — the two never match (and 0xA0–0xA7 are not even valid
  indices into the 1-based key-pair table, which only has IDs 1–12).
• KEY_PAIR_INFO claims slot 3 ↔ ECC256, slot 0 ↔ RSA2048, etc., but the
  certificate physically installed in those slots uses the negotiated algorithm,
  not the per-key-pair algorithm the table asserts.
• The mask only covers slots 0–7 by aligning bit = KeyPairID − 1; key pairs
  9–12 (Ed448, the three ML-DSA PQC pairs) get 0x00, so they are reported as
  associated with no slot at all.

Assessment. The literal values (e.g. 0x08) are format-legal under
Tables 111/112 — each is a valid single-bit mask, and because every sample key
pair sets SPDM_KEY_PAIR_CAP_MASK (which includes ShareableCap), even
multi-bit masks would be permitted. GET_KEY_PAIR_INFO is also defined to report
key-pair data "independent of any negotiated parameters" (§3314), so the handler
returning this canned data is conformant in isolation, and the unit tests (which
check one message at a time) pass.

The defect is device-model fidelity, not message-handler conformance: a
Requester that correlates KEY_PAIR_INFO.AssocCertSlotMask with
DIGESTS.KeyPairID[] and the installed certificates — exactly what the multi-key
feature exists to enable — sees three mutually inconsistent answers. Severity is
Low (sample/emu fixture data, no library "shall" violated), but it makes the
sample unsuitable as a reference for the association semantics and can mislead
integrators.