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

[Daniel Kahn Gillmor <[e-mail]>]

Hi Daniel--

On Wed 2024-04-03 10:45:32 +0000, Daniel Huigens wrote:
> 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

agreed, these are the current profiles for generate-key that
implementers have offered so far.

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

I'd welcome those profiles :)  I suspect some implementation just needs
to lead by example.

fwiw, my intent behind the profiles was never to deliberately expose
them to the user.  Rather, it was to provide a little bit of flexibility
for implementations that they could use as discretion to nudge other
implementations for interop testing.

For example: a simple test would be to create a key with each profile
offered by each implementation, and then confirm whether the other
implementations could consume it.

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

Any sensible user will answer these questions with "as secure as
possible" and "as long as possible", so these are not helpful questions
to ask.  Without knowing what is being traded off (CPU time to generate,
CPU time to consume, wire format space, likelihood of interop failures
in today's environment, etc), it's nearly impossible for a user to make
these choices.

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

This would at least give some vague sense of what the tradeoffs are, but
maybe not all of them (e.g. i don't know how much it describes
present-day interoperability).  My main preference is to avoid punting
any of this to the user, or even to the application, as much as
possible.

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

The different variants of the sop binary do of course have different
profiles by default.  The profile mechanism present in the draft allows
the creation of a single sop binary that can make *some* discretionary
choices, but tries to nudge implementers to make a narrow range of
likely-useful choices, rather than throwing up their hands and saying
"let the user have access to a full airplane cockpit", which is a
pattern that i've observed being actively harmful for interoperability
and usability.

With the different profiles, a single implementation can also signal an
interest in an upcoming approach, and encourage interop with it, without
committing to it as the default behavior.

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

fwiw, the sop draft will certainly be updated to reference the RFC when
the crypto-refresh is released.  There are some minor changes that will
need doing there (e.g. the definition of SESSIONKEY needs updating to be
able to represent sense of v6 ESK), but i hope any sop implementer will
actively identify any potential problems, and propose fixes that seem
reasonable.

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

Every implementation can already make up their own profile names.  I
also want a shared namespace so that implementations can coalesce around
consensus standards.  I don't really see that changing the syntax or
semantics of profiles would help to achieve either of those goals.

Maybe implementers just need to start exercising them?

Thanks for the thoughtful discussion on this!

          --dkg