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]<mailto:[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]>
[mailto:[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]<mailto:[email protected]>;
[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:trac%[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]<mailto:[email protected]> | Owner:
>> >>> > draft-ietf-jose-json-web-
>> >>> > Type: defect |
>> >>> > [email protected]<mailto:[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]<mailto:[email protected]>
>> >>> > https://www.ietf.org/mailman/listinfo/jose
>> >>
>> >>
>> >
>
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
