[openpgp] Re: Persistent Symmetric Keys: new algorithms or new packets?

Hello Daniel, all,

apologies also for a late reply.
I'll go over the set of questions that I see:


1. Reuse key packets types?

I prefer new key packet type(s) for persistent symmetric keys.

Falko suggests that we should introduce a new packet when receiving 
implementations might deal poorly with a new feature wrapped in an 
existing packet type (heavily paraphrased).
I think that's a good starting point, but insufficient. In addition I 
propose: "We should add a new packet type, if extending an existing 
packet type for a new concept/behavior/feature is likely to make even 
reasonably well-designed implementations (sending or receiving) messy".

I believe that reusing the existing key packet(s) for symmetric 
persistent keys is nice for draft-writing, but fundamentally 
not-so-great for implementations (as has been pointed out previously):

- Re-using the existing secret key packet types undermines library-layer 
typing that can currently encode, for example, that encryption 
operations use a public key packet.
- It introduces password unlocking into workflows and APIs that have so 
far not needed to deal with it.
- It breaks the assumptions that it's possible and meaningful to derive 
a public key packet from a secret key packet.

Implementations with strong typing will want to model persistent 
symmetric keys as a separate type of object.
It would seem cleaner to me if the wire format also used this modeling.

I expect that modeling symmetric persistent keys as a separate packet 
type will lower the risk of dangerous mistakes both within libraries, 
and in the resulting library API surface.

(Relatedly, I assume that conflating asymmetric keys and persitent 
symmetric keys in one shared concept/packet type would make it harder 
for people to learn OpenPGP, as application developers.)


2. Reuse PKESK packet?

Reusing the existing PKESK packet with novel persistent symmetric key 
packets seems acceptable to me.
I don't think reusing the PKESK is likely to introduce footguns in 
libraries (let alone problems on the receiver side).

Adding a separate "persistent symmetric key ESK" type does feel a bit 
wasteful, but I don't have strong feelings one way or the other.


3. Do we need "Symmetric signatures" (and if yes, how?)?

The discussion seems to lean towards "yes". I support specifying such a 
mechanism in this draft.

That means we'll produce "symmetric signatures", either as the existing 
signature packet type, or as a new "symmetric signature packet" type 
(Falko suggested the idea of a new "mac packet" type).

A new signature packet type (such as a "mac packet") feels excessive to 
me, as a first reaction.
Signature packets in OpenPGP already have very non-uniform semantics, 
and I'm not convinced that adding a new packet type for "symmetric 
signatures" will clarify things meaningfully.

My current preference would be to reuse the existing signature packet.


4. Algorithm ID namespace(s)

I favor adding two explicit values to the "Public Key Algorithms 
Registry", as the draft currently does.

As long as symmetric persistent keys are used with either the existing 
PKESKs or Signature packets, some algorithm id needs to be set in those 
packets. Using the special value "0" doesn't seem like a good solution 
to me.

Alternatively, if we end up using new variants for every packet that 
interacts with symmetric persistent keys (i.e.: new key packet, new 
signature packet, new ESK packet), then we would presumably start a new 
"Persistent Symmetric Key Algorithms Registry". In this case, the two 
classes of algorithms would be entirely separate.
I do find this idea a little compelling, but I don't think the benefits 
of that approach justify the overhead.


5. Transferable Persistent Symmetric Keys

I'd strongly prefer not to extend the TSK grammar to allow including 
persistent symmetric key packets.


Instead I'd prefer that we define a new and separate grammar for 
"transferable persistent symmetric keys" (TPSK), which allows exactly 
one persistent symmetric key packet per TPSK (i.e. a TPSK consists of 
exactly one key packet, without any signatures or subpackets).


Specifying more complex composite TPSKs (that include signatures and 
potentially multiple key packets) could have two benefits:

- Binding signatures allow inclusion of metadata (Bart mentioned that he 
finds it appealing to have that option).
- Binding signatures allow the keyholder's software to check that the 
subkeys are legitimate, as long as the software knows that the primary 
key is the right one.

However, I'm very unconvinced that either of those two potential 
benefits are worth the complexity of composite TPSKs.

Thanks and regards,
Heiko


On 7/22/25 6:31 PM, Daniel Huigens wrote:
> Hi folks,
>
> In anticipation of the meeting session on Friday, I wanted to pose the
> following question to the group:
>
> I got some feedback in private regarding the persistent symmetric keys
> draft, which came down to two points:
>
> 1. Reusing and renaming the packets may cause some confusion and
>     complexity.
> 2. Given that AEAD offers integrity, do we really need HMAC?
>
> Taken together, this would lead to an alternative proposal, of defining
> two new packets:
>
> 1. Persistent Symmetric Key Packet
> 2. Persistent Symmetric Key Encrypted Session Key Packet
>
> These could then be used to store a symmetric key, and symmetrically
> encrypt a session key using that key. This would still lead to some
> duplication (of the Secret Key and Public Key Encrypted Session Key
> packets, respectively) but a bit less than if we also had to duplicate
> the Signature packet, for example.
>
> And then, even if you mainly wanted to provide integrity you would just
> also encrypt the data.
>
> We could then define a new Transferable Persistent Symmetric Keys
> grammar, that consists of just a Persistent Symmetric Key Packet.
> Unlike Transferable Private Keys, they cannot be converted into
> Transferable Public Keys.
>
> You then also can't make self-signatures, which means you can't set
> metadata on a TPSK, such as a validity period (unless we encode it in
> the packet directly, v3 style), but maybe it's not really needed and
> can be stored externally by the application if necessary.
>
> This would arguably simplify the proposal and more clearly delineate
> the semantics. However, it would also make persistent symmetric keys
> less similarly-shaped to other keys, which may make them harder to
> work with.
>
> For example, I think it can be useful to store a persistent symmetric
> key together with a private key, and use it automatically when
> encrypting to yourself. Though, perhaps this could also be handled
> by the application.
>
> Obviously it's also a bit late to make such a drastic change.
> However, if the WG prefers this, I can update the draft.
>
> Let me know what you think. And, we can discuss more on Friday :)
>
> Best,
> Daniel
>
> _______________________________________________
> openpgp mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]