Subject: Re: [Cose] Issue: Encoding for a single recipient or structure

From: Mike Jones <[email-masked]>
Date: Tue, 30 Jun 2015 22:44:33 +0000

Hi Jim,

Per your suggestion in response to my issue 1, I'm reviewing this thread.  (I'm also including the original message below so WG members who joined the list when the WG was formed will see it.)

First, let me ask a question to see if I correctly understand the problem with your option (1) below.  JWE used "alg" for the key management algorithm and "enc" for the content encryption algorithm.  Likewise, JWE used "encrypted_key" for the encrypted key value and "ciphertext" for the encrypted plaintext.  Since there were no name collisions, all could live in the top-level JSON object.  Whereas, your current COSE draft uses the equivalent of "alg" for both algorithms and the equivalent of "ciphertext" for both encrypted values, hence the label collisions you are citing below, correct?

If my understanding is right, then unless a JWE-like approach were adopted in which different labels are used for the different purposes, then yes, I agree that (1) wouldn't work.  Was this change to a single set of labels the intended topic of the thread "[Cose] Issue:  Reuse the Enrypt structure for recipients"?  I'm asking because a lot of the thread ended up being about a different topic - whether the encrypted_key value would contain just an encrypted bare key or the equivalent of an encrypted JWK structure.

You asked if I had anything new to add to the discussion.  I'll add this...

Just like for JOSE, I expect that many applications will implement only the COSE features that they need.  For instance, JWT [RFC 7519] implementations only need to implement the JOSE Compact Serializations - not the JSON Serializations.  I expect there to be many COSE applications that will similarly only implement support for a single recipient.  This would save on code size and be simpler.

I believe that applications that only use a single recipient will be the most common, hence the goal stated in my review to optimize for this case.  Assuming we take your option (1) off the table and limit discussion to only your options (2) and (3) below, then the choice seems to be between these effective grammars for the single recipient case:
	(2) recipients: {recipient_data}
	(3) recipients: [{recpient_data}]

If you're only ever building code for the single recipient case, then (2) is simpler.  But I agree that if you're using code that supports multiple recipients, then (3) is simpler, if somewhat less elegant.

What do others think about this tradeoff?

				-- Mike

-----Original Message-----
From: Cose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Thursday, April 30, 2015 3:59 PM
To: [email-masked]
Subject: [Cose] Issue: Encoding for a single recipient or structure

Question: Flattened encoding -
a)  Roll into parent map
b)  Just be a map
c)  Single element in array

Discussion:

A late addition to the JOSE specification was the ability to fold a single recipient map into the base encryption or signature map.  This is doable because the keys for all of the maps in question are unique.  This would not be true if the issue on reusing the encryption body for the recipient structure is accepted.  This issue is being discussed in a separate mail thread (but is current).  If arrays were to be used at the top level, one just appends the elements to the end of the base structure  (see examples in the current document).

There are three different options that can be selected at this point:

1)  The recipient/signature map is folded into the encryption/signing message top level.  If we accept the change for using the same structure for both the encryption body and the recipients, this is not a viable option due to collisions of keys in the map.

2)  The recipient/signature element in the base map is permitted to be either an array of recipient/signature elements or a single recipient/signature map.  This option was rejected by the JOSE group as being too complicated for programmers to deal with.  The cost of this option is 2 bytes over option one.  (One byte for the recipients key, one byte for the map marker.) 

CDDL grammar would be:  recipients: [+[recipient_data]] / {recipient_data}

3)  We do not support any special form of dealing with a single recipient.
The cost of this option is 3 bytes over option one.  (One byte for the recipients key, one byte for the array marker, one byte for the map marker.)

CDDL grammar would be:  recipients: [+[recpient_data]]

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

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 30 Jun 2015 17:15:04 -0700

