Subject: [jose] Understanding the motivation for Key Derivation?

From: Brian Campbell <[email-masked]>
Date: Wed, 4 Apr 2012 16:40:40 -0600

Hi all,

I was hoping someone could help me (hopefully it's not just me!)
understand the reasons for the introduction of the key derivation
stuff* into JWE draft -01?

I understand that it's there to derive the two keys, CEK and CIK, from
the CMK and that it is to be done when a non-AEAD algorithm is used to
encrypt the content. But what is the value of deriving the two keys as
apposed to using the CMK for both encryption and integrity?

Perhaps naively I assumed that using the CMK for both would be
sufficient.  It's randomly generated and used only for the one JWE.
It's not clear to me what benefit is provided by the additional
complexity of the derivation function as well as its conditional
application (and the potential interoperability problems that come
with such complexity). I assume there's some security benefit? But I
can't see what it is.

Any help would be appreciated.
Thanks,
Brian

* http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-7
which is referenced by
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-5
and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-6

---

From: John Bradley <[email-masked]>
Date: Wed, 4 Apr 2012 20:42:14 -0300

The use of a single key across two functions is one of things that is not provably without problems.

I agree that from an implementers point of view one key is simpler.

There is a related-key attack that using the same key would enable.  This can be combined with differential and linear attacks on symmetric key cyphers.

Generally this can be thought of as a bad thing.

What is certain is that it increases the possible attack surface,  and if the is a problem discovered as we have seen with AES-CBC it is going to be hard to change later.

We need key derivation anyway for ECDH-ES to produce a key of the correct bit length.

Doing key derivation on CMK is the theoretically proper way to do it.
Making a simplification might bite us in the future.

I suppose one way to get around the conditional application argument is to always use it to produce the CEK even with AEAD algorithms.

Regards
John B.

On 2012-04-04, at 7:40 PM, Brian Campbell wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Matt Miller <[email-masked]>
Date: Thu, 5 Apr 2012 06:49:59 -0600

Another way around the conditional in application-space is to define an AEAD algorithm composed of an encryption and hashing function.  This seems like a reasonable place to start looking at one: < http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1 >.

>> and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-6

- - m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Apr 2012 11:28:18 -0300

A couple of observations.

The current proposal provides integrity over the header,  a new AEAD alg doesn't do that.
Low level crypto is a challenge.   Re-using standard underlying algorithms like HMAC and AES-CBC allow for JS and other libs to call standard lower level crypto functions.

I am not against having another AEAD alg,  but want to help people understand the current design choice.

John B.
On 2012-04-05, at 9:49 AM, Matt Miller wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> 
> iQEcBAEBAgAGBQJPfZT4AAoJEJq6Ou0cgrSP00UIAMxGZw0K50RJPD4JWRvVqzQj
> YFYN5dpM4qG+SLll53BesKPNqSF79L5M5yp9gLW7lVTBdDGd5+k7uU+qn7rDR8kx
> c4m46Wvffbevl6KRFg+vbBA3JZz/S41/mc6Vd3hZ9ib4+1Na66Vzpqp6qOnVDvLy
> LgMqohVeXACHsxVL8BpXqDz336slFBS4gP67cI9Yail0ZUNsZAm+NcoNhnbqLlb+
> ottj9ZpLP8gnYaCus0sM2fshgWapcc4ZN6QbA9F105zEdrNwCDX5ht68Zkma7fbY
> LgFBqvqB2PtRu7SV2QGbNmaG1BGRZ9V3mKXZL/ssryLaOSVrCB5GdNHprlDGz/I=
> =174E
> -----END PGP SIGNATURE-----

---

From: Matt Miller <[email-masked]>
Date: Thu, 5 Apr 2012 08:50:53 -0600

> The current proposal provides integrity over the header,  a new AEAD alg doesn't do that.

The current proposal does not provide this for existing AEAD algorithms. 

> Low level crypto is a challenge.   Re-using standard underlying algorithms like HMAC and AES-CBC allow for JS and other libs to call standard lower level crypto functions.

The draft I noted uses AES-CBC-128 and HMAC-SHA1 (or AES-CBC-256 and HMAC-SHA-256); it's not any more low-level than the non-AEAD path specified in JWE.

> I am not against having another AEAD alg,  but want to help people understand the current design choice.

The benefit is to have a single path through the use of algorithms.  It puts the differences into the algorithm implementations, which is where they should be.

- - m&m

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Apr 2012 12:12:05 -0300

> The current proposal does not provide this for existing AEAD algorithms. 

True that is an advantage the composite CBC + HMAC has over GCM.

> The draft I noted uses AES-CBC-128 and HMAC-SHA1 (or AES-CBC-256 and HMAC-SHA-256); it's not any more low-level than the non-AEAD path specified in JWE.

I will have another look at it.
> The benefit is to have a single path through the use of algorithms.  It puts the differences into the algorithm implementations, which is where they should be.
There is no AES-CBC option without HMAC.  Perhaps we should net be calling it AES-CBC in JWA.

John B.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 5 Apr 2012 08:28:43 -0700

<no hat>

John,

I am at a loss, why do you believe that a new AEAD algorithm would not
protect the headers?

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> John Bradley
> Sent: Thursday, April 05, 2012 7:28 AM
> To: Matt Miller
> Cc: Brian Campbell; [email-masked]
> Subject: Re: [jose] Understanding the motivation for Key Derivation?
> 
> Low level crypto is a challenge.   Re-using standard underlying algorithms
like
> HMAC and AES-CBC allow for JS and other libs to call standard lower level
> crypto functions.
> 
> > Another way around the conditional in application-space is to define an
> AEAD algorithm composed of an encryption and hashing function.  This
> seems like a reasonable place to start looking at one: <
> http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1 >.
> >
> >> The use of a single key across two functions is one of things that is
not
> provably without problems.
> >>
> >> There is a related-key attack that using the same key would enable.
This
> can be combined with differential and linear attacks on symmetric key
> cyphers.
> >>
> >> What is certain is that it increases the possible attack surface,  and
if the is
> a problem discovered as we have seen with AES-CBC it is going to be hard
to
> change later.
> >> I suppose one way to get around the conditional application argument is
> to always use it to produce the CEK even with AEAD algorithms.
> >>
> >> Regards
> >> John B.
> >>
> >>> I understand that it's there to derive the two keys, CEK and CIK,
> >>> from the CMK and that it is to be done when a non-AEAD algorithm is
> >>> used to encrypt the content. But what is the value of deriving the
> >>> two keys as apposed to using the CMK for both encryption and
integrity?
> >>> *
> >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se
> >>> ction-7
> >>> which is referenced by
> >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se
> >>> ction-5 and
> >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se
> >>> ction-6 _______________________________________________
> >>> jose mailing list
> >>> [email-masked]

---

From: Matt Miller <[email-masked]>
Date: Thu, 5 Apr 2012 09:41:48 -0600

> True that is an advantage the composite CBC + HMAC has over GCM.

Maybe we should find a way to correct that.  One possible solution is to use the base64url-encoded header as the additional data (possibly truncated based on algorithm requirements).

> There is no AES-CBC option without HMAC.  Perhaps we should net be calling it AES-CBC in JWA.

I get there's no AES-CBC sans HMAC, and I completely agree that encryption without integrity protection is not worth it.  All I'm suggesting is we (or someone) define an AEAD algorithm, say "AES-CBC-HMAC-SHA2-CONCAT-KDF" or something, which pulls together the non-AEAD path from JWE into its own algorithm.

- - m&m

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Apr 2012 12:45:14 -0300

In JWE the headers are not encrypted.   

GCM provides integrity only over the encrypted content.

In the composite AES-CBC + HMAC the integrity is calculated over both the Header and the encrypted content.

The advantage of not using a AEAD algorithm is that the composite can be more JOSE aware.

I can't rule out having missed something thats why we review these things:)

John B.

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Apr 2012 12:51:01 -0300

If we can find a way to do integrity for AEAD algorithms, that would be great.

I am OK with defining one or more AES-CBC-HMAC alg.

The downside is that allowing flexibility on the HMAC size would cause a large list of alg.  
It is perhaps a flexibility vs implementation complexity argument. 

I am not super emotionally attached to having them as separate parameters.

John B.
On 2012-04-05, at 12:41 PM, Matt Miller wrote:

> iQEcBAEBAgAGBQJPfb09AAoJEJq6Ou0cgrSPFQgIAObHB26bX7zdqcyzdWdMQYpA
> H7JmkjMZSLCG1WMPUJWgg9w3+/SbxBkoTFKQC5SLzZrYXTErXD3sfzEXt5U5i/2v
> buvnqNd4ELZDsf3kosBmn6Y2h45DPlLVMT1JE2wbQDqfx6PZPdBISGdZYlPAqXWl
> cMyLKdVIBYE/4ADa2Rwswnke3dLvv4vkJUzcItAeBA0khLzS25B1Q2JpunOSKMyD
> i0SPxEJ9aZHghxmjGQtQIU9DBI7kuvCap8eD9zYj6DPGoAnEKWMr/hoWUjMhB7HH
> wEVm6dKbmH7aTVSkl4suUnU2uclurmwCB42xDNPieULQy/2T2/oKU9ERwIm0M4k=
> =dvxJ

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Apr 2012 12:53:36 -0300

Yes the KDF for ECDH-ES is baked into the alg, but we did use the same KDF to make things easier (or at least not harder)

John B.
On 2012-04-05, at 12:47 PM, Brian Campbell wrote:

> Okay, you had me at "not provably";)  Thanks for the explanation, John.
> 
> And yep - from an implementers point of view, one key is much simpler.
> I'm working on an implementation now and I'll admit that laziness was
> my first reaction to seeing the KDF and having to go find NIST Special
> Publication 800-56A. But that thought was also followed by thinking
> that the application of the KDF looks like a likely place for
> implementation, interpretation and interop problems to show up.  Maybe
> that's not a valid concern but I wanted to ask about it. And asking
> seems to have sparked some additional discussion which can't hurt.
> 
> And yes,  ECDH-ES does use the KDF but it's somewhat different as it's
> encapsulated in the algorithm rather than part of core JWE.
> 
> I assume that generating and sending two keys was not considered due
> to the goal of having the JWE compact serialization be as compact as
> possible?
> 
> I don't know if always using a KDF for the CEK, even with AEAD
> algorithms, simplifies things all that much. Maybe it does. I don't
> know. The conditional based on one aspect of the underlying algorithm
> does feel a touch awkward but I (now) understand the reasons for doing
> it that way.
> 
> On Wed, Apr 4, 2012 at 5:42 PM, John Bradley <[email-masked]> wrote:

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 5 Apr 2012 09:05:26 -0700

