Re: [jose] Encrypted JWK in JWK set

"Manger, James H" <James.H.Manger@team.telstra.com> Mon, 14 October 2013 07:09 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D38611E811B for <jose@ietfa.amsl.com>; Mon, 14 Oct 2013 00:09:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.633
X-Spam-Level:
X-Spam-Status: No, score=-0.633 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqYtBaA2puMD for <jose@ietfa.amsl.com>; Mon, 14 Oct 2013 00:09:49 -0700 (PDT)
Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 7626011E8162 for <jose@ietf.org>; Mon, 14 Oct 2013 00:09:43 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.93,490,1378821600"; d="scan'208";a="154303541"
Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 14 Oct 2013 18:09:41 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,7227"; a="117558496"
Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcani.tcif.telstra.com.au with ESMTP; 14 Oct 2013 18:09:41 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Mon, 14 Oct 2013 18:09:41 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Richard Barnes <rlb@ipv.sx>, "jose@ietf.org" <jose@ietf.org>
Date: Mon, 14 Oct 2013 18:09:40 +1100
Thread-Topic: [jose] Encrypted JWK in JWK set
Thread-Index: Ac7GluuLl+0hOFc2TGGF39JHW0tj6wCBSZoQ
Message-ID: <255B9BB34FB7D647A506DC292726F6E115333F2AFE@WSMSG3153V.srv.dir.telstra.com>
References: <CAL02cgS2iyXu_R5TXiJOzeEKd=1d6BdJ_amAN-8z29E6D_SbhA@mail.gmail.com>
In-Reply-To: <CAL02cgS2iyXu_R5TXiJOzeEKd=1d6BdJ_amAN-8z29E6D_SbhA@mail.gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [jose] Encrypted JWK in JWK set
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 14 Oct 2013 07:09:55 -0000

> I was thinking today about how it would be nice to replace PKCS#12 with
> something JWK-based.  For background, PKCS#12 is a format that can
> store a certificate (unencrypted) alongside an encrypted private key.

I agree. A JWK-based alternative for PKCS#12 for Java keystores should be possible.

> It seems to me like the obvious thing would be to replace this with a
> JWK Set containing two keys: (1) a public key with the certificate in
> the "x5t" attribute, and (2) the corresponding private key as an
> Encrypted JWK.

I'm not so sure about that design.
It means a public/private key pair are 2 key entries, whereas currently they are 1.

It means an Encrypted JWK and a plain key entry can both appear in the same slot (entries in the "keys" array) so they need to be distinguished. I guess by "Encrypted JWK" you mean the JOSE serialization of a JWE whose content is a JWK. Will you look for a "kty" field? Looking at an "alg" field is unlikely to work.

PKCS#12 (and Java keystores) can store a certificate in the clear, but it is still integrity-protected by a MAC keyed with a password. Mixing plain JWKs and Encrypted JWKs does not give the same security properties.

Another option could be to put an JWE as a field in a JWK. Or to expect people to protect all the private keys and associated public keys together in a single JWE (Encrypted JWK) when any part needs protection. It means you cannot get the public key without the password. Does that kill the required functionality, or is that ok in 99% of cases?

> However, it's not immediately clear to me that the JWK Set format in -
> 17 allows this.  Proposed edit to clarify:
> 
> OLD: "The value of the "keys" member is an array of JWK values"
> NEW: "The value of the "keys" member is an array of JWK and/or
> Encrypted JWK values"
> 
> Thoughts?

--
James Manger