[openpgp] Profiles in SOP [was: Re: Code-signing in OpenPGP]

[Daniel Huigens <[e-mail]>]

Hi dkg,

On Friday, March 29th, 2024 at 19:11, Daniel Kahn Gillmor wrote:
> If a bunch of different implementations all coalesce around the same
> narrowly-chosen set of profile behaviors for key generation and
> encryption, that would be an interesting outcome.

Looking at the interop test suite results [1], the profiles SOP
implementations have landed on are: (with their meanings for keygen)

- rfc4880: use RSA
- draft-koch-eddsa-for-openpgp-00: use EdDSA & ECDH over Curve25519
- draft-ietf-openpgp-crypto-refresh-10: use Ed25519 & X25519

I.e. only the IETF namespace seems to be used, not the user namespace.
And none of them offer an option to use Ed448 & X448, for example.

So to me it looks like the consensus of the implementations is to use
the profile option to answer the question of "which standard do you
want to follow / what do you want to be interoperable with", and not
"what security level do you want" or "what's your use case" or anything
like that - though perhaps we should indeed change that, more on that
below.

I would argue that it's the application that should answer that first
question (because it knows whether it's a greenfield deployment and
whether it should care about interoperability), and so the choice of
profile shouldn't really be presented to an end user at all, as it's
currently implemented.

Instead, the questions the options I proposed (--security & --longevity)
would answer are "how secure do you want your artifacts to be" and
"how long do you want your artifacts to be secure for", respectively.
And those are potentially closer to being answerable by an end user.

>From your email, it sounds like the question you want(ed?) --profile to
answer is more like "what's your use case", perhaps? With options like

- lightweight@...: for daily emails, git commits, etc.
- heavyweight@...: for announcement emails, git tags, tarballs, etc.

(adapted from your first email) - which probably is indeed even better.
But to me, this still seems somewhat orthogonal to the question of
"what do you want to be compatible with". E.g. you might want to create
high-security/longevity artifacts while also caring about interop
(although you can't always have everything, ofc); or you might be in a
greenfield deployment. So, given the current use of --profile, I think
it might make more sense to create a separate parameter for that.

---

All of that being said, before --profile was added, my position was
that the current use of --profile (i.e. to select a standard to follow)
should be covered either by an env variable or by having different
variant of the sop binary, e.g. you could have gosop-crypto-refresh
and so on. That way, it's more clear that it's something that should be
selected by the application (or for testing only) rather than the user.

And, it's arguably also a variant of the SOP standard (not just its
implementation), since the SOP spec references RFC4880 explicitly - so
if `sop generate-key --profile=draft-ietf-openpgp-crypto-refresh-10`
generates a v6 key, that's technically not compliant with SOP, which is
a bit surprising. So, a variant of the binary could claim to implement
a variant of SOP (which would refer to the crypto refresh instead).

The profile could then refer to a set of preferences within that spec;
e.g. "high-security" for Curve448, "performance" for Curve25519, and
"compatibility" for RSA (though to be pedantic this would still refer
to RSA as specified in the crypto refresh, i.e. at least 3072 bits,
while the variant using RFC4880 could technically generate 2048-bit
keys, although probably it shouldn't) and a different set of profiles/
algorithms for the other variants/specs.

Perhaps we could still do that; but then, I would propose to drop the
IETF namespace, and also drop the requirement for an @domain after the
user space profiles - every profile name would just be specific to the
variant & implementation by definition.

But, perhaps that ship has sailed? If so, we could also give this
concept a different name, of course.

Best,
Daniel

[1]: https://tests.sequoia-pgp.org/#versions