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

From: Derek Atkins <[email-masked]>
Date: Mon, 11 May 2015 11:22:47 -0400

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

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 11 May 2015 14:42:00 -0700

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
> 
> > 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.
> >
> > 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
> > 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.
> >
> >

---

From: Mike Jones <[email-masked]>
Date: Mon, 11 May 2015 22:25:19 +0000

>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

> wonder whether you need to add a tag that says whether it's an 
> encrypted key or encrypted 'data'?
> 
> -derek
> 
> > 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.
> > 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.
in the
> > 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

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 11 May 2015 15:46:52 -0700

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

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

---

From: Mike Jones <[email-masked]>
Date: Mon, 11 May 2015 23:18:46 +0000

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.

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

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

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

> 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
> 
In the
level
> > 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 
> > > 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.
> > > recipient structure (i.e. iv and aad), some of these elements 
> > > later appeared as part of algorithm descriptions (iv is a header 
> > > parameter
> > > 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.
> > > 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.
> > >
> > >

---

From: ⌘ Matt Miller <[email-masked]>
Date: Tue, 12 May 2015 10:55:52 -0600

I agree with Derek and Jim.  I would like to reuse the structure, and
I the context makes it clear enough to tell the difference.

- -- 
- - m&m

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

On 5/11/15 3:42 PM, Jim Schaad wrote:
> 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
>> 
>>> 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 
>>> 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
>>> 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
>>> 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
>

---

From: Derek Atkins <[email-masked]>
Date: Tue, 12 May 2015 14:16:05 -0400

> 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 goo…

...

-derek

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 18 May 2015 09:49:16 -0700

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

[JLS]  This depends on if you are carrying a key just as a content, or if
you are carrying a key for use in the next layer down (i.e. as a recipient
structure).  In the first case, no there is no data and a JWK structure as
the content would be necessary.  In the latter case, the key type is known
because it is advertised in the next layer down.

Jim

> 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.

...

-derek

content?
>> > > elements is used to encode both the content encryption and each 
>> > > of the recipient
>> structures.
>> > > 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

---

From: Derek Atkins <[email-masked]>
Date: Wed, 20 May 2015 14:12:35 -0400

> because it is advertised in the next layer down.

This says to me that there are use-cases where the extra data is not
redundant, so it should be possible to put it in there.

-derek

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 20 May 2015 12:30:27 -0700

> Sent: Wednesday, May 20, 2015 11:13 AM
> To: Jim Schaad
> Cc: 'Mike Jones'; [email-masked]
> > 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",
> > Encrypting just the bytes is smaller, and contains no redundant
> > information that will simply be discarded.
> >
> > 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?
> >
> > [JLS]  This depends on if you are carrying a key just as a content, or
> > if you are carrying a key for use in the next layer down (i.e. as a
> > recipient structure).  In the first case, no there is no data and a
> > JWK structure as the content would be necessary.  In the latter case,
> > the key type is known because it is advertised in the next layer down.
> 
redundant,
> so it should be possible to put it in there.

Not redundant in the first case or in the second case?

Jim