> From: Mike Jones [mailto:[email-masked]]
> Sent: Tuesday, June 30, 2015 3:45 PM
> To: Jim Schaad; [email-masked]
> Subject: RE: [Cose] Issue: Encoding for a single recipient or structure
> 
> Hi Jim,
> 
> Per your suggestion in response to my issue 1, I'm reviewing this thread.
> (I'm also including the original message below so WG members who joined
> the list when the WG was formed will see it.)
> 
> First, let me ask a question to see if I correctly understand the problem
with
> your option (1) below.  JWE used "alg" for the key management algorithm
> and "enc" for the content encryption algorithm.  Likewise, JWE used
> "encrypted_key" for the encrypted key value and "ciphertext" for the
> encrypted plaintext.  Since there were no name collisions, all could live
in
> the top-level JSON object.  Whereas, your current COSE draft uses the
> equivalent of "alg" for both algorithms and the equivalent of "ciphertext"
> for both encrypted values, hence the label collisions you are citing
below,
> correct?
> 
> If my understanding is right, then unless a JWE-like approach were adopted
> in which different labels are used for the different purposes, then yes, I
> agree that (1) wouldn't work.  Was this change to a single set of labels
the
> intended topic of the thread "[Cose] Issue:  Reuse the Enrypt structure
for
> recipients"?  I'm asking because a lot of the thread ended up being about
a
> different topic - whether the encrypted_key value would contain just an
> encrypted bare key or the equivalent of an encrypted JWK structure.
> 
> Just like for JOSE, I expect that many applications will implement only
the
> COSE features that they need.  For instance, JWT [RFC 7519]
> implementations only need to implement the JOSE Compact Serializations -
> not the JSON Serializations.  I expect there to be many COSE applications
> that will similarly only implement support for a single recipient.  This
would
> save on code size and be simpler.
> 
> I believe that applications that only use a single recipient will be the
most
> common, hence the goal stated in my review to optimize for this case.
> Assuming we take your option (1) off the table and limit discussion to
only
> your options (2) and (3) below, then the choice seems to be between these
> effective grammars for the single recipient case:
> If you're only ever building code for the single recipient case, then (2)
is
> simpler.  But I agree that if you're using code that supports multiple
> recipients, then (3) is simpler, if somewhat less elegant.

I am going to make the same challenge to you that I made to Derik at one
point.

Can you provide code to show that option 2 is significantly larger than
option 3?

Jim

> A late addition to the JOSE specification was the ability to fold a single
> recipient map into the base encryption or signature map.  This is doable
> because the keys for all of the maps in question are unique.  This would
not
> be true if the issue on reusing the encryption body for the recipient
> structure is accepted.  This issue is being discussed in a separate mail
thread
> (but is current).  If arrays were to be used at the top level, one just
appends
> the elements to the end of the base structure  (see examples in the
current
> document).
> 1)  The recipient/signature map is folded into the encryption/signing
> message top level.  If we accept the change for using the same structure
for
> both the encryption body and the recipients, this is not a viable option
due
> to collisions of keys in the map.
> 
> 2)  The recipient/signature element in the base map is permitted to be
> either an array of recipient/signature elements or a single
> recipient/signature map.  This option was rejected by the JOSE group as
> being too complicated for programmers to deal with.  The cost of this
> option is 2 bytes over option one.  (One byte for the recipients key, one
> byte for the map marker.)
> 
> The cost of this option is 3 bytes over option one.  (One byte for the
> recipients key, one byte for the array marker, one byte for the map
marker.)

---

From: Mike Jones <[email-masked]>
Date: Wed, 1 Jul 2015 00:45:53 +0000

Reply inline below...

> From: Jim Schaad [mailto:[email-masked]]
> Sent: Tuesday, June 30, 2015 5:15 PM
> To: Mike Jones; [email-masked]
> > (I'm also including the original message below so WG members who
> > joined the list when the WG was formed will see it.)
> >
> > your option (1) below.  JWE used "alg" for the key management
> > algorithm and "enc" for the content encryption algorithm.  Likewise,
> > JWE used "encrypted_key" for the encrypted key value and "ciphertext"
> > for the encrypted plaintext.  Since there were no name collisions, all
> > could live
> in
> > If my understanding is right, then unless a JWE-like approach were
> > adopted in which different labels are used for the different purposes,
> > then yes, I agree that (1) wouldn't work.  Was this change to a single
> > set of labels
> the
> > different topic - whether the encrypted_key value would contain just
> > an encrypted bare key or the equivalent of an encrypted JWK structure.
> >
> > implementations only need to implement the JOSE Compact Serializations
> > - not the JSON Serializations.  I expect there to be many COSE
> > applications that will similarly only implement support for a single
> > recipient.  This
> would
> > your options (2) and (3) below, then the choice seems to be between
> > these effective grammars for the single recipient case:
> Can you provide code to show that option 2 is significantly larger than option
> 3?

I'm not saying that there's a significant code size difference.  Maybe you can tell us how much code would be removed from your implementation if you #ifdef'ed out the loops associated with producing and consuming the recipients arrays and just replaced it with code using a singleton array value (option 3) or simply a recipient_data map value (option 2).  I admit up front that there will be almost no code size difference between 2 or 3 if the implementation has been compiled to only support a single recipient.

