I believe that this is an important discussion. I'd be interested to hear
other's opinions about direct key encryption. For instance, while the working
group decided that all plaintext encryption algorithms we used would also
provide integrity, does the working group believe that integrity is necessary
in Matt's case as well?
-- Mike
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Matt
Miller (mamille2)
Sent: Tuesday, October 30, 2012 7:54 AM
To: Mike Jones
Cc: <[email protected]>
Subject: Re: [jose] Support for Wrapped Keys?
On Oct 24, 2012, at 4:03 PM, Mike Jones <[email protected]> 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 < [email protected] >
Cisco Systems, Inc.
> -- Mike
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Matt
> Miller (mamille2)
> Sent: Wednesday, October 24, 2012 2:14 PM
> To: <[email protected]>
> 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 < [email protected] >
> Cisco Systems, Inc.
>
> PS: JSMS supports wrapped keys, as does CMS.
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
