Re: [PATCH v2 17/18] spdm: Authenticate devices despite invalid certificate chain

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

On Sun, 30 Jun 2024 21:52:00 +0200
Lukas Wunner <lukas@wunner.de> wrote:

> The SPDM library has just been amended to keep a log of received
> signatures from a device and expose it in sysfs.
> 
> Currently challenge-response authentication with a device is only
> performed if one of its up to 8 certificate chains is considered valid
> by the kernel.
> 
> Valid means several things:
> 
> * That the certificate chain adheres to requirements in the SPDM
>   specification (e.g. each certificate in the chain is signed by the
>   preceding certificate),
> * that the certificate chain adheres to requirements in other
>   specifications such as PCIe r6.1 sec 6.31.3,
> * that the first certificate in the chain is signed by a trusted root
>   certificate on the kernel's keyring
> * or that none of the certificates in the chain is on the kernel's
>   blacklist_keyring.

That "or" seems odd..  Should it be "and"?

> 
> User space should be given the chance to make up its own mind on the
> validity of a certificate chain and the signature generated with it.
> So if none of the 8 certificate chains is considered valid by the
> kernel, pick one of them and perform challenge-response authentication
> with it for the sole purpose of exposing a signature to user space.
> 
> Do not verify that signature because if the kernel considers the
> certificate chain invalid, the signature implicitly is as well.
> 
> Arbitrarily select the certificate chain in the first provisioned slot
> (which is normally slot 0) for such "for user space only" authentication
> attempts.
> 
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> ---
> I'd like to know whether people actually find this feature useful.
> The patch is somewhat tentative and I may drop it if there is no interest,
> so comments welcome!
> 
Code looks fine, but I'm also interested in whether this is useful
to anyone.  It's not something I care about currently.

Jonathan