[openpgp] Re: Algorithms vs packets in forwarding and PSK

Hi Daniel,

Am 19.08.25 um 16:27 schrieb Daniel Huigens:
> Hi all,
>
> Last month we had two parallel threads about whether to define new
> algorithms or new packet(s) in the forwarding and persistent symmetric
> keys drafts.
>
> My informal impression is that the direction folks are leaning in is
> to define new algorithms for forwarding, and a new key packet for
> persistent symmetric keys (but reuse the other packets).

 From my point of view, there should be a guiding paradigm behind the 
all those decisions. I would suggest this paradigm:

"Define a new packet whenever the receiving side has to process it in a 
way that isn't already covered by an existing packet type that could be 
used."

This seems a useful guideline to me, since for an implementer, the 
producing side is less prone to be subject to processing errors when 
packets are reused, for the following reasons:

- The implementation obviously supports the feature in question, 
otherwise it couldn't produce the packets.
- When using the new feature to produce packets, the implementation does 
so "knowingly".

The consuming side however might not implement the new feature or do so 
in a limited or (erroneously) incompatible way. In such a case it is 
some kind of first line of defence that the packets using the new 
feature aren't erroneously processed according to the pattern of the 
established packets.

>
> Yesterday I had a call with Aron and we both agreed that it would look
> slightly strange to be inconsistent here, though we didn't reach a
> conclusion beyond that, so we thought we'd ask the WG again to make
> sure :)
>
> We basically have a 3x3 grid of options:
>
> A) Forwarding
>     1. Define new algorithms; reuse private key and PKESK packets
>     2. Define a new key packet and a new FKESK packet

It seems to me that applying the above paradigm to forwarding, A2 should 
be the choice: The private keys that users hold cannot be handled like 
normal private keys, since they are specific to the communication with 
one peer (Alice in the Figure in Sec. 4 in the forwarding draft 
<https://datatracker.ietf.org/doc/html/draft-wussler-openpgp-forwarding-00#name-description-of-the-protocol>). 
Specifically, [1] says

"An implementation SHOULD keep the forwardee key separate from the 
generic keyring, and associated to a specific forwarding instance instead."

Thus it seems reasonable to define new private key packets to prevent 
any confusion.

According to Sec. 7 of [1], the decryption process is also special and 
thus deserves a new packet type.

>     3. Define a new FKESK packet, reuse the private key packet
> B) Persistent symmetric keys
>     1. Define new algorithms; reuse private key, PKESK and signature
>        packets
>     2. Define all new packets
>     3. Define a new key packet, reuse other packets, also define new
>        algorithms or the special value 0

For symmetric keys I come to yet another result if I apply the paradigm:

- reuse private key: in my view private keys can be used just like for 
asymmetric algorithms
- reuse PKESK: it can be processed by the recipient in the same manner 
as for asymmetric algorithms
- define new public key packets, since they can't be used for encryption 
or signature verification
- define new "MAC" packets: a MAC (or the authentication feature of 
AEAD) is not equivalent to a public key signature. It doesn't provide 
non-repudiation. Further, any user from a group that shares the same MAC 
key can forge "signatures" for any member of the group. Accordingly, as 
I argued in my review [3] of [2], receiving clients might have to treat 
MACs different than public-key signatures when displaying messages. This 
seems to suggest that new packet types are needed.

>
> (When reusing packets, we should probably introduce new key flags,
> to be able to distinguish the uses of the key.)
Whether key flags are an alternative to defining new packet types in 
some cases should be decided based on the typical/established uses of 
key flags. I lack overview here so I leave that for discussion.
>
> Of course, there are some semantic differences between forwarding and
> persistent symmetric keys, that could potentially lead to a different
> decision making sense for both.
>
> In particular, for forwarding:
> - The key can be used to decrypt forwarded messages, but not encrypt
>    directly (only via the forwarding parameter)
> - The key parameters are the same as those of existing algorithms for
>    all algorithms we care about, though this may not always be the case
> - The message parameters are the same plus some additional ones
>
> For persistent symmetric keys:
> - The key can be used to encrypt and decrypt, or "sign" and "verify",
>    respectively
> - The key parameters are new
> - The message parameters are also new
>
> In both cases, there's no corresponding public key.
>
> For those that have followed or are interested in both discussions,
> please let us know what your preferred option is. If your preferred
> option differs between the two drafts, please also indicate which
> factor makes you prefer a different outcome :)

I hope I have made clear the paradigm behind my suggestions. But 
certainly there will be room for discussion about the paradigm and the 
conclusions drawn from it.

Best regards,
Falko

[1] A. Wussler: "Automatic Forwarding for ECDH Curve25519 OpenPGP 
messages", 
https://datatracker.ietf.org/doc/html/draft-wussler-openpgp-forwarding-00

[2] D. Huigens: "Persistent Symmetric Keys in OpenPGP" 
(draft-ietf-openpgp-persistent-symmetric-keys-01), 
https://datatracker.ietf.org/doc/draft-ietf-openpgp-persistent-symmetric-keys/

[3] Falko Strenzke: "[openpgp] review of 
draft-ietf-openpgp-persistent-symmetric-keys-01", 
https://mailarchive.ietf.org/arch/msg/openpgp/GFyWs5EX62dsenHGGMcuiTHPURw/

>
> Thanks!
>
> Best,
> Daniel
>
> _______________________________________________
> openpgp mailing list [email protected]
> To unsubscribe send an email [email protected]
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: +49 6151 8000 24
E-Mail: [email protected]
Web: mtg.de <https://www.mtg.de>

------------------------------------------------------------------------

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If 
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised 
copying or distribution of this email is not permitted.

Data protection information: Privacy policy 
<https://www.mtg.de/en/privacy-policy>

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