"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]<mailto:[email protected]>> wrote:
>
> On Tue, Nov 12, 2013 at 2:27 PM, Daniel Holth
> <[email protected]<mailto:[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]<mailto:[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]<mailto:[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
