Subject: [jose] JWK Elliptic Curve key representations and new curves

From: Mike Jones <[email-masked]>
Date: Thu, 14 Aug 2014 01:39:58 +0000

It has come up in recent discussions in the CRFG, the W3C WebCrypto working group, and the TLS working group that not all elliptic curves or curve protocols use two coordinates (x and y) in their public key representations.  For instance, a Curve25519 public key is a single 32-byte value.  Especially in light of the request by TLS to the CRFG to recommend new curves, and that some of the curves in consideration use only a single value in their public key representation, I believe that JOSE should consider how to represent such keys as JWKs.

I see there being two logical ways to address this:

CHOICE 1 - MAKE THE "EC" KEY TYPE MORE FLEXIBLE:  One obvious possibility is to make it a property of the "crv" parameter for JWKs with "kty": "EC" what fields are required.  So for instance, when "crv" is "P-256", "P-384", or "P-521", both "x" and "y" members would be used, but other curves might use a different set of members, such as just "x" for public keys.

CHOICE 2 - USE A DIFFERENT KEY TYPE:  Another possibility is to leave the "kty": "EC" definition as it is but to define a related "kty": "EC1" value to be used by elliptic curves for which only one value "x" is used in the public key representation and an additional value "d" is used in the private key representation.

Within choice 2, there are actually two sub-choices available to us:

CHOICE 2A - DEFINE A NEW KEY TYPE VALUE IN JWA NOW:  If we think that there are only two kinds of elliptic curve key representations that we will ever care about, we could define the second one in JWA now.  However, this would almost certainly start a debate within JOSE about whether we should add any additional curve definitions using this new key type.  If we do, it should almost certainly be because we have followed the CFRG's and TLS's lead in the new curve choices, although doing so would almost certainly further delay our completion.
CHOICE 2B - DEFINE THE NEW KEY TYPE IN A NEW SPEC:   This could be done by writing an individual draft that registers "kty": "EC1" and later possibly adopting it as a working group item.  This would allow our current specs to proceed as-is, while giving us time to sync with CFRG and TLS as their curve choices move forwards.

One additional pesky detail worth noting is that the normal Curve25519 key representation uses little-endian 32-bit numbers whereas SEC1 (which we use for "x", "y", and "d") uses big-endian numbers.  So for any of these choices above, we'd also have to decide whether to allow different curves to specify different endianness, require all to use big-endian representations, or to say that for some curves, the value is an octet array of a given size and be silent on endianness.

While I'm reluctant to even bring this up at this point in the development of our specs, I also don't want those designing potential applications of JWKs to believe that their choices of curves are limited by decisions that JOSE has made.  It's clear that JWK can be extended to accommodate curves using only a single value in their public key representations.

How do you think we should do that?

                                                                -- Mike

P.S.  Thanks to Trevor Perrin for private discussions that informed some of the contents of this note.

---

From: Daniel Holth <[email-masked]>
Date: Wed, 13 Aug 2014 22:20:36 -0400

