On 6/5/26 19:34, Chuck Lever wrote:

From: Chuck Lever <chuck.lever@oracle.com>

We'd like tlshd to tag certificates according to admin-defined
characteristics. The tag list is to be returned on a successful
handshake. Upper Layer Protocols (such as NFS) can then authorize
access based on the set of tags returned to the kernel.

For example, suppose NFSD wants to restrict access to an export to
only clients that present certificates whose issuer DN contains
"O=Oracle". tlshd can parse incoming certificates, and add an
"oraclegroup" tag to handshakes where a client presents a
certificate with "O=Oracle" somewhere in its Issuer field. NFSD can
then be configured to look for that tag and permit access only when
it is present. NFSD needs no knowledge of x.509 certificates.

This patch plumbs in the netlink protocol elements for tlshd to
return a list of tags to the kernel when a TLS or QUIC handshake
succeeds. Subsequent patches add tag extraction and storage in
the handshake layer.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
  Documentation/netlink/specs/handshake.yaml | 11 +++++++++++
  include/uapi/linux/handshake.h             |  3 +++
  net/handshake/genl.c                       |  5 +++--
  3 files changed, 17 insertions(+), 2 deletions(-)

Not sure if I agree with this; to my untrained eye the 'tag' attribute 
is just a string, and someone else will have to parse that. But we
are at the netlink level here, so we _can_ have nested tags.
Wouldn't it be better to make 'tags' a nested tag (ie a list of tags)
such that we can avoid parsing in the caller/consumer?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich