Re: [openpgp] Code-signing in OpenPGP [was: Re: SLH-DSA code points]

[Daniel Huigens <[e-mail]>]

Hi dkg,

On Tuesday, March 26th, 2024 at 18:33, Daniel Kahn Gillmor wrote:
> And the corollary seems to be that if there are multiple secret keys,
> just sign with each of them. I'm proposing to make this the default for
> `sop`, since sop was previously ambiguous about that.

I don't think this really solves your original problem in [1], right?
If you use all keys, the performance is always at least as bad as the
slowest algorithm, and the security is still only as good as the
primary key, at most (since it signs the binding signatures).

My idea was, if you have an SLH-DSA primary key and an EdDSA subkey, you
could use EdDSA for short-lived signatures, and SLH-DSA for long-lived
ones. That way, you have fast signing when long-lived signatures aren't
important, and high security/longevity when needed.

> right, i don't think there's a good UI for this either -- "make
> signature likely to be invalidated sooner" is not an option most users
> will reasonably want to check.

If the tradeoff is between signing performance and signature longevity,
I think there are reasonable scenarios where the user would choose the
former; basically the use cases in your first list in [1].

As a high-level API for choosing an algorithm in both SOP and OpenPGP
implementations, I would propose two axes / parameters: security and
longevity. For example, --security=high could lead to choosing Curve448
instead of Curve25519 (which btw should not be called "low security",
but rather "standard" or so), and --longevity=high could lead to
choosing SLH-DSA (with a security level depending on --security).
This could apply both to key generation, and to signing and encryption
(if an appropriate key is available).

Alternatively, the (default?) longevity could be chosen automatically
based on the expiration date, but then (in the case of SOP) we'd need
to add an API for that first, and it might be nice to keep them separate
since the expiration can always be extended but the algorithm can't be
changed.

Note that security and longevity would be orthogonal to but potentially
affected by the profiles - e.g. --profile=rfc4880 --security=high might
lead to using 4096-bit RSA, and so on. Some combinations might not be
possible, e.g. --profile=rfc4880 --longevity=high could return an error.

---

Finally, to actually solve the original problem using SOP, it would also
need to learn about subkeys, e.g. by inventing generate-{encryption,
signing}-subkey commands. That way, you could put it all together with:

  sop generate-key --longevity=high --signing-only > key1
  # Might generate an SLH-DSA primary key, given an appropriate profile.

  sop generate-signing-subkey --longevity=standard < key1 > key2
  # Might generate an (ML-DSA+)EdDSA subkey, depending on the profile.

  sop sign --longevity=standard/high key2 < msg > sig
  # Select which (sub)key to use.

Not entirely trivial, of course, but hopefully not insurmountable for
an informed user, either.

---

In GopenPGP v3, we've implemented the "security" axis of this proposal,
as documented at [2]. Once we add PQC, we could add the "longevity" axis
too. Note that I'm not proposing that we specify in SOP which algorithm
the implementation should pick in each of the security/longevity/profile
combinations, but rather to pass it along to the OpenPGP implementation
(or, if it exposes an option to choose an algorithm directly, the SOP
implementation could make a judgement call).

Best,
Daniel

[1]: https://mailarchive.ietf.org/arch/msg/openpgp/PTBjyBcrNQwAYvy8HpUc2AFyLM0/
[2]: https://github.com/ProtonMail/gopenpgp/tree/v3#generate-key