On Wed, Aug 13, 2014 at 9:39 PM, Mike Jones <[email-masked]> wrote:
> It has come up in recent discussions in the CRFG, the W3C WebCrypto working
> group, and the TLS working group that not all elliptic curves or curve
> protocols use two coordinates (x and y) in their public key representations.
> For instance, a Curve25519 public key is a single 32-byte value.  Especially
> in light of the request by TLS to the CRFG to recommend new curves, and that
> some of the curves in consideration use only a single value in their public
> key representation, I believe that JOSE should consider how to represent
> such keys as JWKs.
>
>
>
> CHOICE 1 – MAKE THE “EC” KEY TYPE MORE FLEXIBLE:  One obvious possibility is
> to make it a property of the “crv” parameter for JWKs with “kty”: “EC” what
> fields are required.  So for instance, when “crv” is “P-256”, “P-384”, or
> “P-521”, both “x” and “y” members would be used, but other curves might use
> a different set of members, such as just “x” for public keys.
>
>
>
> CHOICE 2 – USE A DIFFERENT KEY TYPE:  Another possibility is to leave the
> “kty”: “EC” definition as it is but to define a related “kty”: “EC1” value
> to be used by elliptic curves for which only one value “x” is used in the
> public key representation and an additional value “d” is used in the private
> key representation.
>
>
>
> CHOICE 2A – DEFINE A NEW KEY TYPE VALUE IN JWA NOW:  If we think that there
> are only two kinds of elliptic curve key representations that we will ever
> care about, we could define the second one in JWA now.  However, this would
> almost certainly start a debate within JOSE about whether we should add any
> additional curve definitions using this new key type.  If we do, it should
> almost certainly be because we have followed the CFRG’s and TLS’s lead in
> the new curve choices, although doing so would almost certainly further
> delay our completion.
>
> CHOICE 2B – DEFINE THE NEW KEY TYPE IN A NEW SPEC:   This could be done by
> writing an individual draft that registers “kty”: “EC1” and later possibly
> adopting it as a working group item.  This would allow our current specs to
> proceed as-is, while giving us time to sync with CFRG and TLS as their curve
> choices move forwards.
>
>
>
> One additional pesky detail worth noting is that the normal Curve25519 key
> representation uses little-endian 32-bit numbers whereas SEC1 (which we use
> for “x”, “y”, and “d”) uses big-endian numbers.  So for any of these choices
> above, we’d also have to decide whether to allow different curves to specify
> different endianness, require all to use big-endian representations, or to
> say that for some curves, the value is an octet array of a given size and be
> silent on endianness.
>
>
>
> While I’m reluctant to even bring this up at this point in the development
> of our specs, I also don’t want those designing potential applications of
> JWKs to believe that their choices of curves are limited by decisions that
> JOSE has made.  It’s clear that JWK can be extended to accommodate curves
> using only a single value in their public key representations.
>
>
>

I didn't find the existing spec a burden. My JWK-derived system uses {
"kty" : "Ed25519", vk : "the base64url-encoded verifying key" } and
uses "Ed25519" as alg as well. (In the less necessary JWK private key
representation "sk" : "..." is used for the secret part).

Is there some economy that makes it desirable to have a Ed25519 JWK
look similar to any other elliptic curve key that only uses one
(opaque?) parameter? The constant-time implementation (no secret
branching) is monolithic, specialized to that curve and is not built
out of reconfigurable pieces.

Curve1174 "Elligator" is another elliptic curve system by DJB etc.
that looks like it shares some of the attributes of Ed25519.

Daniel Holth

---

From: Mike Scott <[email-masked]>
Date: Thu, 14 Aug 2014 08:22:16 +0000

Be careful not to confuse Ed25519 with Curve25519. The former uses Edwards coordinates in which case (x,y) coordinates are appropriate. The latter uses Montgomery coordinates, which only require an x coordinate for the special case of an implementation of the Diffie-Hellman key exchange.

In fact all coordinate systems can use a "compressed" form of just x and at most 1 bit to indicate the sign of y (recall that x and y are related via the curve equation). However compression (or some forms of it) was patented, and hence avoided. However I believe that patent has now lapsed (?) As I recall IEEE1363 supports a compressed representation of points.
  
Also "decompression" has a cost associated with it, although this doesn't arise for Curve25519 where it is never required to recover the y coordinate

Mike Scott

________________________________________
From: jose <[email-masked]> on behalf of Daniel Holth <[email-masked]>
Sent: 14 August 2014 03:20
To: Mike Jones
Cc: Trevor Perrin; [email-masked]
Subject: Re: [jose] JWK Elliptic Curve key representations and new curves

Daniel Holth

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 14 Aug 2014 10:51:10 +0100

Hi,

This is very likely a newbie question. What is the role of JWK ?
According to [1] it is "... a (JSON) data structure that represents a 
cryptographic key".

I can see plenty examples of JWK in the JWE specification. JWS and JWE 
headers can have a "jwk" property representing a given JWK.

What confuses me is that the examples in JWE use JWK to describe the 
private parts of a given key. For example, when we talk about the RSA 
OAEP key encryption, JWK would show a private exponent of a given RSA 
key (JWE A1). Same for Aes Wrap secret key (JWE A3). Etc.

So clearly one would not use a "jwk" JWE header to pass around a JWK 
representation of the key which was used to encrypt the content 
encryption key.

So I'm thinking a JWK is:
- a convenient way to describe a cryptographic key for JWE/JWS 
specifications to refer to it in the spec examples.
- perhaps there's a long-term vision that the key stores would support 
JWK format directly ?
- JWK is a 'container' for various key properties, some of those 
'public' properties can be passed around as a JWE/JWS header;

Am I on the right track, can someone please clarify it further ?

Thanks, Sergey

[1] http://tools.ietf.org/html/draft-ietf-jose-json-web-key-31#section-1

---

From: Richard Barnes <[email-masked]>
Date: Thu, 14 Aug 2014 09:25:17 -0400

Hey Sergey,

JWK isn't necessarily tied to JWE or JWS.  It can be used to represent the
public key that was used to encrypt a JWE (so that the recipient can look
up the private key), or the public key that should be used to verify a
JWS.  But it can also be used in other contexts.  For example, WebCrypto
uses JWK (among others) as a format for serializing keys.
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#subtlecrypto-interface-datatypes

As that link suggests, JWK is effectively the same as the PKCS#8 format for
private keys and the SubjectPublicKeyInfo format for public keys -- just in
JSON instead of ASN.1.  It's a way to ship a key from one place to another,
for whatever reason you need to do that.

Hope that helps,
--Richard

On Thu, Aug 14, 2014 at 5:51 AM, Sergey Beryozkin <[email-masked]>
wrote:

> private parts of a given key. For example, when we talk about the RSA OAEP
> key encryption, JWK would show a private exponent of a given RSA key (JWE
> A1). Same for Aes Wrap secret key (JWE A3). Etc.
>
> representation of the key which was used to encrypt the content encryption
> key.
>
> - perhaps there's a long-term vision that the key stores would support JWK
> format directly ?
> - JWK is a 'container' for various key properties, some of those 'public'
> properties can be passed around as a JWE/JWS header;
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 14 Aug 2014 09:43:00 -0400

I think it has to be a new "kty" value, unless the Curve25519 crowd are
willing to do conversion from little-endian to big.  If that's the case, we
could update the "EC" spec to say that "y" is optional in cases where there
is no ambiguity.

It would be very much preferable, however, to keep this on ice until the
CFRG debate settles.  There appear to be all sorts of slight variations in
how these new curves like to represent points, so it will be helpful to
have a more consolidated set of targets, so that we don't have to come up
with N point formats.  It would also be helpful if the proponents of the
various curves could lay down their weapons for a second and agree on a
format that works for all of them.

--Richard

On Thu, Aug 14, 2014 at 4:22 AM, Mike Scott <[email-masked]> wrote:

> Be careful not to confuse Ed25519 with Curve25519. The former uses Edwards
> coordinates in which case (x,y) coordinates are appropriate. The latter
> uses Montgomery coordinates, which only require an x coordinate for the
> special case of an implementation of the Diffie-Hellman key exchange.
>
> In fact all coordinate systems can use a "compressed" form of just x and
> at most 1 bit to indicate the sign of y (recall that x and y are related
> via the curve equation). However compression (or some forms of it) was
> patented, and hence avoided. However I believe that patent has now lapsed
> (?) As I recall IEEE1363 supports a compressed representation of points.
>
> Also "decompression" has a cost associated with it, although this doesn't
> arise for Curve25519 where it is never required to recover the y coordinate
>
>
> Mike Scott
>
> > P.S.  Thanks to Trevor Perrin for private discussions that informed some
> of
> > the contents of this note.
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Aug 2014 15:43:30 +0100

On 14/08/14 14:43, Richard Barnes wrote:
> CFRG debate settles. 

Yep. That'd be sensible. Time enough when CFRG have
produced a result.

S.

---

From: Justin Richer <[email-masked]>
Date: Thu, 14 Aug 2014 11:04:24 -0400

Services are starting to publish their public keys as JWK instead of 
X509, since a JWK doesn't require a trusted CA and can be much more 
easily rotated at runtime. This is the class from our OAuth/OpenID 
Connect system that builds signers and validators off of a public-key 
JWK (using the Nimbus-DS JOSE library):

    https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-common/src/main/java/org/mitre/jwt/signer/service/impl/JWKSetCacheService.java

To add to that, with the private/shared key components of JWK, it can be 
a very effective key store. Our OAuth server uses this for its keys, 
this is the class that reads the file and makes the keys available as 
Java key objects to the rest of the system:

    https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-common/src/main/java/org/mitre/jose/keystore/JWKSetKeyStore.java

As you can see, these are both exceedingly simple classes because they 
simple read the URL (in the first case) or file (in the second case) and 
parse the JSON found there into a JWK set, which is then used to create 
the bare keys in the Java security framework. This is the RSA public key 
parser for example:

    https://bitbucket.org/connect2id/nimbus-jose-jwt/src/0d5b12b4d4b84c822bec4af368b3bea5120cb310/src/main/java/com/nimbusds/jose/jwk/RSAKey.java?at=master#cl-1395

