On Tue, Nov 12, 2013 at 2:27 PM, Daniel Holth <[email protected]> wrote: > I have been using ed25519 with JWS and have found it to be very > convenient. I use "Ed25519" as the alg and call the public and private > parts of the key "vk" and "sk" (verifying and signing key) > respectively. The compact key and signature size, fast signature > verification, and very fast key generation and signing are attractive.
Is there a particular reason you didn't reuse the "crv"/"x"/"y" keys used by other curves? On Tue, Nov 12, 2013 at 8:01 PM, Mike Jones <[email protected]> wrote: > Anyone will be able to register algorithm identifiers in the algorithms > registry, with the only requirement being that a document is written that > specifies the algorithm behavior. So you could define DS128, etc. and > register them if you choose. Does "will be" signify that you think no further algorithms should be added before finalization as an RFC? Is there a current raw estimated time to completion? On Tue, Nov 12, 2013 at 8:54 PM, John Bradley <[email protected]> wrote: > We restricted the curves initially in favour of getting interoperability as > opposed to using arbitrary curves. That's understandable on one hand; on the other hand, if some other curves are rapidly gaining popularity, it seems sensible to me to include them now rather than hold off on standardization with the risk that early adopters start implementation in subtly-incompatible ways (as it seems has already happened given Daniel Holth's experience). We are strongly interested in Ed25519; it's looking like the ChaCha20 stream ciper and the Poly1305 MAC are also rapidly gaining popularity (including implementation in OpenSSL/OpenSSH and NSS/Chrome). Cheers, Dirkjan _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
