PS: I'd like to see at least one EC in the list of "MAY" asymmetric algos.
You have to be *very* careful about this, because there are so many variables
and parameters involved (field type, representation, field parameters, use of
point compression, etc etc) that unless you decide on some useful constraints
you'll end up with either specific, optimised implementations which don't
interoperate because they use different parameters than everyone else, or
incredibly complex and inefficient general-purpose solutions. I think the
best approach would be to take P1363 and define an interoperability profile
for PGP (MUST use this field type, this curve, point compression, etc etc). A
good meet-in-the-middle approach is to take an existing, high-quality PD
implementation which anyone can use, an example being George Barwood's pegwit
code (there's a link to it somewhere on
http://www.cs.auckland.ac.nz/~pgut001/links.html), and defining the parameters
to match what the implementation does. This sets a basic level of EC support
which is required to interoperate, and simultaneously provides an
implementation of the base level which anyone can use.
Peter.