Finally, in order to make these keys more easy to deal with, we wrote a 
simple key generator program that will spin up a new RSA, EC, or Oct key 
and print it out as a JWK:

    https://github.com/mitreid-connect/json-web-key-generator

Whenever we deploy a new copy of our server somewhere, we also pull down 
this program and run it to generate a new JWK key set (with public and 
private keys) that we use to start up the server. The alternative, which 
we used to do, was to use OpenSSL to generate a self-signed X509 
certificate that we effectively threw away the trust chain for -- lots 
of extra effort to create information that we didn't want and then 
ignore it on the far end, all to get a simple keypair. It was 
unnecessarily complex from all ends, and the switch to JWK has been much 
nicer to deal with.

  -- Justin

On 08/14/2014 09:25 AM, Richard Barnes wrote:
> Hey Sergey,
>
> JWK isn't necessarily tied to JWE or JWS.  It can be used to represent 
> the public key that was used to encrypt a JWE (so that the recipient 
> can look up the private key), or the public key that should be used to 
> verify a JWS.  But it can also be used in other contexts.  For 
> example, WebCrypto uses JWK (among others) as a format for serializing 
> keys.
> As that link suggests, JWK is effectively the same as the PKCS#8 
> format for private keys and the SubjectPublicKeyInfo format for public 
> keys -- just in JSON instead of ASN.1.  It's a way to ship a key from 
> one place to another, for whatever reason you need to do that.
>
> Hope that helps,
> --Richard
>
>
>
>
>
> On Thu, Aug 14, 2014 at 5:51 AM, Sergey Beryozkin 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     According to [1] it is "... a (JSON) data structure that
>     represents a cryptographic key".
>
>     I can see plenty examples of JWK in the JWE specification. JWS and
>     JWE headers can have a "jwk" property representing a given JWK.
>
>     What confuses me is that the examples in JWE use JWK to describe
>     the private parts of a given key. For example, when we talk about
>     the RSA OAEP key encryption, JWK would show a private exponent of
>     a given RSA key (JWE A1). Same for Aes Wrap secret key (JWE A3). Etc.
>
>     So clearly one would not use a "jwk" JWE header to pass around a
>     JWK representation of the key which was used to encrypt the
>     content encryption key.
>
>     - perhaps there's a long-term vision that the key stores would
>     support JWK format directly ?
>     [1]
>     http://tools.ietf.org/html/draft-ietf-jose-json-web-key-31#section-1
>
>     [email-masked] <mailto:[email-masked]>

---

From: Mike Jones <[email-masked]>
Date: Thu, 14 Aug 2014 15:46:04 +0000

That's fine with me.  I mainly wanted to make the working group aware of this so they could start thinking about it.

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, August 14, 2014 7:44 AM
To: Richard Barnes; Mike Scott
Cc: Trevor Perrin; Daniel Holth; Mike Jones; [email-masked]
Subject: Re: [jose] JWK Elliptic Curve key representations and new curves

On 14/08/14 14:43, Richard Barnes wrote:
> It would be very much preferable, however, to keep this on ice until 
> the CFRG debate settles.

Yep. That'd be sensible. Time enough when CFRG have produced a result.

S.

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 14 Aug 2014 17:42:30 +0100

Hi Richard and Justin

Very helpful, many thanks !

Richard: thanks for the link, the idea of using JWK as a standard medium 
for shipping the key (information) is something that helps to understand 
why JWK is referred to so much in the specifications like JWE/JWS

Justin: I'll try my best not to copy the Java code you linked too :-).

Thanks for links to the examples, let me ask few questions below:

On 14/08/14 16:04, Justin Richer wrote:
> easily rotated at runtime.
Sorry if it is off-topic, is JWK representing a public key (the public 
exponent) is effectively a self-signed public key/cert ? What provides 
the extra trust into such JWK ? I've heard here about JWK Thumbprints ?

> This is the class from our OAuth/OpenID
Is the simplicity of making a demo application running fast a major 
factor of preferring JWK to self-signed X509  ? What about the 
synchronization between the existing X509-based key storage and the new 
JWK-aware storages ?

Thanks, Sergey

---

From: Justin Richer <[email-masked]>
Date: Thu, 14 Aug 2014 13:14:45 -0400

Sergey - it's an Apache licensed project. Copy away! (with attribution) :)

  -- Justin

