Re: [jose] The role of JWK

Sergey Beryozkin <sberyozkin@gmail.com> Fri, 15 August 2014 10:06 UTC

Return-Path: <sberyozkin@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63E61A8A2C for <jose@ietfa.amsl.com>; Fri, 15 Aug 2014 03:06:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BEIqUmEldka for <jose@ietfa.amsl.com>; Fri, 15 Aug 2014 03:06:02 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1061A8A0D for <jose@ietf.org>; Fri, 15 Aug 2014 03:06:01 -0700 (PDT)
Received: by mail-lb0-f174.google.com with SMTP id c11so1770508lbj.19 for <jose@ietf.org>; Fri, 15 Aug 2014 03:05:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MyUU/TOdr+DKRf7nl1ABzx5N0Em2P0R/ZUBCW06RPHQ=; b=nyZh8ejzy4W61+RbFrdGuy+mwVfnHhBXm8MaLU1BZq5sE7r5I5hdQywAMchPwgeQBw xca4uTCAor482xa+XgUWtJOnA4IZJbVN6QNp41KQNOiGFULzl13z8RGpPDZVd/WuXV1H LHK94yKMbBYEdHk0fNNFnn+T63moabqPN8l36LaXPxXaLCAIOIfeTleZbypzoFB/DyP+ GCzw7jNLXmrpxHJsDWDeWedoVDBHxwj7u+bSZv1CgIHZM8f3//l6o4dDs0OuvKsOmRrZ XIYSDuNzm2GTMDX9AZx1X0pPI02lkeuSd/q7ikzY2bdibKvDx8qUHTtlJhq9qceI60Nr 36pg==
X-Received: by 10.112.51.135 with SMTP id k7mr10603540lbo.39.1408097159726; Fri, 15 Aug 2014 03:05:59 -0700 (PDT)
Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id t3sm12068303lby.22.2014.08.15.03.05.58 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Aug 2014 03:05:58 -0700 (PDT)
Message-ID: <53EDDB85.6070304@gmail.com>
Date: Fri, 15 Aug 2014 11:05:57 +0100
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Brian Campbell <bcampbell@pingidentity.com>
References: <4E1F6AAD24975D4BA5B16804296739439AE1989B@TK5EX14MBXC293.redmond.corp.microsoft.com> <53EC868E.4000000@gmail.com> <CAL02cgS7LxLBWNRdh5EOKwyuiBSsR0jsmMz49c9xztfZehZP_A@mail.gmail.com> <53ECCFF8.9090305@mitre.org> <53ECE6F6.8000400@gmail.com> <CA+k3eCRbC=xOhTKOZ5K_i6X6NzYkF3j+X+5JQenLPF6kmpXEwg@mail.gmail.com>
In-Reply-To: <CA+k3eCRbC=xOhTKOZ5K_i6X6NzYkF3j+X+5JQenLPF6kmpXEwg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/vnVzEGve7MAGPVsC8nRrYt_jQmM
Cc: Richard Barnes <rlb@ipv.sx>, Justin Richer <jricher@mitre.org>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] The role of JWK
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Aug 2014 10:06:06 -0000

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


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 <sberyozkin@gmail.com
> <mailto:sberyozkin@gmail.com>> 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
>             <sberyozkin@gmail.com <mailto:sberyozkin@gmail.com>
>             <mailto:sberyozkin@gmail.com <mailto:sberyozkin@gmail.com>>>
>             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
>             jose@ietf.org <mailto:jose@ietf.org> <mailto:jose@ietf.org
>             <mailto:jose@ietf.org>>
>
>             https://www.ietf.org/mailman/__listinfo/jose
>             <https://www.ietf.org/mailman/listinfo/jose>
>
>
>
>
>             _________________________________________________
>             jose mailing list
>             jose@ietf.org <mailto:jose@ietf.org>
>             https://www.ietf.org/mailman/__listinfo/jose
>             <https://www.ietf.org/mailman/listinfo/jose>
>
>
>
>     _________________________________________________
>     jose mailing list
>     jose@ietf.org <mailto:jose@ietf.org>
>     https://www.ietf.org/mailman/__listinfo/jose
>     <https://www.ietf.org/mailman/listinfo/jose>
>
>