Re: [jose] Encrypted JWK in JWK set

Richard Barnes <> Mon, 14 October 2013 07:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B759B21E80C4 for <>; Mon, 14 Oct 2013 00:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.885
X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e-e3ICwQfG+H for <>; Mon, 14 Oct 2013 00:26:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6DBB121E80C0 for <>; Mon, 14 Oct 2013 00:26:04 -0700 (PDT)
Received: by with SMTP id va2so4417654obc.26 for <>; Mon, 14 Oct 2013 00:26:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DsqSq3HffuSsCTyyykWGwVozeLdVictTMW4ZFBc2v2Y=; b=XjskC0qeG9AKpGPU+fMsxN80zT3RjdCQ6UFcD9sIwzm/tUydMdh6Gn/xcntS0PSini LKGfM32F4SGnZcR6CBc83bBCTJ2GepEblQ89Yq94v2YQQtemR2GO3iPjwIjKnsYGJTWx BVR/vlAeRVVNjX/uM0tqNrgQzp10WwrBBNusNHKryWM4HiAInhJVhPpQYFhtU80ySVVV yJ+Y9W9Nrb+k7j3uNB4yY5m8KI1DTGaIhnRLhSZxnPHkZ1ViTMPMnGHl8zdy3DhRfiys tVM/RqlZ/do2bLVQoyzVaz4CWkKv4eM4Yv4IwT9OL3lG6Mw1Ml5kx1iTickTuaZxFPNQ E1Qw==
X-Gm-Message-State: ALoCoQlsfaHPHN8plXDScEkBLbayR661FZqvKjxqBCYsXU6/vVWzElfsJYnox9kOT5dLdZMnasHS
MIME-Version: 1.0
X-Received: by with SMTP id e4mr27020699oes.23.1381735563860; Mon, 14 Oct 2013 00:26:03 -0700 (PDT)
Received: by with HTTP; Mon, 14 Oct 2013 00:26:03 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Mon, 14 Oct 2013 10:26:03 +0300
Message-ID: <>
From: Richard Barnes <>
To: "Manger, James H" <>
Content-Type: multipart/alternative; boundary="001a11c257d47530e704e8ae619f"
Cc: "" <>
Subject: Re: [jose] Encrypted JWK in JWK set
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Oct 2013 07:26:10 -0000


On Mon, Oct 14, 2013 at 10:09 AM, Manger, James H <> wrote:

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

Yes, that's what I meant by Encrypted JWK.  (In the sense of:

The main thing here is that the parser needs a way to correlate the public
and private keys.  You could use "kid" for this, but matching on "kty" and
the public key fields ("n", "e"; "x", "y") would be more reliable.

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

That's true, but it's not really clear to me what the benefit is of
integrity-protecting the cert or the (cert, private key) pair.  The
certificate has its own integrity protection (obviously), and it's not like
someone can fake the public/private binding.

And if you still wanted this, you could wrap the whole thing in a JWS using
a PBMAC.  But that would be key management for MAC, which is Something The
WG Has Decided Not To Do.

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

I don't know, off the top of my head.  You certainly *could* use a single
Encrypted JWK, just like you can make everything encrypted in a PKCS#12
object.  But it appears to me to be far more common to not encrypt the


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