GET_KEY_PAIR_INFO/KEY_PAIR_INFO Permissive Minimum-Size Validation Tolerates Trailing Data

[czwolak]

Description:
Requester validation for KEY_PAIR_INFO is minimum-size oriented and parses required fields, but does not enforce exact full-message parsed-size equality, allowing trailing bytes to be tolerated.

Observed Behavior

Validation checks mostly use >= minimum required sizes.
SPDM 1.4 extension fields are validated for minimum presence.
Extra trailing data can remain accepted if mandatory fields parse correctly.
Expected Behavior
Requester should enforce exact parsed-size match for full KEY_PAIR_INFO layout and reject trailing bytes beyond defined structure.

Impact

Compliance strictness gap in parser behavior.
Potential interoperability ambiguity with non-canonical message encodings.
Severity
Low-Medium (strictness/compliance issue, non-security by itself).

Suggested Fix
After parsing complete layout, require exact size equality with message length and reject extras as invalid size/field. Add UT with syntactically valid payload plus trailing bytes.

Present in Release 3.8.2
Yes, core permissive behavior is also present there.

[steven-bellock]

Requester should enforce exact parsed-size match for full KEY_PAIR_INFO layout and reject trailing bytes beyond defined structure.

This is probably true for many messages. Note that exact checks are only possible within a secure session. Outside a secure session there may be transport alignment and padding issues that prevent exact checks.

[jyao1]

Why we need exact full message-size check? Which spec language requires that?

[czwolak]

Thanks for the clarification.

I do not currently point to a specific SHALL that universally mandates rejecting all trailing bytes for this case.
My intent was to avoid accepting unparsed payload tail in variable-length parsing paths.

Based on your suggestion, I propose one scoped change only: exact-size checks for secure-session parsing paths.
For non-secure paths, we reviewed this and it is risky (as you noted), so I do not recommend strict trailing-byte rejection there.

If we don’t want to broaden this into a larger hardening sweep across multiple messages, I suggest we close this issue.

Messages that could reasonably get an exact-size check in secure session paths:

• GET_CSR / CSR
• GET_MEASUREMENTS / MEASUREMENTS
• GET_MEASUREMENT_EXTENSION_LOG / MEASUREMENT_EXTENSION_LOG
• VENDOR_DEFINED_REQUEST / VENDOR_DEFINED_RESPONSE
• GET_ENDPOINT_INFO / ENDPOINT_INFO (especially the no-signature branch)
• GET_CERTIFICATE / CERTIFICATE (if used over secure session in your profile)
• GET_DIGESTS / DIGESTS (if allowed over secure session in your profile)

Messages that already look good (strict size validation already present):

• HEARTBEAT / HEARTBEAT_ACK
• KEY_UPDATE / KEY_UPDATE_ACK
• END_SESSION / END_SESSION_ACK
• PSK_FINISH / PSK_FINISH_RSP