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

On 6/9/26 16:29, Chuck Lever wrote:
> 
> On Tue, Jun 9, 2026, at 2:41 AM, Hannes Reinecke wrote:
>> On 6/5/26 19:34, Chuck Lever wrote:
>>> 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.
> 
>> 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?
> 
> Had some time to digest your comment a little more...
> 
> The tag attribute is declared "multi-attr: true", so it is already a
> list rather than a single delimited string. tlshd emits one
> HANDSHAKE_A_DONE_TAG attribute per tag, and the kernel receives each
> tag as a separate netlink attribute. There is no string to split in
> the consumer; the parsing you are worried about does not happen.
> 
> This matches remote-auth directly above it, which is likewise a
> multi-attr scalar list in the same DONE message.
> 
> A nested attribute earns its keep when each list element is a
> structured record with several sub-fields to group. A tag is a single
> string, so nesting would add a container attribute, a second
> attribute-set, and a nested policy without making anything on the
> consumer side simpler. If a tag later needs to carry structured
> metadata, nesting becomes the right tool, but that is not in scope for
> this series.
> 
Ah. So one can have several 'tag' attributes in one 'done' downcall?
That's perfect.

So you can add my:

Reviewed-by: Hannes Reinecke <[email protected]>

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