Matt, if you look at the examples in
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04#section-3.1
and
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04#section-3.2,
you'll see that the encrypted key occupies more than half the total space of
the JWE in those examples - 342 characters out of 597 and 475 respectively, to
be precise. That's a big deal when operating in space-constrained
environments, such as passing JWTs as URI query parameters - where the total
URL length is often limited to 2048 characters or sometimes less. Plus there's
a significant performance advantage in not having to do the keygen for the CMK
or two encryptions, rather than one. The direct encryption mode may not be for
everyone, but for those that need it, it can be the difference between meeting
space and performance budgets, or not.
Like John, I'd be glad to talk with you about this in Vancouver.
Best wishes,
-- Mike
-----Original Message-----
From: John Bradley [mailto:[email protected]]
Sent: Thursday, July 19, 2012 2:58 PM
To: Matt Miller (mamille2)
Cc: Mike Jones; [email protected]
Subject: Re: [jose] Symmetric encryption and key agreement with and without a
separate CMK
Sorry I missed your post. I will have a look.
The idea with 1 is that it allows for the rotation of the key for the stream
cypher without the need to negotiate new shared secrets.
What bothers you about it.
We can meet up in Vancouver if you are coming
John B.
Sent from my iPad
On 2012-07-19, at 3:45 PM, "Matt Miller (mamille2)" <[email protected]> wrote:
>
> On Jul 18, 2012, at 23:23, John Bradley wrote:
>
>> I agree that is a reasonable approach.
>>
>
> I don't know that I support a). I can't articulate exactly why, other than
> to say it gives me the willies (-:
>
>> In the XMPP example from earlier it was method 2 that they were using for
>> multiple recipients, and that worked because the receiver requested the key
>> from the sender after receiving the message.
>>
>
> That was true, now the CMK is wrapped by a separate "SMK" (Session Master
> Key). See < http://tools.ietf.org/html/draft-miller-xmpp-e2e-02 >, which I
> thought I had forwarded to this list (-:
>
>> So 2 may be useful in some multi recipient scenarios though probably not all.
>>
>> John B.
>>
>> On 2012-07-18, at 7:04 PM, Mike Jones wrote:
>>
>>> Hi all,
>>>
>>> I’ve been thinking about two of our open issues, which are closely related,
>>> and am writing to make a proposal to resolve both of them. The issues are:
>>>
>>> (1) Currently we specify methods for using symmetric keys to key wrap a
>>> separate Content Master Key (CMK), but no means of using the symmetric key
>>> as the CMK directly. Some applications need this functionality, both for
>>> size and for efficiency reasons.
>>>
>>> (2) Currently we specify methods for performing key agreement and directly
>>> using the resulting key as the CMK to perform block encryption, but no
>>> means of using the agreed-upon key to wrap a separate CMK. When doing key
>>> agreement for multiple recipients, a separate CMK is needed.
>>>
>>> Thus, I propose that we define methods for filling in both of the holes
>>> above, as follows:
>>>
>>> (a) Define “alg”:”dir” (direct) to mean that the symmetric key is directly
>>> used as the CMK for the block encryption and integrity calculations, rather
>>> than as a key to wrap the CMK value.
>>>
>>> (b) Define “alg”:”ECDH-ES+A128KW” and “alg”:”ECDH-ES+A256KW” to mean that
>>> the result of the key agreement is respectively used as the 128 bit or 256
>>> bit AES Key Wrap key to wrap the CMK.
>>>
>>> Doing this will enable all four flavors, whereas we’re currently missing 2
>>> and 3 below:
>>> 1. The symmetric key used to wrap a separate CMK
>>> 2. The symmetric key used as the CMK
>>> 3. The key agreement result used to wrap a separate CMK
>>> 4. The key agreement result used as the CMK
>>>
>>> I recognize that flavors 2 and 4 are not usable with multiple recipients
>>> when methods such as JWE JSON Serialization are used (which counts on a
>>> common CMK value to enable a common ciphertext value). A note to that
>>> effect would be added to the JWA definitions of “alg”:“ECDH-ES” and
>>> “alg”:”dir” and it would be pointed out in the JWE-JS spec that “alg”
>>> values that utilize a separate CMK MUST be used when the plaintext is
>>> encrypted to multiple recipients.
>>>
>>> Comments?
>>>
>>> -- Mike
>>>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/jose
>>
>> _______________________________________________
>> jose mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/jose
>
>
> - m&m
>
> Matt Miller - <[email protected]>
> Cisco Systems, Inc.
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
