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

[Heiko Schäfer <[e-mail]>]

Hello Daniel, list,

this is going to contain slight duplications with my previous mail, 
apologies.

> 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
>     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

To recap, for Persistent symmetric keys (B), I argued in favor of B3.

New key packet (but reuse Signature packet, and probably also reuse the 
PKESK packet).

As I argued, I think persistent symmetric key packets are sufficiently 
different from asymmetric ones that reusing the existing key packet is 
more trouble than the reuse is worth.

I argued for using explicit Algorithm IDs. Presumably two, with no huge 
prospect of that number growing much, or at all.



Regarding Forwarding (A), I prefer A1 (or alternatively A3).

Either way, I'd prefer to reuse the key packet here:

I don't think there's much danger of footguns or excessive burden on 
implementations in reusing the existing secret key packets for 
forwarding keys.
The conceptual difference to "normal asymmetric private keys" is smaller 
than with persistent symmetric keys.

In particular, the failure mode for misusing Forwarding keys is less 
severe. I don't see additional risk for users making dangerous mistakes 
around forwarding keys (I'd judge them as similar to, but less dangerous 
to mishandle than "normal" secret keys).

Signalling the specific intended use of a forwarding subkey via a Key 
Flag (as opposed to with a separate packet type) seems in line with 
existing practice, to me.


For both Forwarding and Persistent symmetric keys I have no strong 
feelings between re-using the PKESK or adding a new type of ESK packet.
However, in both cases, I'd default to re-using the PKESK.


I think the most serious reason for new packet types for Forwarding 
would be if we worry about needing many new entries in the Public Key 
Algorithms Registry. But I don't think that's a serious concern.


To quantify the Public Key Algorithms Registry status quo:

- In RFC 9580 the highest entry in the registry is 28 (but the IDs are 
not densely used)
- draft-ietf-openpgp-pqc-12 uses 30-36,
- draft-ehlen-openpgp-nist-bp-comp (as presented at IETF 123) envisions 
using another 10 code points.

So a grand total of well under 50. Even if we ended up specifying, say, 
20 forwarding algorithms in the Public Key Registry over the next decade 
(which seems like a very generous upper bound), that would not seem 
prohibitive to me.

My conclusion is that there is no strong argument for introducing a new 
ESK type for either of the two formats.


Thanks, regards,
Heiko