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

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

On Fri 2023-02-17 19:13:57 +0100, Justus Winter wrote:
> Stephen Farrell <[e-mail]> writes:
>
>> That said, if someone were to create a merge-request
>> in the next day or two with a suggested change, and
>> if we see a clear WG consensus for that specific change,
>> then that could just about make it into the next rev.
>
> Here you go:
>
>   https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/240
>
> The gist is:
>
>   Use x509's OIDs for Ed25519 and X25519, see RFC8410.
>
>   Also, use the opaque signature wire format for Ed25519, and opaque
>   secrets for X25519.
>
>   Keep the currently used OIDs for compatibility with v4 key material.
>   Forbid its generation in v6 material.

Thanks for writing this up, Justus.

Are you advocating for it, or are you just providing it as a point of
discussion?  Is anyone on this list advocating for it?

This proposed change includes two entries for Ed25519 in the
#ecc-oid-usage table, one of which is marked "v4 only", and the other is
not marked any way at all.  Does this mean that the newly introduced
variant is allowed/encouraged when generating v4 keys, or should it only
be used in v6 keys or later?  I imagine most implementations will
generate v4 keys by default for a while after this draft comes out.  If
they're generating a 25519-based key, will they know which forms to
choose?

Would this change be clearer if it introduced a variant name for the
deprecated form of Ed25519, to make it clear that it is distinct?

For the adjustments to the tables, does it make sense to have a
parenthetical "v4 only" and "deprecated", or should there instead be a
new column marked explicitly for this kind of deprecation?  Having a
distinct column might make it easier for an implementer to make sense of
these things.

I imagine that an implementer who doesn't know the history here could be
pretty confused about what to do, and i'd hope that anyone advocating
for these changes would try to make them as clar as possible.

    --dkg