Draft: draft-schaad-cose

Commentary: Make the encryption tag field go away . Change recipient structure so that it is empty , one or array . Change encryption and MAC to use CBOR structure to create the value to authenticate 
  has an interesting idea in his COSE document . He says to build an array of the items to be concatenated together and then CBOR encode them before running it into the hashing / MAC function . This would make things easier to explain as it them makes sense to just copy the elements that are going to be transported into the array and encode the array . This makes it easier than saying bstr encode this and tstr encode that and so forth . Comments ? 
 Re - open for group discussion 
 Put it out on the list and it does not appear to be contentious - so closing it . 
 JOSE now allows for a single recipient to be encoded at the same level as the content . While COSE does not allow for quite the same way of encoding this it would be possible to do something similar . Current syntax is " recipients : COSEencrypta\ null ; " Do so would allow for a single recipient to be appended to the end of the current array of values rather than creating two array sub - encodings in CBOR . This encoding saves 2 bytes in the event of a single recipient at the expense of needing to pass in an offset in the array structure when parsing it . Not really that hard to do from a programmers point of view . 
 Open for group discussion 
 Based on the messages , there seems to be no support for combining the two maps together into a single map . I have therefore removed that from my working copy of the draft . There was one request for allowing option b ( where a single recipient can be represented as a single map entry rather than as an array of a single map ) . I have looked at code size , and there does not seem to be a lot of code associated with this option , but as there was no outcry for this option I have not included it . Unless others have opinions that they believe need to be expressed , I am closing this issue . 
 The trend in things to is to move to a fixed sized authentication tag for a given algorithm and to encode that tag as part of the encryption stream . Since a number of the algorithms that we are using do n't have a separate authentication tag value , we should change from JOSE to use this model rather than having empty tag array members for a large number of the encryption structures . Expected savings in space is 1 byte for the content plus 1 byte for every recipient . 
 Reopen for group discussion
