Re: [jose] The role of JWK

[Sergey Beryozkin <[e-mail]>]

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
On 14/08/14 18:52, Justin Richer wrote:
>
>> 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