Re: [jose] The role of JWK

[Justin Richer <[e-mail]>]

> 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.

>
> Cheers, Sergey
>>>
>>>> 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.
>>> 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 ?

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.

>>>
>>>>
>>>> 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.
>>>>
>>> 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 ?
>>>

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