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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
