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

[Paul Wouters <[e-mail]>]

On Fri, 10 Feb 2023, Peter Gutmann wrote:

> Werner Koch writes:
>
>> Actually rfc6637 allows the specification of curves using arbitrary OIDs.
>> FWIW:
>
> Yup, and the original from 2013 was:
>
> -- Snip --
>
>> For completeness, Crypto++ has a factory-like method that serves curves. The
>> curves are sorted by OID in the function, so Crypto++ would need an OID for
>> ed25519.
>
>  { 1 3 6 1 4 1 3029 1 5 1 } ed209^H^H5519
>
> You have been OIDed.  Go forth and encrypt.
>
> -- Snip --
>
> I picked a bit of random unused space, which in any case was for Ed25519 and
> not Curve25519, because there was nothing else available at the time and
> people needed something to play with.  It was never intended to be a
> permanent, standards-track value, it was something I made up (but from a space
> where it was guaranteed not to clash with anything) to help out folks who
> needed an OID.  Until someone pointed me at the RFC I had no idea it was still
> in use.
>
> We now have standard OIDs for this, they're in RFC 8410.  If there are
> implementations out there that use the made-up value then the RFC can include
> a note to say that for historical purposes implementations may encounter keys
> with the ... 1 5 1 OID, but new keys should use the standard OID.
>
> Peter.

Thanks for the clarification Peter.

I think we should use the new OIDs and mention the old OIDs in the draft
for backwards compatibility.

Paul