Adding support for Ed25519 signatures

[skion]

Would anyone upstream be interested in adding support for NaCl-style Ed25519 signatures? I have done some preliminary work in here based on PyNaCl. At the moment it includes a fallback (and prohibitively slow) pure-Python implementation as well, but I could easily be persuaded to create a PR without that part and/or based on feedback.

[jpadilla]

I have to admit that I don't know much about NaCL so I'd be good to have some feedback from somebody that does.

What's the use case for using Ed25519 signatures?

[skion]

They essentially offer digital (public key) signatures similar to RS*, yet with keys that are just 32 bytes long. Public keys can thus be stored in a kid header parameter directly making verification of the signature trivial.

[mark-adams]

The JSON Web Algorithms (JWA) draft spec doesn't seem to include anything other than HMAC (HS*), RSASSA-PKCS-v1_5 (RS*), ECDSA (EC*), and RSASSA-PSS (PS*).

I think that the library should focus on implementing the proposed spec as closely as possible and leave non-standard algorithms to others, but that's just my opinion. That being said, there's no reason we shouldn't make it easier by introducing some sort of a pluggable extension mechanism that developers could use to add non-standard algorithms for use in their applications.

Maybe we could rework the existing signing_methods and verifying_methods lookups into more of a object-based architecture using the registry pattern. That way it would be easier for consumers of the library to add new non-standard algorithms such as NaCL for their applications to use. I don't think we'd be looking at any public API changes here with the exception of adding a new public register_algorithm method.

@jpadilla, if you think this sort of a plugin design might be a good idea, let me know and I can create a separate issue for it..

[skion]

From my angle a plugin model would probably work great.

[jpadilla]

Sounds good to me. I also want to start moving this to a v1 stance. It's already being used in production and has been kicking around for a while now.

[wbolster]

@skion see #70 for more discussion re. extensions.

[mark-adams]

@jpadilla Since we've decided this is best handled by some form of extensibility (like #70), can we go ahead and close this issue?

[skion]

Most definitely; looking forward to trying the registry stuff soon.

[stela]

Since January 2017, Ed25519 and Ed448 signatures are now standardized by this RFC: https://tools.ietf.org/html/rfc8037 (using alg=EdDSA)
There's a registry of algorithm definitions to use for JOSE implementations at https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms