The point format question isn't about specific curves, it's whether we want to support binary curves at all. The current format just doesn't define a way to represent binary curve points, so they can't be used. Referencing SEC1/uncompressed would mean no change for current (prime) curves, but would add support for binary curves.
While prime curves do seem more popular, there are a fair number of binary curves out there. The relevant NIST spec (186-4) arguably recommends more binary than prime curves. See appendix D of: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf So this seems like a low-cost change, without which we lose significant capability. On Thursday, August 15, 2013, Mike Jones wrote: > Maybe this seems too easy to me because I misunderstand something, but > from your example, the only open question that seems to remain about this > issue is whether to register “crv” values other than “P-256”, “P-384”, and > “P-521”. To me, this would only seem to make sense if they are actually > used in practice.**** > > ** ** > > Given that the Suite B Implementer’s Guide to NIST SP 800-56A ( > http://www.nsa.gov/ia/_files/SuiteB_Implementer_G-113808.pdf) doesn’t > include any curves outside that set, I question whether other curves are > frequently enough used to warrant inclusion in our standard set.**** > > ** ** > > -- Mike*** > * > > ** ** > > *From:* Richard Barnes [mailto:[email protected] <javascript:_e({}, 'cvml', > '[email protected]');>] > *Sent:* Thursday, August 15, 2013 4:53 PM > *To:* Mike Jones > *Cc:* Brian Campbell; [email protected] <javascript:_e({}, 'cvml', > '[email protected]');> > *Subject:* Re: [jose] #53: Use "SEC1" format for elliptic curve keys**** > > ** ** > > The base point of the NIST curve B-283 would be:**** > > ** ** > > {**** > > "kty": "EC",**** > > "crv": "B-283",**** > > "x": "Bfk5JY233ZDhk0-McLDf7C7tJbhVfqycgOLhmPjNvs2GsSBT",**** > > "y": "A2doVP4kFBy5j-bUsg0CtFFv9wI1Dt2wgmd5yBPw30W-gRL0",**** > > } **** > > ** ** > > No special magic, just base64url-encoding an octet string. But it's > important that you use the *right* octet string :)**** > > ** ** > > <http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf>**** > > ** ** > > On Thu, Aug 15, 2013 at 12:51 PM, Mike Jones <[email protected]> > wrote:**** > > So the current “crv”, “x”, “y” representation for the current EC curves > would then remain unchanged?**** > > **** > > Can you give us a proposed concrete representation example for a binary > curve?**** > > **** > > -- Mike**** > > **** > > *From:* Richard Barnes [mailto:[email protected]] > *Sent:* Thursday, August 15, 2013 9:41 AM > *To:* Mike Jones > *Cc:* Brian Campbell; [email protected]**** > > > *Subject:* Re: [jose] #53: Use "SEC1" format for elliptic curve keys**** > > **** > > I would be fine with removing the compressed format, and saying that the > points MUST use the uncompressed format. This is doubleplusgood because it > means that current objects are completely unaffected.**** > > **** > > I still think there's value in basing this in SEC1, since it gives us > binary curves. **** > > **** > > On Thu, Aug 15, 2013 at 12:32 PM, Mike Jones <[email protected]> > wrote:**** > > I have an issue with the whole premise of “An elliptic curve point can be > represented in compressed or uncompressed format”. Part of the design > philosophy of JOSE/JWT has always been to have one simple way to do things > whenever possible and to do them well. Having multiple formats is a sure > recipe for interop problems, because no matter what the spec says, some > implementations will only implement the parts that they think they need at > the time.**** > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
