Re: [jose] The role of JWK

[Anders Rundgren <[e-mail]>]

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 <[e-mail]
>> <mailto:[e-mail]>> 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
>>              <[e-mail] <mailto:[e-mail]>
>>              <mailto:[e-mail] <mailto:[e-mail]>>>
>>              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
>>              [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>              <mailto:[e-mail]>>
>>
>>              https://www.ietf.org/mailman/__listinfo/jose
>>              <https://www.ietf.org/mailman/listinfo/jose>
>>
>>
>>
>>
>>              _________________________________________________
>>              jose mailing list
>>              [e-mail] <mailto:[e-mail]>
>>              https://www.ietf.org/mailman/__listinfo/jose
>>              <https://www.ietf.org/mailman/listinfo/jose>
>>
>>
>>
>>      _________________________________________________
>>      jose mailing list
>>      [e-mail] <mailto:[e-mail]>
>>      https://www.ietf.org/mailman/__listinfo/jose
>>      <https://www.ietf.org/mailman/listinfo/jose>
>>
>>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>