Re: [PATCH 2/9] handshake: Add tags to "done" downcall

On 6/5/26 19:34, Chuck Lever wrote:
> From: Chuck Lever <[email protected]>
> 
> 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 <[email protected]>
> ---
>   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
[email protected]                                +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