I'll be a bit contrarian here and say that, while I'm of course fine
with binding the wire format to the public key algorithm, I'd prefer not
to bind the wire format to the curve. Especially when it comes to
Curve25519 and Curve448, they are specified together so often (see
RFC7748, RFC8032, RFC8422, RFC8031, etc) that to me it seems strange to
specify them in a different way in OpenPGP, especially given that this
crypto-refresh will officially be the first place for both curves to
appear. Of course, Curve25519 has been around in implementations for
much longer, but still, from the perspective of the spec it seems
strange.
(Probably I should've brought up this concern sooner, when SOS was being
discussed etc, but this patch made me realize the above.)
For what it's worth, I fully agree that the current situation with
Curve25519 is non-ideal and confusing, and that a simple byte string
would be better. However, we'll likely be stuck with it forever, and I'm
not sure if specifying a different wire format for Curve448 makes things
any simpler.
That being said, I don't think anything in this patch so far is really
"incorrect", and if everyone else feels that it makes things clearer,
(and, thanks dkg, indeed, for trying to make things clearer!) I'm OK
with specifying things that way, just perhaps with the exception of the
language saying that future algorithms should use a different encoding
(even though I do agree with that as written, but it seems like a note
for the future editors, not a note for current implementers.)
Once we do specify a new public key algorithm (e.g. post-quantum), as
opposed to just a new curve (my expectation is that adding post-quantum
algorithms will be the next "crypto refresh", and that we will never
need a new curve after Curve448), I fully agree that we definitely
shouldn't do this byte-string-in-MPI thing again. When we do so, we
could specify a new octet string type, or something else. But I'm not
sure that between Curve25519 and Curve448 is the correct place to "draw
the line in the sand".
Best,
Daniel
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp