Subject: [COSE] Single Recipient Discussions

From: "Jim Schaad" <[email-masked]>
Date: Wed, 12 Aug 2015 14:12:03 -0700

Since we appear to have finished dealing with the question of array vs map
at the top level, I want to restart the discussions dealing with handing
single recipient/signer as a special case.

1.  I am assuming that we are going with arrays at the top level for all of
the sizes that I cite in this mail.  As such, these number will be slightly
different that those cited by the advocates of a single recipient solution,
but I do not believe that the slightly different numbers would change their
arguments in any way.

2.  I believe that it is a misnomer to call the discussion that has been
primarily advanced to be about a single recipient use case.  It would be
more accurate the tag this discussion as being about making the case of
using a PSK directly as the key.  The proposals do nothing to deal with any
of the other key management techniques as a single recipient, they only deal
with a key management algorithm of 'direct'.

3.  The message space savings for the proposals that have been advanced will
save at most 8 bytes from the current document.  2 bytes for the two array
markers, 2 bytes for the two maps, 1 byte for the absent ciphertext, 1 byte
for the zero length recipient array, 2 bytes for the algorithm identifier
tag and value.   Of these 8 bytes, we can remove 3 of them relatively
easily.  If the recipient array is optional, then it disappears.  If we
unroll the recipients in the case of a single recipient then the 2 bytes for
array markers disappears.  The published document does the first but not the
latter.

4.  There is currently a very clear cut rule about things only being used at
the layer they are placed in.  This means that currently key identifiers are
never placed in the same layer as a content key algorithm.  This would be
broken by the proposal put forth.  I worry that once this is done, there
will be more items than kid that will migrate between layers.  One of the
things that I never liked in the JOSE proposals what the number of places
that one needed to look for the various control fields.  Currently in COSE
this is limited to two places.  If we introduce the possibility of cross
layer contamination then this number might grow in the future to deal with
implementation faults.   

One of the way that these faults might develop is for designers to say - I
think that this should be authenticated, and thus will put it at the wrong
layer to ensure that it is.  Either without thinking about the question -
should it be authenticated, or a different algorithm be required so that
authentication is possible.

5.  Code size is going to be very different if two different methods of
dealing with structure needs to be supported.  It is currently being assumed
that direct key is going to be the major use case in a number of situations.
If this is not the case then current proposals do not help the situation
any.  If it is true that more than one method of key management needs to be
supported then the code size is going to grow because of the need to support
an additional way that key management is going to be done.

6.  Personally, I am planning to argue against using direct key in future
work of ACE for long term authentication keys.  The fact that it is going to
be hard to rotate them means that one needs to either add a KDF step or else
have a key agreement method to keep the same key from being used for the
entire lifetime of the device (perhaps 30 years?).  This is something that
is related to the previous item as we now are going to need to support
multiple key management methods in these cases.

7.  Now that we are doing arrays, it would be possible to have a generic one
recipient/signer solution by unrolling the recipient/signer structure on the
end of the message.  This was originally proposed before the change from
arrays to maps was initially made.  Since we are moving from maps back to
arrays it is one again a viable solution to look at.  It would be totally
viable to have applications state that there is one recipient/signer and the
unrolled version is always used.  This would still allow for multiple key
management types to be used.  Systems in more unconstrained spaces could
potentially setup to have multiple recipients - but only if use cases exist
where it would be needed.

---

From: Mike Jones <[email-masked]>
Date: Wed, 12 Aug 2015 21:24:34 +0000

I think I know what your proposal in 7 would look like, but it could probably help the discussion if you were to give us a concrete example - not using numbers and an actual representation, but using symbolic names for the array fields.  I'm thinking something like:

[protected,
 unprotected,
 payload,
 signature]

I realize you may be envisioning more fields than that to maintain the layering you discuss below, which is part of why I'd like us to be able to easily see what they are.

				Thanks,
				-- Mike

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, August 12, 2015 5:12 PM
To: [email-masked]
Subject: [COSE] Single Recipient Discussions

Since we appear to have finished dealing with the question of array vs map at the top level, I want to restart the discussions dealing with handing single recipient/signer as a special case.

1.  I am assuming that we are going with arrays at the top level for all of the sizes that I cite in this mail.  As such, these number will be slightly different that those cited by the advocates of a single recipient solution, but I do not believe that the slightly different numbers would change their arguments in any way.

2.  I believe that it is a misnomer to call the discussion that has been primarily advanced to be about a single recipient use case.  It would be more accurate the tag this discussion as being about making the case of using a PSK directly as the key.  The proposals do nothing to deal with any of the other key management techniques as a single recipient, they only deal with a key management algorithm of 'direct'.