On 08/14/2014 12:42 PM, Sergey Beryozkin wrote:
> Richard: thanks for the link, the idea of using JWK as a standard 
> medium for shipping the key (information) is something that helps to 
> understand why JWK is referred to so much in the specifications like 
> JWE/JWS
>
> synchronization between the existing X509-based key storage and the 
> new JWK-aware storages ?
>
> Thanks, Sergey
>
>>   -- Justin
>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 14 Aug 2014 18:40:06 +0100

Hi Justin -
I can only afford sometimes looking at how others do something I'm not 
clear about but eventually would hack things my own way :-)

Can you please give me a favor and address a couple of questions I asked 
in the previous message too ?

Cheers, Sergey

---

From: Brian Campbell <[email-masked]>
Date: Thu, 14 Aug 2014 11:46:06 -0600

One pattern that's emerging as popular is to publish (and periodically
rotate) a JWK Set at an HTTPS endpoint and reference they key used for
individual messages by kid. OpenID Connect uses that model - it's discussed
in some more detail in section 10:
http://openid.net/specs/openid-connect-core-1_0.html#SigEnc

There's not really much more info there but I discussed this a bit in a
recent presentation I gave:
http://www.slideshare.net/briandavidcampbell/i-left-my-jwt-in-san-jose/29

On Thu, Aug 14, 2014 at 10:42 AM, Sergey Beryozkin <[email-masked]>
wrote:

> exponent) is effectively a self-signed public key/cert ? What provides the
> extra trust into such JWK ? I've heard here about JWK Thumbprints ?
>
>
>>     https://github.com/mitreid-connect/OpenID-Connect-Java-
>> Spring-Server/blob/master/openid-connect-common/src/
>> main/java/org/mitre/jwt/signer/service/impl/JWKSetCacheService.java
>>
>>
>>     https://github.com/mitreid-connect/OpenID-Connect-Java-
>> Spring-Server/blob/master/openid-connect-common/src/
>> main/java/org/mitre/jose/keystore/JWKSetKeyStore.java
>>
>>     https://bitbucket.org/connect2id/nimbus-jose-jwt/src/
>> 0d5b12b4d4b84c822bec4af368b3bea5120cb310/src/main/java/com/
>> nimbusds/jose/jwk/RSAKey.java?at=master#cl-1395
>>
>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 14 Aug 2014 13:52:37 -0400

> Can you please give me a favor and address a couple of questions I 
> asked in the previous message too ?

Sure, I missed those before.

>>> the extra trust into such JWK ? I've heard here about JWK Thumbprints ?

It's all based on how you get the JWK -- either from a trusted HTTPS 
URI, or out of band in a configuration, or what have you. Don't think of 
the JWK as a certificate, think of it as a keypair. It's not signed or 
issued with a certification chain or anything that you'd expect from 
X509. Instead, it's literally the raw keys. If you're fetching it from a 
URL, it's going to be the public keys only. If you're using it for 
configuring an app or building a local keypair store, it's going to have 
both the public and private key parts.

>>> synchronization between the existing X509-based key storage and the

It's not runtime execution that's driving things for us, it's ease of 
development, lower code complexity, and deployment management.

We haven't needed to synchronize the two kinds of storage mechanisms, 
but you could always do what we used to do when we were using a Java 
x509 keystore for our server: parse the certificates, dutifully ignore 
all of the certificate chain validation (since they were self-signed 
anyway), and extract the bare keys. These keys can be easily represented 
in JWK for JWK-aware apps, while X509 apps can use the existing certs 
directly. Alternatively you could programmatically generate self-signed 
X509 certs based on the raw keys from a JWK. We looked into doing that 
at one point, but the APIs for handling this (in Java, at least) were 
absolutely awful.

So now we just use JWKs in our OAuth infrastructure, both clients and 
servers. The keystore is a JSON text file that we can squirrel away on a 
safe part of the server, remote keys are fetched over HTTPS and easily 
parsed, and everything works quite swimmingly.

  -- Justin

  -- Justin

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 14 Aug 2014 17:26:08 -0400

Sent from my iPhone

> On Aug 14, 2014, at 10:43 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

Ok, JWA should move forward into last call once the shepherd report is posted and this can be added into the registry and may require a separate draft.  Does that sound good?

Thanks,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Thu, 14 Aug 2014 21:27:02 +0000

