On Nov 21, 2013 6:15 AM, "Dirkjan Ochtman" <[email protected]> wrote: > > 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?
Simply because Ed25519 does not expose those parameters. > 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