Ok - I see you problem.

Yes, in JWE the headers are not encrypted.
GCM provides integrity over both the encrypted content and the additional
data fields (hence the difference between AD (authenticated Data) and
AEAD(Authenticated Data with Additional Data).

All AEAD algorithms provide for the ability to have data which is not part
of the encrypted data be included in the authenticated data.  In fact AEAD
algorithms can be used as MAC algorithms in many cases by simply having an
empty string for the encrypted data (it depends in part on the internal
construction of the encrypted data stream).  I believe we verified that this
was a true statement for GCM at the last IETF meeting (in a hallway
conversation).

Jim

> From: John Bradley [mailto:[email-masked]]
> Sent: Thursday, April 05, 2012 8:45 AM
> To: Jim Schaad
> Cc: 'Matt Miller'; 'Brian Campbell'; [email-masked]
> >> The current proposal provides integrity over the header,  a new AEAD
alg
> >> doesn't do that.

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Apr 2012 13:10:58 -0300

Then we should look at including the header as the additional data for GCM.

I will have a look at it, and make a proposal for some text, unless someone else is volunteering?

John B.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 5 Apr 2012 09:47:33 -0600

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 5 Apr 2012 13:24:32 -0700

<no hat>

+1  to defining new AEAD algorithms that combine the necessary CBC + HMAC
together.

> Matt Miller
> Sent: Thursday, April 05, 2012 8:42 AM
> To: John Bradley
alg
> Maybe we should find a way to correct that.  One possible solution is to
use
> the base64url-encoded header as the additional data (possibly truncated
> based on algorithm requirements).
> 
> >>
> like HMAC and AES-CBC allow for JS and other libs to call standard lower
level
> crypto functions.
> >>>
> >>
> >> The draft I noted uses AES-CBC-128 and HMAC-SHA1 (or AES-CBC-256 and
> HMAC-SHA-256); it's not any more low-level than the non-AEAD path
> specified in JWE.
> >
> >> The benefit is to have a single path through the use of algorithms.  It
puts
> the differences into the algorithm implementations, which is where they
> should be.
> >>
> I get there's no AES-CBC sans HMAC, and I completely agree that encryption
> without integrity protection is not worth it.  All I'm suggesting is we
(or
> someone) define an AEAD algorithm, say "AES-CBC-HMAC-SHA2-CONCAT-
> KDF" or something, which pulls together the non-AEAD path from JWE into
> its own algorithm.
> 
> >>> John B.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 5 Apr 2012 15:05:39 -0600

Is it worth considering (I'm guessing the answer is no but what the
heck) going the other direction and making the separate integrity
check required regardless of the encryption algorithm?  It would mean,
when using GCM anyway, larger JWEs and also not utilizing the inherent
integrity checks provided by that class of algorithm.  But it would
also mean a cleaner encapsulation of the algorithm from the JWE
perspective and less conditional logic in JWE.

Perhaps that suggestion might be more realistic if the separate
integrity check was required but then also allowing the "none" option
from the list of JWS cryptographic algorithms  to be used for
integrity in addition to the HMAC ones.  And lastly, define some kind
of mapping or requirements between the "enc" algo used and allowed or
required "int" algorithms (i.e. "A256GCM" and "A128GCM" are the only
ones that can be used with "none").   That would provide integrity
protections, simplify the treatment of the various "enc" algorithms in
JWT (no more conditionals on the algorithm), avoid defining composite
algorithm identifiers (like A128CBC-H256), and also allow the AEAD to
use their own integrity protections.

Just some thoughts...

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 5 Apr 2012 14:24:35 -0700

<no hat>

alg
use
level
puts
(or
> KDF" or something, which pulls together the non-AEAD path from JWE into

Based on the fact that we are not placing the attributes for a given
algorithm anyplace except at the top level, I think we can probably define
AES-CBC (maybe with an -AEAD tag) as an AEAD encryption algorithm.  The
definition of the algorithm would then include the parameters "iv" and "int"
as parameters of the algorithm.  The int parameter would then define an HMAC
algorithm (or any other MAC algorithm).  It would make a great deal of sense
in this case to limit the number of items that can occur in the int field
for interoperability reasons.  This reduces the number of algorithm names.

Contra-wise (as says Tweedle-Dum) - I have no problems with creating a very
limited number of AEAD algorithm labels that include the MAC algorithm as
part of the name string.  I don't see any reason to go overboard however and
would say that two variations are probably more than is needed at this time.

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 5 Apr 2012 14:26:01 -0700

Another reason is that the algorithms may use two different key sizes and
thus you need to deal with the expansion/truncation questions.

jim

> Sent: Wednesday, April 04, 2012 4:42 PM
> To: Brian Campbell
> Cc: [email-masked]
> There is a related-key attack that using the same key would enable.  This
can
> be combined with differential and linear attacks on symmetric key cyphers.
> 
> What is certain is that it increases the possible attack surface,  and if
the is a
> problem discovered as we have seen with AES-CBC it is going to be hard to
> change later.
> 
> I suppose one way to get around the conditional application argument is to
> always use it to produce the CEK even with AEAD algorithms.
> 
> Regards
> John B.
> 
> > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sect
> > ion-7
> > which is referenced by
> > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sect
> > ion-5 and
> > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#sect
> > ion-6 _______________________________________________
> > jose mailing list
> > [email-masked]

---

From: Mike Jones <[email-masked]>
Date: Thu, 5 Apr 2012 22:18:16 +0000

As an individual, I'm not against an IETF security working group defining such algorithms, but it would seem to me that these should be separate RFC(s) from JWE, both as they have broader applicability, and because they are not essential to the JWE functionality.  Once they are approved, they could easily be added to the set of supported algorithms in in the JWA spec.  But I worry about coupling the JWE spec to this largely orthogonal encryption algorithm work.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Thursday, April 05, 2012 1:25 PM
To: 'Matt Miller'; 'John Bradley'
Cc: 'Brian Campbell'; [email-masked]
Subject: Re: [jose] Understanding the motivation for Key Derivation?

<no hat>

+1  to defining new AEAD algorithms that combine the necessary CBC + 
+HMAC
together.

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Matt Miller
alg
use
> the base64url-encoded header as the additional data (possibly 
> truncated based on algorithm requirements).
> 
> >>
level
puts
> the differences into the algorithm implementations, which is where 
> they should be.
> >>
> I get there's no AES-CBC sans HMAC, and I completely agree that 
> encryption without integrity protection is not worth it.  All I'm 
> suggesting is we
(or
> someone) define an AEAD algorithm, say "AES-CBC-HMAC-SHA2-CONCAT- KDF" 
> or something, which pulls together the non-AEAD path from JWE into its 
> own algorithm.
> 
> >>> John B.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 10 Apr 2012 17:05:49 -0600

That's a good point that I hadn't considered. But it leads me to another
question. What key size(s) should be used for generated the Content
Integrity Key? I ask because HMAC can take keys of arbitrary length.

I did little reading of RFC 2104 "HMAC: Keyed-Hashing for Message
Authentication"* and it seems to suggest that an optimal key length would
be equal to the hash output length. But for the sake of interoperability,
it seems like JWE/JWA should be very specific about key lengths for derived
keys for each integrity algorithm (if this is already in the, I couldn't
find it, so please excuse me and point me to the text).

* §3 of http://tools.ietf.org/html/rfc2104

---

From: Mike Jones <[email-masked]>
Date: Tue, 10 Apr 2012 23:15:14 +0000

Eric Rescorla recommended that key sizes equal to the hash output sizes be used in his presentation in Paris (attached).

Thanks for pointing out that the spec needs to nail this down!

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Tuesday, April 10, 2012 4:06 PM
To: Jim Schaad
Cc: John Bradley; [email-masked]
Subject: Re: [jose] Understanding the motivation for Key Derivation?

That's a good point that I hadn't considered. But it leads me to another question. What key size(s) should be used for generated the Content Integrity Key? I ask because HMAC can take keys of arbitrary length.

I did little reading of RFC 2104 "HMAC: Keyed-Hashing for Message Authentication"* and it seems to suggest that an optimal key length would be equal to the hash output length. But for the sake of interoperability, it seems like JWE/JWA should be very specific about key lengths for derived keys for each integrity algorithm (if this is already in the, I couldn't find it, so please excuse me and point me to the text).

* §3 of http://tools.ietf.org/html/rfc2104
On Thu, Apr 5, 2012 at 3:26 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
Another reason is that the algorithms may use two different key sizes and
thus you need to deal with the expansion/truncation questions.

jim

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> John Bradley
> Cc: [email-masked]<mailto:[email-masked]>
can
the is a
> > [email-masked]<mailto:[email-masked]>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 11 Apr 2012 09:18:56 -0600

Thanks Mike, I guess I should have stayed for the week in Paris, eh?

Just to be totally clear - and it probably already is so this will be
redundant but what the heck - that presentation talks about minimum
key length recommendations. Which is useful in general and also as
input into this discussion.  But JWE (or JWA - I'm not sure) needs to
define the *exact* key lengths as input into the KDF for the various
HMAC integrity algorithms. Key sizes equal to the hash output sizes
makes sense but it just needs to be made explicit.

Thanks,
B

On Tue, Apr 10, 2012 at 5:15 PM, Mike Jones <[email-masked]> wrote:
> Eric Rescorla recommended that key sizes equal to the hash output sizes be
> used in his presentation in Paris (attached).
>
>
>
> Brian Campbell
> Authentication"* and it seems to suggest that an optimal key length would be
> equal to the hash output length. But for the sake of interoperability, it
> seems like JWE/JWA should be very specific about key lengths for derived

---

From: Mike Jones <[email-masked]>
Date: Wed, 11 Apr 2012 15:26:14 +0000

Agreed

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Wednesday, April 11, 2012 8:19 AM
To: Mike Jones
Cc: John Bradley; Jim Schaad; [email-masked]
Subject: Re: [jose] Understanding the motivation for Key Derivation?

Just to be totally clear - and it probably already is so this will be redundant but what the heck - that presentation talks about minimum key length recommendations. Which is useful in general and also as input into this discussion.  But JWE (or JWA - I'm not sure) needs to define the *exact* key lengths as input into the KDF for the various HMAC integrity algorithms. Key sizes equal to the hash output sizes makes sense but it just needs to be made explicit.

Thanks,
B

On Tue, Apr 10, 2012 at 5:15 PM, Mike Jones <[email-masked]> wrote:
> Eric Rescorla recommended that key sizes equal to the hash output 
> sizes be used in his presentation in Paris (attached).
>
>
>
>                                                                 -- 
> Mike
> Of Brian Campbell
> That's a good point that I hadn't considered. But it leads me to 
> another question. What key size(s) should be used for generated the 
> Content Integrity Key? I ask because HMAC can take keys of arbitrary length.
>
> Authentication"* and it seems to suggest that an optimal key length 
> would be equal to the hash output length. But for the sake of 
> interoperability, it seems like JWE/JWA should be very specific about 
> key lengths for derived keys for each integrity algorithm (if this is 
> already in the, I couldn't find it, so please excuse me and point me to the text).
>
> Another reason is that the algorithms may use two different key sizes 
> and thus you need to deal with the expansion/truncation questions.
>
>
> jim
>
>> Of John Bradley
>> not provably without problems.
>>
>> problem discovered as we have seen with AES-CBC it is going to be 
>> hard to change later.
>>
>> I suppose one way to get around the conditional application argument 
>> is to always use it to produce the CEK even with AEAD algorithms.
>>
>> Regards
>> John B.
>>
>> > two keys as apposed to using the CMK for both encryption and integrity?
>> >
>> > with such complexity). I assume there's some security benefit? But 
>> > I can't see what it is.
>> >

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 11 Apr 2012 09:10:22 -0700

<no hat>

John, 

 I would be nice if you did this.  Personally I would like to see the text
move back to the -00 version as the base to start from.   I would be nice if
the description was strictly in terms of how AEAD algorithms are processed.
For the S/MIME work, we would still use the term CEK for the key fed into an
AEAD algorithm even if the algorithm later produced two different keys for
use in the encryption and authentication processing.  The details of that
would be purely internal to the algorithm description.

As a part of this I think it would be more reasonable to move the details of
how to do the CBC/HMAC algorithm to the algorithms document rather than
putting in this document so that this document is simpler and clearer.

Jim

> Sent: Thursday, April 05, 2012 9:11 AM
> To: Jim Schaad
> I will have a look at it, and make a proposal for some text, unless
someone
> else is volunteering?
> >> In the composite AES-CBC + HMAC the integrity is calculated over both
> the
> >> Header and the encrypted content.
> >>
> >> The advantage of not using a AEAD algorithm is that the composite can
be
> >> more JOSE aware.
> >> Of
> >> is
> I
> >>>>>>> ction-6

---

From: John Bradley <[email-masked]>
Date: Wed, 11 Apr 2012 13:29:13 -0300

Yes making both AEAD and our composite HMAC process the envelope in the same way so that as much as possible they look the same is a good idea.

I am just off to Munich for EIC.  I will try to get to it next week when Mike and I are at EIC.

John B.

---

From: Matt Miller <[email-masked]>
Date: Wed, 11 Apr 2012 10:31:23 -0600

I was planning to start writing up a composite CBC/HMAC algorithm, based partly on the work done by David McGrew.  Is there still interest in this?

>>>>>>> -----END PGP SIGNATURE-----

- m&m

---

From: John Bradley <[email-masked]>
Date: Wed, 11 Apr 2012 13:43:53 -0300

We have the mandatory HMAC for non AEAD now.  

While it is possible to do it as an algorithm it requires munging the HMAC and the CMK together in some way.

There is no reason not to improve on the current RFC for AES128+SHA1 as that is quite specific. 

I think it remains to be seen if that is preferable to allowing the integrity and symmetric encryption to be defined separately at the JOSE layer.

John B.