+1
________________________________
From: Kathleen Moriarty<mailto:[email-masked]>
Sent: ‎8/‎14/‎2014 2:26 PM
To: Stephen Farrell<mailto:[email-masked]>
Cc: Richard Barnes<mailto:[email-masked]>; Mike Scott<mailto:[email-masked]>; Trevor Perrin<mailto:[email-masked]>; Daniel Holth<mailto:[email-masked]>; Mike Jones<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] JWK Elliptic Curve key representations and new curves

Sent from my iPhone

Thanks,
Kathleen

---

From: Justin Richer <[email-masked]>
Date: Thu, 14 Aug 2014 17:27:29 -0400

+1, this makes the most sense given that JWK is a highly extensible format

On 08/14/2014 05:27 PM, Mike Jones wrote:
> +1
> ------------------------------------------------------------------------
> From: Kathleen Moriarty <mailto:[email-masked]>
> To: Stephen Farrell <mailto:[email-masked]>
> Cc: Richard Barnes <mailto:[email-masked]>; Mike Scott 
> <mailto:[email-masked]>; Trevor Perrin 
> <mailto:[email-masked]>; Daniel Holth <mailto:[email-masked]>; Mike 
> Jones <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> Ok, JWA should move forward into last call once the shepherd report is 
> posted and this can be added into the registry and may require a 
> separate draft.  Does that sound good?
>
> Thanks,
> Kathleen
>
> >
> > S.
> >

---

From: Richard Barnes <[email-masked]>
Date: Thu, 14 Aug 2014 17:35:19 -0400

+1

No need to hold up the base specs.

Note that if we repurpose/generalize "EC", then old parsers will reject
JWKs without "y" elements.  But that's OK, because they wouldn't understand
the new curve anyway.

On Thu, Aug 14, 2014 at 5:27 PM, Justin Richer <[email-masked]> wrote:

>   ------------------------------
> From: Kathleen Moriarty <[email-masked]>
> To: Stephen Farrell <[email-masked]>
> Cc: Richard Barnes <[email-masked]>; Mike Scott <[email-masked]>; Trevor
> Perrin <[email-masked]>; Daniel Holth <[email-masked]>; Mike Jones
> <[email-masked]>; [email-masked]
> > On Aug 14, 2014, at 10:43 AM, Stephen Farrell
> <[email-masked]> <[email-masked]> wrote:
> >
> >
> >
> posted and this can be added into the registry and may require a separate
> draft.  Does that sound good?
>
> Thanks,
> Kathleen
>
> >
> > S.
> >
> jose mailing [email-masked]://www.ietf.org/mailman/listinfo/jose
>
>
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 14 Aug 2014 15:38:07 -0600

+1

On Thu, Aug 14, 2014 at 3:35 PM, Richard Barnes <[email-masked]> wrote:

>> the

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 14 Aug 2014 23:49:30 +0100

Hi Justin, and all,

thanks again, I've got plenty of information real fast, very nice,

As far as I understand the regular browser would not support public JWKs 
natively (just) yet which is what I was curious about; but I got the 
points about JWK being the standard container of the public or 
public/private key properties providing for the ease of use & storage. 
Look forward to reviewing the all the additional material I've got the 
links too

Cheers, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 15 Aug 2014 11:05:57 +0100

Sorry for returning to it,

Brian, IMHO, jose4J would do really well in the Apache (Software 
Foundation) landscape, just a thought which you may've heard not once 
already.

In your presentation you referred to JWK being like self-signed certs. 
Yes, Justin explained they are not X509 certs, rather the containers for 
the raw key info. The lack of the associated trust chain does bring an 
analogy to the self-signed certificates.

However I can see JWK can hold X509 related properties. As such it 
appears that it is feasible that browsers could support JWK indirectly 
eventually. That would likely require JWS being supported at the TLS 
level...

Thanks, Sergey

On 14/08/14 18:46, Brian Campbell wrote:
> individual messages by kid. OpenID Connect uses that model - it's
> discussed in some more detail in section 10:
> On Thu, Aug 14, 2014 at 10:42 AM, Sergey Beryozkin <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Richard and Justin
>
>     Sorry if it is off-topic, is JWK representing a public key (the
>     public exponent) is effectively a self-signed public key/cert ? What
>     provides the extra trust into such JWK ? I've heard here about JWK
>     Thumbprints ?
>
>
>         https://github.com/mitreid-__connect/OpenID-Connect-Java-__Spring-Server/blob/master/__openid-connect-common/src/__main/java/org/mitre/jwt/__signer/service/impl/__JWKSetCacheService.java
>         <https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-common/src/main/java/org/mitre/jwt/signer/service/impl/JWKSetCacheService.java>
>
>
>         https://github.com/mitreid-__connect/OpenID-Connect-Java-__Spring-Server/blob/master/__openid-connect-common/src/__main/java/org/mitre/jose/__keystore/JWKSetKeyStore.java
>         <https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-common/src/main/java/org/mitre/jose/keystore/JWKSetKeyStore.java>
>
>         https://bitbucket.org/__connect2id/nimbus-jose-jwt/__src/__0d5b12b4d4b84c822bec4af368b3be__a5120cb310/src/main/java/com/__nimbusds/jose/jwk/RSAKey.java?__at=master#cl-1395
>         <https://bitbucket.org/connect2id/nimbus-jose-jwt/src/0d5b12b4d4b84c822bec4af368b3bea5120cb310/src/main/java/com/nimbusds/jose/jwk/RSAKey.java?at=master#cl-1395>
>
>
>         https://github.com/mitreid-__connect/json-web-key-generator
>         <https://github.com/mitreid-connect/json-web-key-generator>
>
>
>             https://dvcs.w3.org/hg/__webcrypto-api/raw-file/tip/__spec/Overview.html#__subtlecrypto-interface-__datatypes
>             <https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#subtlecrypto-interface-datatypes>
>
>             <[email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>>
>             wrote:
>
>                  Hi,
>
>             http://tools.ietf.org/html/__draft-ietf-jose-json-web-key-__31#section-1
>             <http://tools.ietf.org/html/draft-ietf-jose-json-web-key-31#section-1>
>
>                  _________________________________________________
>                  jose mailing list
>             [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>
>
>             https://www.ietf.org/mailman/__listinfo/jose
>             <https://www.ietf.org/mailman/listinfo/jose>
>
>
>
>
>             _________________________________________________
>             jose mailing list
>             https://www.ietf.org/mailman/__listinfo/jose
>             <https://www.ietf.org/mailman/listinfo/jose>
>
>
>
>     _________________________________________________
>     jose mailing list
>     https://www.ietf.org/mailman/__listinfo/jose
>     <https://www.ietf.org/mailman/listinfo/jose>
>
>

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 16 Aug 2014 10:33:53 +0200

> eventually. That would likely require JWS being supported at the TLS

Hi Sergey,

May I as developer in this space offer my opinion on this matter?

Browsers will soon support JWK directly through W3C WebCrypto.

However, browser/platform key-stores typically use proprietary formats
and TLS structures are binary.

Although JWK [maybe] could replace PEM and PKCS #12, I don't think that will
happen either.

That is, from my horizon (FWIW), the JOSE standards will probably only be
used in *new* schemes.  This isn't too bad since there are a lot of such in
the workings, including payment systems.

Regarding certificates versus public keys, the FIDO alliance craze seems
to indicate that client-side PKI is not so hot anymore.  Personally, I
would take this with a grain of salt :-)

Anders

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 18 Aug 2014 10:20:41 +0100

Hi Anders,

> May I as developer in this space offer my opinion on this matter?
Sure :-), it's very welcome

> and TLS structures are binary.
I ended up reading parts of WebCrypto yesterday, should've done it 
earlier, after Richard's reply. I did not realize using the JOSE 
structures was actually one of Web Crypto use cases (though Web Crypto 
API (key management) making it simpler to use JWE/JWS from the browser)
> would take this with a grain of salt :-)
I'm learning something new with every reply, I was not aware of the FIDO 
alliance at all :-)

Thanks
Sergey

>>>          parse the JSON found there into a JWK set, which is then
>>> used to
>>>          create
>>>          simple key generator program that will spin up a new RSA,
>>> EC, or
>>>          Oct key
>>>              JWK isn't necessarily tied to JWE or JWS.  It can be
>>> used to
>>>              represent
>>>              keys -- just in JSON instead of ASN.1.  It's a way to
>>> ship a
>>>              key from
>>>                   This is very likely a newbie question. What is the
>>> role
>>>              of JWK ?
>>>                   What confuses me is that the examples in JWE use
>>> JWK to
>>>              describe
>>>                   So clearly one would not use a "jwk" JWE header to
>>> pass
>>>              around a
>>>                   - JWK is a 'container' for various key properties,
>>> some
>>>              of those