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
