Re: [openpgp] Weird OIDs in the 4880bis draft

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

On Mon 2023-02-20 19:17:47 +0000, Stephen Farrell wrote:
> On 20/02/2023 19:01, Daniel Huigens wrote:
>> After discussing with Justus, dkg and Stephen, I've added the Curve25519
>> OIDs back into [!242], but marked as legacy (as Justus did in !240).
>> That way, they can still be referenced easily, but we still make it
>> clear that the new algorithm IDs are preferable. This doesn't simplify
>> the spec as much as before, but it's also a less radical change, and it
>> will still simplify greenfield implementations a lot. In a way, I think
>> it's a good compromise between the two MRs. And I believe that it now
>> represents the option we'd both be most happy with :)
>
> Ok, so given the proponents are now happy with this merge
> request can other people please take a look and express an
> opinion on the list as to whether we should make these
> changes now.
>
> Please do so by the end of Wednesday if you can.

With no hats on, I've reviewed the changes proposed in !242 and I am
fine with them.  It's a departure, but not a hugely radical one, and it
offers a *very* simple/clean approach to the use of CFRG curves in any
greenfield OpenPGP implementation.

The one substantive change is see (which Justus also observed [0]) is:

The new structure of X25519 and X448 inputs for KDF are simplified: RFC
6637-style ECDH binds the PKESK to the recipient by including the
recipient key's fingerprint in the KDF inputs, but X* algorithms do not.
So !242's approach means that the X25519 and X448 inputs could
potentially be modified with some sort of proxy "re-encryption" approach
[1], which wouldn't be possible under the RFC 6637 ECDH mechanism.

[0] https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/242#note_1285298560
[1] https://en.wikipedia.org/wiki/Proxy_re-encryption

I'm OK with this change, even though i'm not particularly wild about the
semantics or mental models involved with proxy re-encryption schemes.

RFC 6637 offered no clear justification for including the recipient's
fingerprint in the KDF in the first place, and as Daniel Huigens
observed, anyone interested in confirming who the message was intended
for should be using signed messages and the Intended Recipients
subpacket for that purpose.

There are a handful of cleanups that should probably be done if MR !242
is applied (i noted them on the gitlab issue), but i don't think any of
them are blockers to !242 itself.

And just a final note about the Subject line here: This change does
*not* get rid of the "weird OIDs" at all.  Rather, it acknowledges their
widespread use, and marks them explicitly as legacy OIDs that should not
be used with v6 keys.  I think that's a reasonable outcome for
standardization.

          --dkg