On Mar 3, 2025, at 3:40 PM, Paul Moore [off-list ref] wrote:

On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg [off-list ref] wrote:

quoted

quoted

On Feb 28, 2025, at 9:14 AM, Paul Moore [off-list ref] wrote:
On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar [off-list ref] wrote:

quoted

On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:

quoted

I'd still also like to see some discussion about moving towards the
addition of keyrings oriented towards usage instead of limiting
ourselves to keyrings that are oriented on the source of the keys.
Perhaps I'm missing some important detail which makes this
impractical, but it seems like an obvious improvement to me and would
go a long way towards solving some of the problems that we typically
see with kernel keys.

The intent is not to limit ourselves to the source of the key.  The main
point of Clavis is to allow the end-user to determine what kernel keys
they want to trust and for what purpose, irrespective of the originating
source (.builtin_trusted, .secondary, .machine, or .platform). If we could
go back in time, individual keyrings could be created that are oriented
toward usage.   The idea for introducing Clavis is to bridge what we
have today with kernel keys and allow them to be usage based.

While it is unlikely that the current well known keyrings could be
removed, I see no reason why new usage oriented keyrings could not be
introduced.  We've seen far more significant shifts in the kernel over
the years.

Could you further clarify how a usage oriented keyring would work?  For 
example, if a kernel module keyring was added, how would the end-user
add keys to it while maintaining a root of trust?