3.  The message space savings for the proposals that have been advanced will save at most 8 bytes from the current document.  2 bytes for the two array markers, 2 bytes for the two maps, 1 byte for the absent ciphertext, 1 byte for the zero length recipient array, 2 bytes for the algorithm identifier
tag and value.   Of these 8 bytes, we can remove 3 of them relatively
easily.  If the recipient array is optional, then it disappears.  If we unroll the recipients in the case of a single recipient then the 2 bytes for array markers disappears.  The published document does the first but not the latter.

4.  There is currently a very clear cut rule about things only being used at the layer they are placed in.  This means that currently key identifiers are never placed in the same layer as a content key algorithm.  This would be broken by the proposal put forth.  I worry that once this is done, there will be more items than kid that will migrate between layers.  One of the things that I never liked in the JOSE proposals what the number of places that one needed to look for the various control fields.  Currently in COSE this is limited to two places.  If we introduce the possibility of cross layer contamination then this number might grow in the future to deal with
implementation faults.   

One of the way that these faults might develop is for designers to say - I think that this should be authenticated, and thus will put it at the wrong layer to ensure that it is.  Either without thinking about the question - should it be authenticated, or a different algorithm be required so that authentication is possible.

5.  Code size is going to be very different if two different methods of dealing with structure needs to be supported.  It is currently being assumed that direct key is going to be the major use case in a number of situations.
If this is not the case then current proposals do not help the situation any.  If it is true that more than one method of key management needs to be supported then the code size is going to grow because of the need to support an additional way that key management is going to be done.

6.  Personally, I am planning to argue against using direct key in future work of ACE for long term authentication keys.  The fact that it is going to be hard to rotate them means that one needs to either add a KDF step or else have a key agreement method to keep the same key from being used for the entire lifetime of the device (perhaps 30 years?).  This is something that is related to the previous item as we now are going to need to support multiple key management methods in these cases.

7.  Now that we are doing arrays, it would be possible to have a generic one recipient/signer solution by unrolling the recipient/signer structure on the end of the message.  This was originally proposed before the change from arrays to maps was initially made.  Since we are moving from maps back to arrays it is one again a viable solution to look at.  It would be totally viable to have applications state that there is one recipient/signer and the unrolled version is always used.  This would still allow for multiple key management types to be used.  Systems in more unconstrained spaces could potentially setup to have multiple recipients - but only if use cases exist where it would be needed.

_______________________________________________
COSE mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40microsoft.com%7c42b45138af2043af976708d2a35aa0e5%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=62f4AJob4HGGxfnZpU2Yt7AGjiTJcxW75rCq2jYKlUo%3d

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 12 Aug 2015 19:49:24 -0700

No it would look like

[ msg_type, protected, unprotected, payload, protected, unprotected,
signature]

One would append the signature structure to the end of the body structure.
Similar for encryption and mac.

> From: Mike Jones [mailto:[email-masked]]
> Sent: Wednesday, August 12, 2015 2:25 PM
> To: Jim Schaad; [email-masked]
> Subject: RE: [COSE] Single Recipient Discussions
> 
> I think I know what your proposal in 7 would look like, but it could
probably help
> the discussion if you were to give us a concrete example - not using
numbers
> and an actual representation, but using symbolic names for the array
fields.  I'm
> thinking something like:
> 
> [protected,
>  unprotected,
>  payload,
>  signature]
> 
> I realize you may be envisioning more fields than that to maintain the
layering
> you discuss below, which is part of why I'd like us to be able to easily
see what
> they are.
at
> the top level, I want to restart the discussions dealing with handing
single
> recipient/signer as a special case.
> 
> 1.  I am assuming that we are going with arrays at the top level for all
of the
> sizes that I cite in this mail.  As such, these number will be slightly
different that
> those cited by the advocates of a single recipient solution, but I do not
believe
> that the slightly different numbers would change their arguments in any
way.
> 2.  I believe that it is a misnomer to call the discussion that has been
primarily
> advanced to be about a single recipient use case.  It would be more
accurate the
> tag this discussion as being about making the case of using a PSK directly
as the
> key.  The proposals do nothing to deal with any of the other key
management
> techniques as a single recipient, they only deal with a key management
> algorithm of 'direct'.
> 
> markers, 2 bytes for the two maps, 1 byte for the absent ciphertext, 1
byte for
> the zero length recipient array, 2 bytes for the algorithm identifier
unroll the
> recipients in the case of a single recipient then the 2 bytes for array
markers
> disappears.  The published document does the first but not the latter.
> 
> 4.  There is currently a very clear cut rule about things only being used
at the
> layer they are placed in.  This means that currently key identifiers are
never
> placed in the same layer as a content key algorithm.  This would be broken
by
> the proposal put forth.  I worry that once this is done, there will be
more items
> than kid that will migrate between layers.  One of the things that I never
liked in
> the JOSE proposals what the number of places that one needed to look for
the
> various control fields.  Currently in COSE this is limited to two places.
If we
> introduce the possibility of cross layer contamination then this number
might
> grow in the future to deal with
> implementation faults.
> 
think
> that this should be authenticated, and thus will put it at the wrong layer
to
> ensure that it is.  Either without thinking about the question - should it
be
> authenticated, or a different algorithm be required so that authentication
is
> possible.
dealing
> with structure needs to be supported.  It is currently being assumed that
direct
> key is going to be the major use case in a number of situations.
any.  If it is
> true that more than one method of key management needs to be supported
> then the code size is going to grow because of the need to support an
additional
> way that key management is going to be done.
> 
work of
> ACE for long term authentication keys.  The fact that it is going to be
hard to
> rotate them means that one needs to either add a KDF step or else have a
key
> agreement method to keep the same key from being used for the entire
lifetime
> of the device (perhaps 30 years?).  This is something that is related to
the
> previous item as we now are going to need to support multiple key
management
> methods in these cases.
> recipient/signer solution by unrolling the recipient/signer structure on
the end of
> the message.  This was originally proposed before the change from arrays
to
> maps was initially made.  Since we are moving from maps back to arrays it
is one
> again a viable solution to look at.  It would be totally viable to have
applications
> state that there is one recipient/signer and the unrolled version is
always used.
> This would still allow for multiple key management types to be used.
Systems in
> more unconstrained spaces could potentially setup to have multiple
recipients -
> but only if use cases exist where it would be needed.
> 
> 
> 
> 
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.
> org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40micro
> soft.com%7c42b45138af2043af976708d2a35aa0e5%7c72f988bf86f141af91ab2
> d7cd011db47%7c1&sdata=62f4AJob4HGGxfnZpU2Yt7AGjiTJcxW75rCq2jYKlUo%
> 3d

---

From: Mike Jones <[email-masked]>
Date: Tue, 18 Aug 2015 04:26:22 +0000

Would people prefer the structure that Jim described below:

    [ msg_type, protected, unprotected, payload, protected, unprotected, signature]

or the flattened structure:

    [ msg_type, protected, unprotected, payload, signature]

The latter seems to me like it does a better job of "keeping simple things simple".

Jim, would MAC look exactly like signature, or if not, what would the differences be?  Likewise, would encrypted content look like this in your proposal?

    [ msg_type, protected, unprotected, ciphertext, protected, unprotected, encrypted_key]

Likewise, in the encrypted structure, if we can coalesce the two sets of protected and unprotected headers, that would seem simpler.

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Wednesday, August 12, 2015 7:49 PM
To: Mike Jones; [email-masked]
Subject: RE: [COSE] Single Recipient Discussions

No it would look like

[ msg_type, protected, unprotected, payload, protected, unprotected, signature]

probably help
numbers
fields.  I'm
layering
see what
at
single
of the
different that
believe
way.
primarily
accurate the
as the
management
> 3.  The message space savings for the proposals that have been 
> advanced
will
> save at most 8 bytes from the current document.  2 bytes for the two 
> array markers, 2 bytes for the two maps, 1 byte for the absent 
> ciphertext, 1
byte for
unroll the
markers
at the
never
by
more items
liked in
the
If we
might
think
to
be
is
dealing
direct
any.  If it is
additional
work of
hard to
key
lifetime
the
management
> methods in these cases.
> 
> 7.  Now that we are doing arrays, it would be possible to have a 
> generic
one
the end of
to
is one
applications
always used.
Systems in
recipients -

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 17 Aug 2015 22:14:24 -0700

> Sent: Monday, August 17, 2015 9:26 PM

So which part of "keeping simple things simpler" does it make simpler?  

Do you want to address issue 4 below?
Do you want to address issue 5 below?
How many bytes are you saving by doing this? 
How much code space to you add if you need to do multiple signatures?
Do you believe that there is never going to be the need to go from one to
two signatures later?

> 
> Jim, would MAC look exactly like signature, or if not, what would the
differences

No, you need to expand the correct set of structures

[msg_type, protected, unprotected, plaintext, tag, protected, unprotected,
encrypted_key]

> be?  Likewise, would encrypted content look like this in your proposal?
> 
>     [ msg_type, protected, unprotected, ciphertext, protected,
unprotected,
> encrypted_key]
> 
> Likewise, in the encrypted structure, if we can coalesce the two sets of
> protected and unprotected headers, that would seem simpler.

Again - same questions