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
