Indeed, according to the EdDSA papers, a public (verifying) key is an EC point, and the private (signing) key is an integer. <http://ed25519.cr.yp.to/ed25519-20110926.pdf>
So the existing "x", "y", and "d" parameters would be sufficient. You would just need new values for "alg" and "crv". --Richard On Thu, Nov 21, 2013 at 10:54 AM, Mike Jones <[email protected]>wrote: > “will be” signifies that registrations will be possible once the > registry has been established, which will happen when JWA is an RFC. > > > > Does the verifying key not have the structure of a pair of x, y values? > It would surprise me if it didn’t. And I’d think you’d want to use > something like “crv”:”ed25519” as the curve name in the JWK representation. > > > > -- Mike > > > > *From:* jose [mailto:[email protected]] *On Behalf Of *Daniel Holth > *Sent:* Thursday, November 21, 2013 4:02 AM > *To:* Dirkjan Ochtman > *Cc:* jose > *Subject:* Re: [jose] JWS algorithms: DSA, non-NIST curves > > > > > 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 > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
