Subject: [jose] Encrypted JWK in JWK set

From: Richard Barnes <[email-masked]>
Date: Fri, 11 Oct 2013 11:30:02 -0400

Hey all,

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.

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.

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?

--Richard

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 14 Oct 2013 18:09:40 +1100

> 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:
> 
> NEW: "The value of the "keys" member is an array of JWK and/or
> Encrypted JWK values"
> 
> Thoughts?

--
James Manger

---

From: Richard Barnes <[email-masked]>
Date: Mon, 14 Oct 2013 10:26:03 +0300

Inline.

On Mon, Oct 14, 2013 at 10:09 AM, Manger, James H <
[email-masked]> wrote:

> 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:
http://tools.ietf.org/html/draft-ietf-jose-json-web-key-17#section-6)

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

--Richard