On 2014-08-15 12:05, Sergey Beryozkin wrote:
Sorry for returning to it,
Brian, IMHO, jose4J would do really well in the Apache (Software
Foundation) landscape, just a thought which you may've heard not once
already.
In your presentation you referred to JWK being like self-signed certs.
Yes, Justin explained they are not X509 certs, rather the containers for
the raw key info. The lack of the associated trust chain does bring an
analogy to the self-signed certificates.
However I can see JWK can hold X509 related properties. As such it
appears that it is feasible that browsers could support JWK indirectly
eventually. That would likely require JWS being supported at the TLS
level...
Hi Sergey,
May I as developer in this space offer my opinion on this matter?
Browsers will soon support JWK directly through W3C WebCrypto.
However, browser/platform key-stores typically use proprietary formats
and TLS structures are binary.
Although JWK [maybe] could replace PEM and PKCS #12, I don't think that will
happen either.
That is, from my horizon (FWIW), the JOSE standards will probably only be
used in *new* schemes. This isn't too bad since there are a lot of such in
the workings, including payment systems.
Regarding certificates versus public keys, the FIDO alliance craze seems
to indicate that client-side PKI is not so hot anymore. Personally, I
would take this with a grain of salt :-)
Anders
Thanks, Sergey
On 14/08/14 18:46, Brian Campbell wrote:
One pattern that's emerging as popular is to publish (and periodically
rotate) a JWK Set at an HTTPS endpoint and reference they key used for
individual messages by kid. OpenID Connect uses that model - it's
discussed in some more detail in section 10:
http://openid.net/specs/openid-connect-core-1_0.html#SigEnc
There's not really much more info there but I discussed this a bit in a
recent presentation I gave:
http://www.slideshare.net/briandavidcampbell/i-left-my-jwt-in-san-jose/29
On Thu, Aug 14, 2014 at 10:42 AM, Sergey Beryozkin <[email protected]
<mailto:[email protected]>> wrote:
Hi Richard and Justin
Very helpful, many thanks !
Richard: thanks for the link, the idea of using JWK as a standard
medium for shipping the key (information) is something that helps to
understand why JWK is referred to so much in the specifications like
JWE/JWS
Justin: I'll try my best not to copy the Java code you linked too :-).
Thanks for links to the examples, let me ask few questions below:
On 14/08/14 16:04, Justin Richer wrote:
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 ?
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
<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
<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/__0d5b12b4d4b84c822bec4af368b3be__a5120cb310/src/main/java/com/__nimbusds/jose/jwk/RSAKey.java?__at=master#cl-1395
<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
<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.
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 ?
Thanks, Sergey
-- 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
<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]>
<mailto:[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
<http://tools.ietf.org/html/draft-ietf-jose-json-web-key-31#section-1>
_________________________________________________
jose mailing list
[email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
https://www.ietf.org/mailman/__listinfo/jose
<https://www.ietf.org/mailman/listinfo/jose>
_________________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/jose
<https://www.ietf.org/mailman/listinfo/jose>
_________________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/jose
<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
