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
