Richard:
The unclear IPR situation has caused many implementers to steer clear of
compressed format. So, ...
If we go down this path, support for uncompressed must be mandatory, and
support for compressed must be optional.
Russ
On Aug 14, 2013, at 9:53 PM, Richard Barnes 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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
