Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients

From: Mike Jones <[email-masked]>
Date: Sun, 7 Jun 2015 00:33:08 +0000

Replying to Derek's question " I guess my question to you (not being as intimately familiar with JWKs) is whether the algorithm of the wrapped (encrypted) key is exposed somewhere outside the wrapping?"...

Yes, in JOSE, the key wrap algorithm is always explicitly declared in the JWE "alg" header parameter http://tools.ietf.org/html/rfc7516#section-4.1.1.  Repeating the algorithm in the equivalent of a JWK "alg" member http://tools.ietf.org/html/rfc7517#section-4.4 would only add redundant information, both increasing the message size, and possibly worse, creating new error cases that would have to be checked for.  For instance, a new error that this approach would introduce that is impossible for JWE encrypted_key values is for the two algorithm declarations not to match.  It's simpler and less error prone when the data structure can't represent such inconsistent states in the first place.

				Cheers,
				-- Mike

-----Original Message-----
From: Derek Atkins [mailto:[email-masked]] 
Sent: Tuesday, May 12, 2015 11:16 AM
To: Mike Jones
Cc: Jim Schaad; 'Derek Atkins'; [email-masked]
Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients

Mike Jones <[email-masked]> writes:

> What was presented to the JOSE working group in Denver by Richard Barnes was the option of representing encrypted keys as encrypted JWK structures, rather than just encrypted bare keys.  The choice is between encrypting:
>     {"kty":"oct",
>      "alg":"A128KW",
>      "k":"GawgguFyGrWKav7AX4VKUg"}
> or simply the bytes that "k" represents in base64url encoded form.  Encrypting just the bytes is smaller, and contains no redundant information that will simply be discarded.

Is it necesarily redundant?  What says that the key being encrypted
(wrapped) is of the exact same algorithm/size/mode as the method being used to encrypt/wrap it?

E.g., I can certainly posit a situation where I am encrypting an AES-128-CCM key with an AES-256-GCM key (Or even more, I could see encrypting a 3DES key with AES).  In this case the extra information is definitely not redundant, and is certainly not derivable just from 'k'.

I guess my question to you (not being as intimately familiar with JWKs) is whether the algorithm of the wrapped (encrypted) key is exposed somewhere outside the wrapping?

> That's why the JOSE working group rejected using encrypted JWKs as the encrypted_key representation.  If the "encrypt structure" you're referring to is different than this, it would probably be good to explain what it is, how you're proposing to reuse it, and why reusing it doesn't add extraneous unused information, as Richard's proposal in Denver did.

...

> 				-- Mike

-derek

