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

[Chuck Lever]

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.


-- 
Chuck Lever