For EdDSA we need a new RFC to have the IANA assign a new algorithm id.
While doing that we should also address two questions:
1. Shall we keep the OID field or shall we replace it with either a
curve size parameter or maybe assign a single algorithm identifier
for Ed25519/EdDSA?
OIDs are just unique constants. It's quasi-IANA governed. Getting an OID is
easy as long as you have a base OID from the IEEE. I've gotten OIDs for a
number of organizations, and once you have one, you just put your own off of
that.
So suppose they give you [1.2.3.4]. All you need to do is make
[1.2.3.4.x.y.z...] for your own OIDs for whatever purpose.
If you look at <http://www.oid-info.com/faq.htm>, particularly question 10,
there are easy ways to get one. There are suggestions that include how to get
an OID from IANA, and also how to use a UUID as an OID.
2. Does the use of MPIs make sense? Bernstein defines the key as well
as the signature material as octet strings and not as MPIs.
As you've noted, in RFC 6637, Andrey codes an EC point into an MPI, which I
think is clever, and works fine. Why not just do it?
A reason to drop the OID field would be smaller key material which may
help with key backup or direct use of the key. However, it complicates
parsing because we would need two methods. I am fine with the OIDs
(after all I suggested them) because for key backup we can use our own
format. Such a format should be URI encoded for use in QR codes anyway.
That's a good argument for not using a UUID, because it's going to be over 16
bytes long. But you can go to IANA for an OID, or get your own OID base and
then just issue one from there.
Of course we could informally agree on an algorithm id for EdDSA, as we
always did in the OpenPGP WG. However, a new algorithm id is not
sufficient as long as we do not have answers to the above questions. We
better go in lock-step with the Ladd I-D. Is there anyone with free
time to write an I-D?
I'd say just do something that will work. Get an OID, we agree on an algorithm
ID, and then Bob's your uncle and Alice is your auntie.
Shouldn't we continue this discussing at the IETF OpenPGP mailing list?
You mean this isn't?
Jon
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp