Summary
The libspdm crypto backend function libspdm_x509_verify_cert_chain() only verifies the link of the certificate chain (digital signature).
See https://github.com/DMTF/libspdm/blob/main/os_stub/cryptlib_openssl/pk/x509.c, and https://github.com/DMTF/libspdm/blob/main/os_stub/cryptlib_mbedtls/pk/x509.c.
However, the openssl and mbedtls backend function does not verify CA nameConstraints / pathLenConstraint according to RFC 5280 §6.1 path validation.
Impact
When perform the SPDM certificate chain validation, the libspdm requester only validates the digital signature of the certificate chain, but CA nameConstraints / pathLenConstraint are ignored and not validated.
Scope is limited because: it requires (a) a name/path-constrained multi-tier PKI under the pinned root, (b) an attacker with a valid issuer credential under the constrained node, (c) a measurement policy that identity impersonation alone satisfies.
The root is out-of-band provisioned and byte-pinned, so there is no root-substitution bypass; this issue only lets a certificate already subordinate to the trusted root exceed its constraints.
Configuration
This issue only impacts if the integrate uses the libspdm provided openssl or mbedtls as crypto-backend, and the integrate leverages the libspdm to perform the SPDM certificate chain validation and does not have any other mechanism to perform the SPDM certificate chain validation.
Patches
The fix is to replace link-by-link verification with one full-chain validation so the backend enforces pathlen / name / policy constraints across the whole path.
NOTE: One limitation we notice is that mbedtls does not enforce the nameConstraints (Mbed-TLS/mbedtls#8759). As such, mbedtls path is not fully mitigated. libspdm will leave it to mbedtls community, since it is a known issue since 2024. Once mbedtls resolves then we will update libspdm to close the gap.
libspdm 4.0.0: #3902
libspdm 3.8.3: #3914
References
Reference: https://datatracker.ietf.org/doc/html/rfc5280#section-6.1
007bsd Finder
Summary
The libspdm crypto backend function
libspdm_x509_verify_cert_chain()only verifies the link of the certificate chain (digital signature).See https://github.com/DMTF/libspdm/blob/main/os_stub/cryptlib_openssl/pk/x509.c, and https://github.com/DMTF/libspdm/blob/main/os_stub/cryptlib_mbedtls/pk/x509.c.
However, the openssl and mbedtls backend function does not verify CA
nameConstraints/pathLenConstraintaccording to RFC 5280 §6.1 path validation.Impact
When perform the SPDM certificate chain validation, the libspdm requester only validates the digital signature of the certificate chain, but CA nameConstraints / pathLenConstraint are ignored and not validated.
Scope is limited because: it requires (a) a name/path-constrained multi-tier PKI under the pinned root, (b) an attacker with a valid issuer credential under the constrained node, (c) a measurement policy that identity impersonation alone satisfies.
The root is out-of-band provisioned and byte-pinned, so there is no root-substitution bypass; this issue only lets a certificate already subordinate to the trusted root exceed its constraints.
Configuration
This issue only impacts if the integrate uses the libspdm provided openssl or mbedtls as crypto-backend, and the integrate leverages the libspdm to perform the SPDM certificate chain validation and does not have any other mechanism to perform the SPDM certificate chain validation.
Patches
The fix is to replace link-by-link verification with one full-chain validation so the backend enforces pathlen / name / policy constraints across the whole path.
NOTE: One limitation we notice is that mbedtls does not enforce the nameConstraints (Mbed-TLS/mbedtls#8759). As such, mbedtls path is not fully mitigated. libspdm will leave it to mbedtls community, since it is a known issue since 2024. Once mbedtls resolves then we will update libspdm to close the gap.
libspdm 4.0.0: #3902
libspdm 3.8.3: #3914
References
Reference: https://datatracker.ietf.org/doc/html/rfc5280#section-6.1