My main point in raising this issue now is we're likely to hear the same thing about COSE that Richard Barnes heard from developers who were really using the JSON Serializations before we added the flattened data representation - that having to emit and parse a singleton array is ugly, awkward, etc.

This isn't a show-stopper to me, but now that there's a working group, I wanted to raise the issue for the working group to explicitly consider up front, rather than wait until people are using early implementations and we hear back from developers "why couldn't this have been simpler in the simple case"?

				Cheers,
				-- Mike

> > A late addition to the JOSE specification was the ability to fold a
> > single recipient map into the base encryption or signature map.  This
> > is doable because the keys for all of the maps in question are unique.
> > This would
> not
> > recipient/signature map.  This option was rejected by the JOSE group
> > as being too complicated for programmers to deal with.  The cost of
> > this option is 2 bytes over option one.  (One byte for the recipients
> > key, one byte for the map marker.)
> >

---

From: Dick Hardt <[email-masked]>
Date: Tue, 30 Jun 2015 18:00:39 -0700

If I'm writing a library and I have to support multiple recipients to be
compliant, then given a choice between dealing with both a singleton and an
array(a) vs just an array (c), then I'll pick just an array (c). ... or am
I missing some aspect of how this is simpler Mike?

On Tue, Jun 30, 2015 at 5:45 PM, Mike Jones <[email-masked]>
wrote:

> option
> I'm not saying that there's a significant code size difference.  Maybe you
> can tell us how much code would be removed from your implementation if you
> #ifdef'ed out the loops associated with producing and consuming the
> recipients arrays and just replaced it with code using a singleton array
> value (option 3) or simply a recipient_data map value (option 2).  I admit
> up front that there will be almost no code size difference between 2 or 3
> if the implementation has been compiled to only support a single recipient.
>
> My main point in raising this issue now is we're likely to hear the same
> thing about COSE that Richard Barnes heard from developers who were really
> using the JSON Serializations before we added the flattened data
> representation - that having to emit and parse a singleton array is ugly,
> awkward, etc.
>
> This isn't a show-stopper to me, but now that there's a working group, I
> wanted to raise the issue for the working group to explicitly consider up
> front, rather than wait until people are using early implementations and we
> hear back from developers "why couldn't this have been simpler in the
> simple case"?
>
>                                 Cheers,
>                                 -- Mike
>
> > Jim
> >
> > >

---

From: Mike Jones <[email-masked]>
Date: Wed, 1 Jul 2015 01:11:51 +0000

My underlying assumption is that just like we did in JOSE, you *don’t* have to support multiple recipients to be compliant.  http://tools.ietf.org/html/rfc7515#section-7 says:

   JWSs use one of two serializations: the JWS Compact Serialization or
   the JWS JSON Serialization.  Applications using this specification
   need to specify what serialization and serialization features are
   used for that application.  For instance, applications might specify
   that only the JWS JSON Serialization is used, that only JWS JSON
   Serialization support for a single signature or MAC value is used, or
   that support for multiple signatures and/or MAC values is used.  JWS
   implementations only need to implement the features needed for the
   applications they are designed to support.

Indeed, I believe that we should add equivalent text to COSE, because it’s even more likely in constrained environments than Web environments that applications will specify that they are only using subsets of the COSE-defined features and that general-purpose libraries will be compiled for specific applications with #ifdef settings to remove unused code paths.  I plan to propose exact text along these lines for inclusion.

                                                                -- Mike

From: Dick Hardt [mailto:[email-masked]]
Sent: Tuesday, June 30, 2015 6:01 PM
To: Mike Jones
Cc: Jim Schaad; [email-masked]
Subject: Re: [Cose] Issue: Encoding for a single recipient or structure

If I'm writing a library and I have to support multiple recipients to be compliant, then given a choice between dealing with both a singleton and an array(a) vs just an array (c), then I'll pick just an array (c). ... or am I missing some aspect of how this is simpler Mike?

On Tue, Jun 30, 2015 at 5:45 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Reply inline below...

> From: Jim Schaad [mailto:[email-masked]<mailto:[email-masked]>]
> To: Mike Jones; [email-masked]<mailto:[email-masked]>
> > From: Mike Jones [mailto:[email-masked]<mailto:[email-masked]>]
> > To: Jim Schaad; [email-masked]<mailto:[email-masked]>

                                Cheers,
                                -- Mike

> > From: Cose [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jim Schaad
> > To: [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>

_______________________________________________
Cose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cose

---

From: Dick Hardt <[email-masked]>
Date: Tue, 30 Jun 2015 18:16:53 -0700

Thanks for the refresher MIke.

I expect that if I want to deploy COSE, I would be adding support to the
JOSE libraries I already have that I would deploy on the server, so a
consistent data model would be very beneficial and increase the odds that
it is correct and hence secure.

If there is agreement that multiple recipients is optional, then I would
strongly prefer option (a).

I'm sure this was covered in JOSE, but I don't know of any scenarios where
I would need multiple recipients -- particularly in a constrained
environment. Is there a multiple recipient use case documented somewhere?

On Tue, Jun 30, 2015 at 6:11 PM, Mike Jones <[email-masked]>
wrote:

>  My underlying assumption is that just like we did in JOSE, you **don’t**
> have to support multiple recipients to be compliant.
> http://tools.ietf.org/html/rfc7515#section-7 says:
>
>
>
> Indeed, I believe that we should add equivalent text to COSE, because it’s
> even more likely in constrained environments than Web environments that
> applications will specify that they are only using subsets of the
> COSE-defined features and that general-purpose libraries will be compiled
> for specific applications with #ifdef settings to remove unused code
> paths.  I plan to propose exact text along these lines for inclusion.
>
>
>
>                                                                 -- Mike
>
>
>
>
>
> *From:* Dick Hardt [mailto:[email-masked]]
> *Sent:* Tuesday, June 30, 2015 6:01 PM
> *To:* Mike Jones
> *Cc:* Jim Schaad; [email-masked]
> *Subject:* Re: [Cose] Issue: Encoding for a single recipient or structure
>
>
>

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 30 Jun 2015 21:31:30 -0700

Part of the question is going to be where do you expect COSE to be used in the future.

If one believes that it is only for use in constrained environments, then it is unlikely that there is a need for multiple recipients.  Based on the use cases that have been provided at the current time, it is also likely that there is no need to have anything more than a shared secret method of key management. 

If one believes that it will be used in environments other than just constrained environments – say in SACM or MILE then there are probably several use cases for multiple recipients and multiple key management methods.  An example would be a central authority providing an encrypted token to a client that is good for multiple servers, each server having its own private key for decryption. 

Another thing might be a version of multi-cast of messages.  Currently this is designed to use a previously sent pre-shared secret.  But it is possible that this might become a multiple recipient type system instead.

One also always has the case of an entity wanting to archive the messages it is sending – and adding itself as a recipient.

I think it is quite likely that there will be application profiles of COSE, just as there are application protocols of CMS.  This is where one can say that a feature does not need to be implemented.  But it still makes the code much simpler for all involved if there is only one way that is used to do something.  This was not the approach used for portions of JOSE such as encoding a single recipient message.  I can think of at least three different ways to encode this type of message.

From: Dick Hardt [mailto:[email-masked]] 
Sent: Tuesday, June 30, 2015 6:17 PM
To: Mike Jones
Cc: Jim Schaad; [email-masked]
Subject: Re: [Cose] Issue: Encoding for a single recipient or structure

I expect that if I want to deploy COSE, I would be adding support to the JOSE libraries I already have that I would deploy on the server, so a consistent data model would be very beneficial and increase the odds that it is correct and hence secure.

If there is agreement that multiple recipients is optional, then I would strongly prefer option (a).

I'm sure this was covered in JOSE, but I don't know of any scenarios where I would need multiple recipients -- particularly in a constrained environment. Is there a multiple recipient use case documented somewhere?

On Tue, Jun 30, 2015 at 6:11 PM, Mike Jones <[email-masked] <mailto:[email-masked]> > wrote:

                                                                -- Mike

From: Dick Hardt [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, June 30, 2015 6:01 PM
To: Mike Jones
Cc: Jim Schaad; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Cose] Issue: Encoding for a single recipient or structure

On Tue, Jun 30, 2015 at 5:45 PM, Mike Jones <[email-masked] <mailto:[email-masked]> > wrote:

Reply inline below...

> From: Jim Schaad [mailto:[email-masked] <mailto:[email-masked]> ]
> To: Mike Jones; [email-masked] <mailto:[email-masked]> 
> > From: Mike Jones [mailto:[email-masked] <mailto:[email-masked]> ]
> > To: Jim Schaad; [email-masked] <mailto:[email-masked]> 

                                Cheers,
                                -- Mike

> > From: Cose [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Jim Schaad
> > To: [email-masked] <mailto:[email-masked]> 
> > [email-masked] <mailto:[email-masked]> 

_______________________________________________
Cose mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/cose