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