Re: [jose] Support for Wrapped Keys?

[Mike Jones <[e-mail]>]

Per our discussions, there's an approach we could discuss that's very close to what you're already doing.  JWE already has a way to encrypt a key.  This key is then currently always used to encrypt the plaintext.

One obvious solution then appears to be to have no plaintext and only perform the first of the two steps - create a JWE Encrypted Key value, leaving the JWE Initialization Vector, JWE Ciphertext, and JWE Integrity value fields empty.

The objection that I'm sure people would raise to this obvious solution is that then the contents of the header and encrypted key are not integrity protected.  One potential solution to this would be to use an "enc" algorithm that only provides integrity but performs no encryption.

The most simple such solution would be to use a cryptographic hash function such as SHA-256 to compute an integrity value over the other fields.  You could look at this as a degenerate AEAD algorithm, accepting an "additional authenticated data" input and producing an "authentication tag" output, but with no plaintext input or ciphertext output.

That would give you an integrity-protected encrypted key, doing the key encryption in the same way that the JWE "alg" values already do.

Anyway, hopefully the above will at least seed a productive discussion of the possibilities.  I do completely understand the value of Matt's use case and want us to think about how to best solve it.

				-- Mike

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Matt Miller (mamille2)
Sent: Wednesday, October 24, 2012 2:14 PM
To: <[e-mail]>
Subject: [jose] Support for Wrapped Keys?

This is a topic that has been discussed some off-list between myself, Mike Jones, John Bradley, and Nat Sakimura.

For XMPP E2E, there is a need to disseminate a "session" master (symmetric) key between the sender and recipients as a wrapped key.  To date, this is done in a very custom manner by encrypting the session key with the recipient's public key, and packaging as a partial (read: broken) JWE value.

Ideally, I would like a nice way of handling wrapped keys in JWE.  The more standardized alternatives I can see are:

* Follow JWE, using the session key for both the content key and the content plaintext (feels very awkward)
* Follow JWE, generating yet-another-CMK and using the session key as the content plaintext (feels very wasteful)

Does anyone else think this is worth supporting?


- m&m

Matt Miller < [e-mail] >
Cisco Systems, Inc.

PS: JSMS supports wrapped keys, as does CMS.