Re: [jose] Encrypted JWK in JWK set

[Richard Barnes <[e-mail]>]

Inline.

On Mon, Oct 14, 2013 at 10:09 AM, Manger, James H <
[e-mail]> 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:
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



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