The base point of the NIST curve B-283 would be:
{
"kty": "EC",
"crv": "B-283",
"x": "Bfk5JY233ZDhk0-McLDf7C7tJbhVfqycgOLhmPjNvs2GsSBT",
"y": "A2doVP4kFBy5j-bUsg0CtFFv9wI1Dt2wgmd5yBPw30W-gRL0",
}
No special magic, just base64url-encoding an octet string. But it's
important that you use the *right* octet string :)
<http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf>
On Thu, Aug 15, 2013 at 12:51 PM, Mike Jones <[email protected]>wrote:
> 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]>
> 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