Concise Binary Object Representation (CBOR) is data format designed
for small code size and small message size.  There is a need for the
ability to have the basic security services defined for this data
format.  This document specifies how to do signatures, message
authentication codes and encryption using this data format.  The work
in this document is derived in part from the JSON web security
documents using the same parameters and algorithm identifiers as they
do.
The authors did not always agree with some of the decisions made
by the JOSE working group.  Many of these decisions have been re-
examined, and where it seems to the authors to be superior,
replaced.
The authors did not always agree with some of the decisions made
by the JOSE working group.  Many of these decisions have been re-
examined, and where it seems to the authors to be superior or
simpler, replaced.
Switch from using a map to using an array at the message level.
While this change means that it is no longer possible to add new
information in the form of new fields to the message object, this
ability is still there as this data can be added to the protected
and unprotected maps.
Switch from using a map to using an array at the message level.
While this change means that it is no longer possible to new named
parameters to the top level message, it also means that there is
not a need to define how older implementations are defined to
behave when new fields are present.  Most of the reasons that a
new field would need to be defined are adequately addressed by
defining a new parameter instead.
Remove the authentiction tag for encryption algorithms as a
separate item.
The signature structure allows for one or more signatures to be
applied to a message payload.  There are provisions for there to be
attributes about the content and about the signature to be carried
along with the signature itself.  These attributes may be
authenticated by the signature, or just present.  Examples of
attributes about the content would be the type of content, when the
content was created, and who created the content.  Examples of
attributes about the signature would be the algorithm and key used to
create the signature, when the signature was created, and counter-
signatures.
When more than one signature is present, the successful validation of
one signature associated with a given signer is usually treated as a
successful signature by that signer.  However, there are some
application environments where other rules are needed.  An
application that employs a rule other than one valid signature for
each signer must specify those rules.  Also, where simple matching of
the signer identifier is not sufficient to determine whether the
signatures were generated by the same signer, the application
specification must describe how to determine which signatures were
generated by the same signer.  Support of different communities of
recipients is the primary reason that signers choose to include more
than one signature.  For example, the COSE_Sign structure might
include signatures generated with the RSA signature algorithm and
with the Elliptic Curve Digital Signature Algorithm (ECDSA) signature
algorithm.  This allows recipients to verify the signature associated
with one algorithm or the other.  (Source of text is RFC5652.)
More detailed information on multiple signature evaluation can be
found in RFC5752.
contains the serialized content to be signed.  If the payload is
not present in the message, the application is required to supply
the payload separately.  The payload is wrapped in a bstr to
ensure that it is transported without changes, if the payload is
transported separately it is the responsibility of the application
to ensure that it will be transported without changes.
is either a single signature or an array of signature values.  It
is legal to use the array of signature values for a single
signature.  Implementations MUST be able to parse both layouts.
is optional and contains additional information to be
authenticated by the signature.  The field holds data about the
signature operation.  The field MUST NOT hold attributes about the
payload being signed.  The content is a CBOR map of attributes
which is encoded to a byte stream.  At least one of protected and
unprotected MUST be present.
contains the serialized content to be signed.
If the payload is not present in the message, the application is
required to supply the payload separately.
The payload is wrapped in a bstr to ensure that it is transported
without changes, if the payload is transported separately it is
the responsibility of the application to ensure that it will be
transported without changes.
is either a single signature or an array of signature values.
It is legal to use the array of signature values for a single
signature.
Implementations MUST be able to parse both layouts.
contains additional information to be authenticated by the
signature.  The field holds data about the signature operation.
The field MUST NOT hold attributes about the payload being signed.
The content is a CBOR map of attributes which is encoded to a byte
stream.  At least one of protected and unprotected MUST be
present.
contains the recipient information.  The field can have one of
three values.  * An array of COSE_Encrypt elements, one for each
recipient.  * A single COSE_Element, encoded as an extension to
the containing COSE_element, for a single recipient.  Single
recipients can be encoded either this way or as a single array
element.  * A 'null' value if there are no recipients.
At the moment we do not have any key management methods that allow
for the use of protected headers.  This may be changed in the future
if, for example, the AES-GCM Key wrap method defined in [JWA] were
extended to allow for authenticated data.  In that event the use of
the 'protected' field, which is current forbidden below, would be
permitted.
At the moment we do not have any key management methods that allow
for the use of protected headers.  This may be changed in the future
if, for example, the AES-GCM Key wrap method defined in I-D.ietf-
jose-json-web-algorithms were extended to allow for authenticated
data.  In that event the use of the 'protected' field, which is
current forbidden below, would be permitted.
Nice short encryption algorithm.
Construct the octet string to be placed in the protected field:
CBOR encode the protected data map, place it the protected field.
The encryption algorithm for AEAD algorithms is fairly simple.
In order to get a consistent encoding of the data to be
authenticated, the Enc_structure is used to have canonical form of
the AAD.
If there is protected data, CBOR encode the map to a byte string
and place in the protected field of the Enc_structure and the
COSE_Encrypt structure.
Copy the add field from the COSE_Encrypt structure to the
Enc_Structure.
Encode the Enc_structure using a CBOR Canonical encoding CBOR-
Canonical to get the AAD value.
contains attributes about the payload which are to be protected by
the MAC.  An example of such an attribute would be the content
type ('cty') attribute.  The content is a CBOR map of attributes
which is encoded to a byte stream.  This field MUST NOT contain
attributes about the recipient, even if those attributes are
common across multiple recipients.  At least one of protected and
unprotected MUST be present.
contains attributes about the payload which are not protected by
the MAC.  An example of such an attribute would be the content
type ('cty') attribute.  This field MUST NOT contain attributes
about a recipient, even if the attributes are common across
multiple recipients.  At least one of protected and unprotected
MUST be present.
contains the serialized content to be MAC-ed.
If the payload is not present in the message, the application is
required to supply the payload separately.
The payload is wrapped in a bstr to ensure that it is transported
without changes, if the payload is transported separately it is
the responsibility of the application to ensure that it will be
transported without changes.
contains the MAC value.
contains the recipient information.  See the description under
COSE_Encryption for more info.
Create a MAC_structure and copy the protected and payload elements
from the COSE_mac structure.
Encode the MAC_structure using a canonical CBOR encoder.  The
resulting bytes is the value to compute the MAC on.
Compute the MAC and place the result in the 'tag' field of the
COSE_mac structure.
Encrypt and encode the MAC key for each recipient of the message.
The element "kty" is a required element in a COSE_Key map.
All other elements are optional and not all of the elements listed in
[JWK] or [JWA] have been listed here even though they can all appear
in a COSE_Key map.
The element "kty" is a required element in a COSE_Key map.
All other elements are optional and not all of the elements listed in
I-D.ietf-jose-json-web-key or I-D.ietf-jose-json-web-algorithms have
been listed here even though they can all appear in a COSE_Key map.