Subject: [jose] JWK Generator Service

From: Justin Richer <[email-masked]>
Date: Tue, 04 Nov 2014 09:44:21 -0500

A while ago, I was fed up with creating self-signed X.509 certificates 
just to manage the bare keys used in JOSE processing. There's a lot of 
extraneous effort that goes into making fake certificate chains that are 
then dutifully ignored by the application, especially when the JWK 
format can hold both public and private keys natively already. So we 
switched our apps over to reading the JWK format instead of X.509, but 
we still needed something to securely generate the keys themselves. So I 
created a commandline Java application to generate keys in JWK format 
(based on the NimbusDS JOSE library):

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

It's slightly unwieldy to compile and run but it gets the job done. Last 
night, I wrapped that commandline application with a webapp and made it 
publicly available:

   https://mkjwk.org/

This simple service will generate a JWK in RSA, EC, or Oct (shared 
secret) format for you, using Java's cryptographic engine. You can add 
in the use, kid, and alg parameters, and the results are formatted into 
easily-copyable JSON. It will even wrap the key in a keyset and pull out 
the public key separately for you, in case you need those.

We don't log any of the keys being generated by the service, but to be 
extra safe I would still recommend using a local generation mechanism 
(like the commandline app above) for production systems.

Finally, I put the code to the site online in the name of transparency:

   https://github.com/mitreid-connect/mkjwk.org

I hope that people can find this useful, and we can start moving off of 
X.509 for bare key storage in applications. Much thanks to MIT KIT for 
providing hosting and support.

  -- Justin

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 4 Nov 2014 14:52:49 +0000

nice stuff Justin!! really :)

regards

antonio

On Nov 4, 2014, at 3:44 PM, Justin Richer <[email-masked]> wrote:

> A while ago, I was fed up with creating self-signed X.509 certificates just to manage the bare keys used in JOSE processing. There's a lot of extraneous effort that goes into making fake certificate chains that are then dutifully ignored by the application, especially when the JWK format can hold both public and private keys natively already. So we switched our apps over to reading the JWK format instead of X.509, but we still needed something to securely generate the keys themselves. So I created a commandline Java application to generate keys in JWK format (based on the NimbusDS JOSE library):
> 
> It's slightly unwieldy to compile and run but it gets the job done. Last night, I wrapped that commandline application with a webapp and made it publicly available:
> 
>  https://mkjwk.org/
> 
> This simple service will generate a JWK in RSA, EC, or Oct (shared secret) format for you, using Java's cryptographic engine. You can add in the use, kid, and alg parameters, and the results are formatted into easily-copyable JSON. It will even wrap the key in a keyset and pull out the public key separately for you, in case you need those.
> 
> We don't log any of the keys being generated by the service, but to be extra safe I would still recommend using a local generation mechanism (like the commandline app above) for production systems.
> 
> I hope that people can find this useful, and we can start moving off of X.509 for bare key storage in applications. Much thanks to MIT KIT for providing hosting and support.
> 
> -- Justin
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Tue, 4 Nov 2014 09:54:04 -0500

Note that with WebCrypto, the crypto parts of this become one-liners.

crypto.subtle.generateKey({name: "RSA-OAEP", hash: "SHA-1"}, true,
["encrypt", "decrypt"])
  .then( function(keyPair) {

  })

On Tue, Nov 4, 2014 at 9:44 AM, Justin Richer <[email-masked]> wrote:

> then dutifully ignored by the application, especially when the JWK format
> can hold both public and private keys natively already. So we switched our
> apps over to reading the JWK format instead of X.509, but we still needed
> something to securely generate the keys themselves. So I created a
> commandline Java application to generate keys in JWK format (based on the
> NimbusDS JOSE library):
>
> This simple service will generate a JWK in RSA, EC, or Oct (shared secret)
> format for you, using Java's cryptographic engine. You can add in the use,
> kid, and alg parameters, and the results are formatted into easily-copyable
> JSON. It will even wrap the key in a keyset and pull out the public key
> separately for you, in case you need those.
>
> extra safe I would still recommend using a local generation mechanism (like
> the commandline app above) for production systems.
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 04 Nov 2014 09:57:25 -0500

That will be great to have a Javascript version widely available as 
well, when it's ready. I also know someone working on a Python app to 
handle the same task on the commandline, and I look forward to people 
having their pick of tools to do this job. If key generation isn't easy, 
people will get lazy and re-use keys, fail to rotate them when needed, 
or other, worse things.

  -- Justin

On 11/4/2014 9:54 AM, Richard Barnes wrote:
> On Tue, Nov 4, 2014 at 9:44 AM, Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     A while ago, I was fed up with creating self-signed X.509
>     certificates just to manage the bare keys used in JOSE processing.
>     There's a lot of extraneous effort that goes into making fake
>     certificate chains that are then dutifully ignored by the
>     application, especially when the JWK format can hold both public
>     and private keys natively already. So we switched our apps over to
>     reading the JWK format instead of X.509, but we still needed
>     commandline Java application to generate keys in JWK format (based
>     on the NimbusDS JOSE library):
>
>     It's slightly unwieldy to compile and run but it gets the job
>     done. Last night, I wrapped that commandline application with a
>     webapp and made it publicly available:
>
>     https://mkjwk.org/
>
>     secret) format for you, using Java's cryptographic engine. You can
>     add in the use, kid, and alg parameters, and the results are
>     formatted into easily-copyable JSON. It will even wrap the key in
>     a keyset and pull out the public key separately for you, in case
>     you need those.
>
>     We don't log any of the keys being generated by the service, but
>     to be extra safe I would still recommend using a local generation
>     mechanism (like the commandline app above) for production systems.
>
>     I hope that people can find this useful, and we can start moving
>     off of X.509 for bare key storage in applications. Much thanks to
>     MIT KIT for providing hosting and support.
>
>      -- Justin
>
>     [email-masked] <mailto:[email-masked]>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 4 Nov 2014 10:19:18 -0500

Oops, here's the real version:

-----BEGIN-----
var alg = {
      name: "RSASSA-PKCS1-v1_5",
      hash: "SHA-256",
      modulusLength: 1024,
      publicExponent: new Uint8Array([0x01, 0x00, 0x01])
    };
crypto.subtle.generateKey(alg, true, ["sign", "verify"])
  .then(
    function(keyPair) {
      crypto.subtle.exportKey("jwk", keyPair.privateKey).then(function(x) {
console.log(x) });
      crypto.subtle.exportKey("jwk", keyPair.publicKey).then(function(x) {
console.log(x) });
    }
  );
-----END-----

That should work in recent versions of Firefox if you turn on
dom.webcrypto.enabled, and in Safari with s/subtle/webkitSubtle/.

It shouldn't be much more complicated in node.js (require("node-forge")) or
python.  The only marginally non-trivial part is the base64 encoding.

--Richard

On Tue, Nov 4, 2014 at 9:57 AM, Justin Richer <[email-masked]> wrote:

> people will get lazy and re-use keys, fail to rotate them when needed, or
> other, worse things.
>
>  -- Justin
>
>
>> secret) format for you, using Java's cryptographic engine. You can add in
>> the use, kid, and alg parameters, and the results are formatted into

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 04 Nov 2014 16:33:21 +0100

It seems that the representation the private keys is incompatible with WebCrypto import.
Chrome and Firefox also wants the SHOULD parameters.

Anders

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 10 Nov 2014 18:26:46 +0000

Hi All,

Would it make sense to have a JWT spec talk about its JSON 
representation, example:
{
    "headers": {...}
    "claims": {...}
}

IMHO it might be interesting in cases where JWT is an access token 
passed over the secure channel or simply used as a standard data/token 
container

Sergey

---

From: John Bradley <[email-masked]>
Date: Mon, 10 Nov 2014 08:39:48 -1000

JWT is a OAuth spec for historic reasons, so it might be best to discuss this on that list.

Are you talking about a unsigned JWT?

JWT currently only supports the compact form.   For access tokens that allows them to be passed in headers without additional escaping.

I would need to see a use case before adding the JSON encoding to JWT.

Nothing stops someone from using a JSON encoded JWS with a set of claims in the body, but that is not by definition a JWT on the wire.

They can be converted between the two forms programatically. 

John B.

On Nov 10, 2014, at 8:26 AM, Sergey Beryozkin <[email-masked]> wrote:

> Hi All,
> 
> Would it make sense to have a JWT spec talk about its JSON representation, example:
> {
>   "headers": {...}
>   "claims": {...}
> }
> 
> IMHO it might be interesting in cases where JWT is an access token passed over the secure channel or simply used as a standard data/token container
> 
> Sergey
> 
>