Re: [jose] The role of JWK

[Sergey Beryozkin <[e-mail]>]

Hi Anders,

On 16/08/14 09:33, Anders Rundgren wrote:
> 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?
>
Sure :-), it's very welcome

> Browsers will soon support JWK directly through W3C WebCrypto.
>
> However, browser/platform key-stores typically use proprietary formats
> and TLS structures are binary.
I ended up reading parts of WebCrypto yesterday, should've done it 
earlier, after Richard's reply. I did not realize using the JOSE 
structures was actually one of Web Crypto use cases (though Web Crypto 
API (key management) making it simpler to use JWE/JWS from the browser)
>
> 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 :-)
>
I'm learning something new with every reply, I was not aware of the FIDO 
alliance at all :-)

Thanks
Sergey

> 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
>>
>