Re: [jose] Support for Wrapped Keys?

["Matt Miller (mamille2)" <[e-mail]>]

On Oct 24, 2012, at 4:03 PM, Mike Jones <[e-mail]> wrote:

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

That would work, but I wonder if this complicates implementation interfaces too much.

Here's what I mean:  As far as I can tell, there's no real need for a user of a JWE implementation to actually know about the CMK.  For encryption, the implementation could generate it using a suitable RNG based on the (header) parameters, and encode it with the one key provided by the user.  For decryption, it uses parameters from the header and some determination of the "alg" key (passed in, from a keystore, etc etc), decrypts the CMK with that key, then decrypts the ciphertext with the CMK.

In this instance, decryption requires at a bare minimum multiple outputs: plaintext plus the CMK.  It might be nice for an implementation to provide the rest (header, integrity), but these are easily obtained from the input data in the first place.

Personally, I think it would be ideal if there were a way to say "use this asymmetric key to encrypt the plaintext, but don't worry about a CMK."

I think what we had talked about in Vancouver was effectively to use an "alg" of "dir" and an "enc" of "RSA-OAEP", which I'm sure has its own set of objections (aside from currently being disallowed).

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

Personally, I don't really care if there is integrity protection here.  I'm probably alone (with Richard) on this one, though.

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


- m&m

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

> 				-- 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.
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose