[openpgp] Re: "TSK grammar" update in persistent symmetric keys

[Daniel Huigens <[e-mail]>]

Hi dkg,

The intention of the draft was to say that a PSK packet by itself can
constitute a single TSK, _but_ that it can also be combined with an
asymmetric TSK into a sequence of TSKs.

However, I indeed misremembered what RFC9580 said on the matter and was
under the impression that the TPK and TSK grammars themselves already
allowed multiple primary keys, for example. They don't, but it does say:

> Transferable Public Key packet sequences may be concatenated to allow
> transferring multiple public keys in one operation (see Section 3.6).

So in essence it specifies a secret additional grammar "TPKs := TPK..."
(and since TSKs are defined by analogy to TPKs, it seemed natural to me
to allow having multiple of them, as indeed sop does but our libraries
have supported that even before then). And for the migration to v6, we
in fact need that grammar even more, and now for persistent symmetric
keys as well. So, I do think it would be worth specifying that grammar
somewhere.

_But_ arguably that's wholly orthogonal to PSKs, and the PSK draft
should just say that a single PSK packet is also a valid TSK, and/or
provide an updated complete grammar. In any case I'll try to clarify
this. Thanks for raising it!

Best,
Daniel


On Tuesday, August 25th, 2026 at 21:33, Daniel Kahn Gillmor <[e-mail]> wrote:

> Hey folks--
>
> (this is with no hats on, just as an interested reviewer)
>
> I just read through draft-ietf-openpgp-persistent-symmetric-keys again
> and i'm struck by this section:
>
> > The Transferable Secret Key grammar defined in section 10.2 of
> > [RFC9580] is extended to allow including Persistent Symmetric Key
> > Packets. Persistent Symmetric Keys may be included together with
> > asymmetric keys in a single sequence of Transferable Secret
> > Keys. However, Persistent Symmetric Keys do not accept subcomponents,
> > such as subkeys, User IDs, or direct-key signatures.
>
> I think "is extended to allow" is not clear. Does it "allow" them as a
> subkey for an existing primary key (for example)? Does it allow them
> only in place of a primary key? If it allows them in place of a primary
> key, but direct-key signatures are not allowed, doesn't that make the
> whole grammar invalid, since a direct-key signature from the primary is
> required for the TSK?
>
> I see (at least) two different ways to resolve this:
>
>  - provide an explicit grammar (at least as explicit as the v6
>    certificate grammar) for TSKs that includes PSK packets, or
>
>  - define a new "sequence of packets" specifically for PSKs, which could
>    be as simple as the grammar for detached signatures.
>
> Also, i don't know that RFC 9580 really gets into the idea of a
> "sequence of Transferable Secret Keys". section 10 of 9580 seems to talk
> about a series of packets which are to be interpreted as a TSK, but it
> doesn't really go into detail about sequences of TSKs themselves. This
> is in contrast to SOP's KEYS object which does contemplate such an
> object.
>
> How do folks think this should be resolved? Or is there actually not a
> problem here, and i'm just confused?
>
> I've opened an issue in the issue tracker about this as well, if folks
> would rather follow up there:
>
> https://gitlab.com/twisstle/openpgp-persistent-symmetric-keys/-/work_items/4
>
> Regards,
>
>         --dkg
> _______________________________________________
> openpgp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]