Re: [RFC v3 00/27] lib: Rust implementation of SPDM

[Lukas Wunner <lukas@wunner.de>]

On Fri, Feb 20, 2026 at 10:10:57AM -0400, Jason Gunthorpe wrote:
> IOW the resume/RAS acceptance criteria is that the second nonce was
> signed with the same private key(s) that the first nonce was signed
> with.

What you seem to have in mind is essentially a "trust on first use"
model where trust is given to a specific device certificate
(i.e. leaf certificate), not to a root certificate.

Whereas the SPDM spec (and by extension CMA, i.e. PCIe r7.0 sec 6.31)
envisions a model where each of the 8 slots may contain a certificate
*chain* (comprising a root certificate, optional intermediate certificates
and a leaf certificate).  In this model, trust is given to root
certificates.  These could be vendors, but it's also possible that
e.g. a CSP operates its own CA and provisions one of the 8 slots with
a custom certificate chain anchored in its own CA.

Your "trust on first use" model could be made to fit into the
SPDM model by adding the leaf certificate (= device certificate)
to the .cma keyring and provisioning one of the certificate slots
with just the leaf certificate (and nothing else in the cert chain).
The verifier in user space could add the leaf certificate to the keyring
and provision a slot with it after having verified the device successfully.

That would make verification in user space compatible with RAS & resume,
at least the certificate validation part.

An alternative solution would be to have the verifier in user space
operate its own mini CA.  The root certificate of that mini CA would be
added to the .cma keyring.  Upon successful verification, the verifier
would create a short-lived certificate for the device which is signed
by its mini CA.  The verifier would provision one of the 8 cert slots
of the device with this custom short-lived certificate and thereby
allow the kernel to re-authenticate the device without reliance on
user space until the short-lived certificate expires.  User space
would have to monitor expiration of those certificates and re-new
them to ensure continued re-authentication.

I'm adding Mathieu and Thomas to cc as they have been exploring ways
to take advantage of the .cma keyring for Confidential Computing
use cases.

> Linux will have its own sw model, the spec is just the protocol
> definition. In the CC world everyone just knows the verifier needs to
> be external.. How else could it even work?

There are products out there which support CMA but not TDISP.
In other words, the CC world isn't everything.  The modest goal
of this series is to allow authentication of devices in compliance
with PCIe r7.0 sec 6.31 and the SPDM spec.  I understand there are
features and authentication modes which are important for the
Confidential Computing world, but CoCo needs to fit into the
spec-defined mechanisms.

Thanks,

Lukas