> -----Original Message-----
> From: Jim Schaad [mailto:[email-masked]]
> Sent: Monday, May 11, 2015 11:47 PM
> To: Mike Jones; 'Derek Atkins'
> Cc: [email-masked]
> Subject: RE: [Cose] Issue: Reuse the Enrypt structure for recipients
>
> I don't understand what you are arguing for or against.
>
> Are you saying don't do the reuse of the structure?
> Are you saying don't do the extra tagging of encrypted key vs encrypted content?
> Are you saying something completely different?
>
> jim
>
>> -----Original Message-----
>> From: Mike Jones [mailto:[email-masked]]
>> Sent: Monday, May 11, 2015 3:25 PM
>> To: Jim Schaad; 'Derek Atkins'
>> Cc: [email-masked]
>> Subject: RE: [Cose] Issue: Reuse the Enrypt structure for recipients
>> 
>> From my point of view, the JOSE WG didn't reject encrypting a JWK to 
>> represent the encrypted key because it was a change.  The working 
>> group rejected it because there was no need to carry any data that 
>> would remain unused about the encrypted key, when just the the 
>> encrypted key value
> itself
>> would do.  Particularly in a space-constrained environment, carrying 
>> extra metadata about a key that will only be discarded seems wasteful 
>> in the extreme.
>> 
>> I would advocate having the encrypted_key value remain only an 
>> encrypted form of the CEK value, adding nothing extra.
>> 
>> 				- Mike
>> 
>> -----Original Message-----
>> From: Cose [mailto:[email-masked]] On Behalf Of Jim Schaad
>> Sent: Monday, May 11, 2015 10:42 PM
>> To: 'Derek Atkins'
>> Cc: [email-masked]
>> Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients
>> 
>> At the present time, that information can easily be inferred by context.
> In the
>> event that we want to talk about use the "recipient" structure as a 
>> top
> level
>> object then I think this question would need to be revisited.
>> 
>> Jim
>> 
>> 
>> > -----Original Message-----
>> > From: Derek Atkins [mailto:[email-masked]]
>> > Sent: Monday, May 11, 2015 8:23 AM
>> > To: Jim Schaad
>> > Cc: [email-masked]
>> > Subject: Re: [Cose] Issue: Reuse the Enrypt structure for 
>> > recipients
>> >
>> > I believe that yes, the map should be reused, however if we do that 
>> > I wonder whether you need to add a tag that says whether it's an 
>> > encrypted key or encrypted 'data'?
>> >
>> > -derek
>> >
>> > "Jim Schaad" <[email-masked]> writes:
>> >
>> > > Question:  Reuse Encrypt body map for recipients
>> > >
>> > > Discussion:
>> > >
>> > > The concept of using the same structure for both recipients and 
>> > > the base encryption map was introduced to the JOSE working group 
>> > > at the Denver meeting.  The JOSE working group rejected the idea 
>> > > as being too much of a change to make in the current working code.
>> > > The concept is that the same data structure, with the same 
>> > > elements is used to encode both the content encryption and each 
>> > > of the recipient
>> structures.
>> > > While in JOSE, many of the same elements are not present in the 
>> > > recipient structure (i.e. iv and aad), some of these elements 
>> > > later appeared as part of algorithm descriptions (iv is a header 
>> > > parameter
>> > defined for AES-GCM key wrapping).
>> > >
>> > > Using the same structure for encrypting content as well as 
>> > > encrypting keys allows for some neat tricks to be played at a 
>> > > later date if needed.  One example is that you could separate the 
>> > > key wrapping algorithm, and the ECDH-KDF algorithm pair into 
>> > > separate layers.  This allows one to move towards a Chinese Menu 
>> > > method of selecting and using algorithms rather than the current 
>> > > algorithm suite
>> method.
>> > > While I would not recommend that this happen in the current 
>> > > specification, it might be nice to keep it open as an option to 
>> > > be used
>> in the
>> > future as new algorithms are added.
>> > >
>> > > Another advantage of doing this folding is in code size.  In my 
>> > > implementation, I have created the recipient class as inheriting 
>> > > from the encryption body class.  The recipient class contains 
>> > > only code that deals with the cryptography of key management.  
>> > > All of the
>> > encoding/decoding is
>> > > handled by the base encryption class.   If the structures are kept
>> separate
>> > > as they are today then that code would need to be added to the 
>> > > recipient class.  While my code does not currently deal with idea 
>> > > of having multiple layers of key management.  I believe that this 
>> > > would be a minimal addition to the current code base.
>> > >
>> > >
>> > > _______________________________________________
>> > > Cose mailing list
>> > > [email-masked]
>> > > https://www.ietf.org/mailman/listinfo/cose
>> > >
>> > >
>> >
>> > --
>> >        Derek Atkins                 617-623-3745
>> >        [email-masked]             www.ihtfp.com
>> >        Computer and Internet Security Consultant
>> 
>> _______________________________________________
>> Cose mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/cose
>
>
>

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Derek Atkins <[email-masked]>
Date: Mon, 08 Jun 2015 11:37:31 -0400

I guess I'm still confused...

What would the structure look like for encrypting an AES-128 key with
AES-256 encryption?

I would expect it to look something like:

JWE: { alg: aes256,
       data: <key> }

where <key> is the following data, encrypted and base64 encoded:

<key> : { alg: aes128,
          key: <hex or base64 of aes128 key> }

If the key used for the encryption of the JWE is not the same algorithm
as the key being encrypted then you NEED to be explicit.

Again, maybe I'm being confused by something because I'm not intimately
familiar with the data structures.  But I'll point out that this is why
Kerberos has both a KeyType and EncType, because the key being encrypted
could be for a different algorithm than the weapping of said key.

-derek

Mike Jones <[email-masked]> writes:

> Replying to Derek's question " I guess my question to you (not being
> as intimately familiar with JWKs) is whether the algorithm of the
> wrapped (encrypted) key is exposed somewhere outside the wrapping?"...
>
> Yes, in JOSE, the key wrap algorithm is always explicitly declared in
> the JWE "alg" header parameter
> http://tools.ietf.org/html/rfc7516#section-4.1.1.  Repeating the
> algorithm in the equivalent of a JWK "alg" member
> http://tools.ietf.org/html/rfc7517#section-4.4 would only add
> redundant information, both increasing the message size, and possibly
> worse, creating new error cases that would have to be checked for.
> For instance, a new error that this approach would introduce that is
> impossible for JWE encrypted_key values is for the two algorithm
> declarations not to match.  It's simpler and less error prone when the
> data structure can't represent such inconsistent states in the first
> place.
>
> 				Cheers,
> 				-- Mike
>
>> That's why the JOSE working group rejected using encrypted JWKs as
>> the encrypted_key representation.  If the "encrypt structure" you're
>> referring to is different than this, it would probably be good to
>> explain what it is, how you're proposing to reuse it, and why
>> reusing it doesn't add extraneous unused information, as Richard's
>> proposal in Denver did.
>
> ...
>
>> 				-- Mike
>
> -derek
>