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