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

[Justus Winter <[e-mail]>]

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

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

I am advocating for it.  I think it is a reasonably small change which
makes the spec simpler and more consistent, and will reduce confusion
in implementations.

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

That is a good question.  I think in the interest of interoperability,
implementations should generate v4 keys with the legacy OID.

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

That'd be good, I think.  I hesitated to change the curve name, but I
guess it is a symbolic name local to the spec.

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

Yeah.  I'll add the column and more warnings.

Best,
Justus