Binary fields tend to be used more in embedded hardware for power and performance reasons. (binary fields = less gates)
That may or may not remain the case. While I don't see a real advantage to having JOSE require implementations to support those curves and the different logic to process them, it may make sense for JWK to support those additional types for non JOSE applications. With the onset of the internet of things where EC over binary fields becomes more important for dedicated hardware, there may come an argument that in order to interoperate with low power devices JOSE may need to support binary curves. I think that may be a bit premature to jump to the conclusion that current generation constrained environments prefer binary fields. So in general Mike is correct that in software implementations prime fields are much more common. John B. On 2013-08-15, at 8:09 PM, Mike Jones <[email protected]> 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]] > Sent: Thursday, August 15, 2013 4:53 PM > To: Mike Jones > Cc: Brian Campbell; [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. > > Thus, I’m against having two representations for elliptic curve keys. > > -- Mike > > From: [email protected] [mailto:[email protected]] On Behalf Of > Richard Barnes > Sent: Thursday, August 15, 2013 6:11 AM > To: Brian Campbell > Cc: jose issue tracker; [email protected]; > [email protected] > Subject: Re: [jose] #53: Use "SEC1" format for elliptic curve keys > > Ok, clarity we can work on. How about a paragraph like this at the top of > level of the section "JWK Parameters for Elliptic Curve Public Keys", after > the origin paragraph: > """ > An elliptic curve point can be represented in compressed or uncompressed > format. If the point is in uncompressed format, then both the "x" and "y" > values will represent elements of the base field. In the compressed format, > the "x" value will be a field element, but the "y" value will be a > single-octet value indicating one of the two possible points with that "x" > value. > > A recipient of a public key can determine whether a public key is compressed > or uncompressed by comparing the lengths of the "x" and "y" fields. If the > two fields are of equal length, it is uncompressed; if the "y" value has > length 2, compressed. If neither of these is the case (e.g., the "y" value > has length 3), then the recipient MUST reject the key as syntactically > invalid. > """ > > As far as value: Are you saying that we should not support binary curves, or > do you have a different idea of how points on those curves should be > represented? > > > On Wed, Aug 14, 2013 at 11:10 PM, Brian Campbell <[email protected]> > wrote: > To me anyway, that is not expressed clearly from the patch or the issue. > > And I remain unconvinced of the value here. > > On Wed, Aug 14, 2013 at 7:53 PM, Richard Barnes <[email protected]> wrote: > > If you read further into the patch, the proposal refers to the actual "X" > > and "Y" values. For reference: > > Uncompressed = 0x04 || X || Y > > Compressed = Y || X, where Y == 0x02 or 0x03 > > > > The proposal in the patch suggests that the JWK format just use the "X" and > > "Y" values directly. So the signaling of compressed/uncompressed would be > > implicit; if x.length == y.length, uncompressed, else if y.length == 2 > > compressed (else fail). For example: > > Uncompressed: { "x": "ivc35sAmUfbHCpzKO1zSbsRgJBW29EEKQmD-4yULcAQ", "y": > > "dd_jxUcjbqpGRWeP21qhE3ElPQrvFNpE8WuVweQQTtM" } > > Compressed: { "x": "ivc35sAmUfbHCpzKO1zSbsRgJBW29EEKQmD-4yULcAQ", "y": "Aw" > > } > > > > So like I said, points in the current format would just be uncompressed > > prime field points. > > > > --Richard > > > > > > > > > > > > > > On Wed, Aug 14, 2013 at 5:16 PM, Brian Campbell <[email protected]> > > wrote: > >> > >> I can't say I've read all (or even much) of SEC 1 or that I understand > >> it but I don't how that's possible when the 1st paragraph of 2.3.3 > >> (the section your patch references) says that the leftmost octet > >> indicates if compression is used or not. > >> > >> On Mon, Aug 12, 2013 at 3:47 PM, Richard Barnes <[email protected]> wrote: > >> > Also: > >> > > >> > 4. Existing objects are not invalidated. They're just prime curves, > >> > non-compressed. > >> > > >> > > >> > > >> > > >> > On Mon, Aug 12, 2013 at 5:44 PM, Richard Barnes <[email protected]> wrote: > >> >> > >> >> There are at least three clear benefits: > >> >> > >> >> 1. Compatibility with binary elliptic curves (e.g., the B-XXX curves in > >> >> FIPS 186) > >> >> > >> >> 2. Simplified compatibility with crypto libraries (as noted in the > >> >> issue) > >> >> > >> >> 3. Space savings via compressed format > >> >> > >> >> > >> >> > >> >> On Mon, Aug 12, 2013 at 5:11 PM, Brian Campbell > >> >> <[email protected]> wrote: > >> >>> > >> >>> -1 > >> >>> > >> >>> Ad-hoc as it might be, the current format is pretty simple and has > >> >>> been working rather well for a good while now. > >> >>> > >> >>> This would be a breaking change with no clear benefit. > >> >>> > >> >>> > >> >>> On Sun, Aug 11, 2013 at 4:54 PM, jose issue tracker > >> >>> <[email protected]> wrote: > >> >>> > #53: Use "SEC1" format for elliptic curve keys > >> >>> > > >> >>> > The "SEC1" format for elliptic curve points is used as the format > >> >>> > for > >> >>> > EC > >> >>> > public keys in CMS, X.509, TLS, etc. As a result, it enjoys > >> >>> > widespread > >> >>> > library support. > >> >>> > > >> >>> > * OpenSSL: "Note OpenSSL uses the private key format specified in > >> >>> > 'SEC > >> >>> > 1: > >> >>> > Elliptic Curve Cryptography' (http://www.secg.org/)." > >> >>> > * BouncyCastle: "[As of 2.39.3] EC Public/Private keys are now > >> >>> > encoded > >> >>> > in > >> >>> > accordance with SEC 1." > >> >>> > * CNG: CryptImportPublicKeyInfo uses SubjectPublicKeyInfo, which > >> >>> > uses > >> >>> > SEC1 > >> >>> > * PKCS#11: Uses IEEE P1363, which is the same as SEC1 > >> >>> > > >> >>> > So rather than specifying an ad-hoc point format, we should re-use > >> >>> > that > >> >>> > format. We could do this directly (by just having a binary field > >> >>> > with > >> >>> > the > >> >>> > SEC1 encoding), or take the X and Y values defined in SEC1 and > >> >>> > express > >> >>> > them separately. > >> >>> > > >> >>> > -- > >> >>> > > >> >>> > > >> >>> > -------------------------+------------------------------------------------- > >> >>> > Reporter: [email protected] | Owner: draft-ietf-jose-json-web- > >> >>> > Type: defect | [email protected] > >> >>> > Priority: major | Status: new > >> >>> > Component: json-web- | Milestone: > >> >>> > algorithms | Version: > >> >>> > Severity: - | Keywords: > >> >>> > > >> >>> > > >> >>> > -------------------------+------------------------------------------------- > >> >>> > > >> >>> > Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/53> > >> >>> > jose <http://tools.ietf.org/jose/> > >> >>> > > >> >>> > _______________________________________________ > >> >>> > jose mailing list > >> >>> > [email protected] > >> >>> > https://www.ietf.org/mailman/listinfo/jose > >> >> > >> >> > >> > > > > > > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
