Draft: draft-schaad-cose

Commentary: This is the first round of editorial comments I 'm making : typos .
Remove the authentiction tag for encryption algorithms as a
separate item.
Remove the flattened mode of encoding.  Forcing the use of an
array of recipients at all times forces the message size to be two
bytes larger, but one gets a corresponding decrease in the
implementation size that should compenstate for this.
Remove the authentication tag for encryption algorithms as a
separate item.
Remove the flattened mode of encoding.  Forcing the use of an
array of recipients at all times forces the message size to be two
bytes larger, but one gets a corresponding decrease in the
implementation size that should compensated for this.
The top level of each of the COSE message structures are encoded as
arrays.
We use an integer to distingish bettwen the different security
message types.  By looking at the integer in the first element, one
can determine which security message is being used and thus what the
syntax is for the rest of the elements in the array.
The top level of each of the COSE message structures are encoded as
arrays.
We use an integer to distinguish between the different security
message types.  By looking at the integer in the first element, one
can determine which security message is being used and thus what the
syntax is for the rest of the elements in the array.
The structure of COSE has been designed to have two buckets of
information that are not considered to be part of the message
structure itself, but are used for holding information about
algorithms, keys, or evaluation hints for the processing of the
layer.  These two buckets are available for use in all of the
structures in this document except for keys.  While these buckets can
be present, they may not all be usable in all instances.  For
example, while the protected bucket is present for recipient
structures, most of the algorithms that are-used for recipients do
not provide the necessary functionality to provide the needed
protection and thus the element is not used.
The structure of COSE has been designed to have two buckets of
information that are not considered to be part of the message
structure itself, but are used for holding information about
algorithms, keys, or evaluation hints for the processing of the
layer.  These two buckets are available for use in all of the
structures in this document except for keys.  While these buckets can
be present, they may not all be usable in all instances.  For
example, while the protected bucket is present for recipient
structures, most of the algorithms that are used for recipients do
not provide the necessary functionality to provide the needed
protection and thus the element is not used.
Create a Sig_structure object and populate it with the appropriate
fields.  For body_protected and sign_protected, if the fields are
not present in their corresponding maps, an bstr of length zero is
be used.
Comput the hash value from the byte string.
Create a Sig_structure object and populate it with the appropriate
fields.  For body_protected and sign_protected, if the fields are
not present in their corresponding maps, a bstr of length zero is
be used.
Compute the hash value from the byte string.
One of the byproducts of using the same technique for encrypting and
encoding both the content and the keys using the various key
management techniques, is a requirement that all of the key
management techniques use an Authenticated Encryption (AE) algorithm.
(For the purpose of this document we use a slightly loose definition
of AE algorithms.)  When encrypting the plain text, it is normal to
use an Authenticated Encryption with Additional Data (AEAD)
algorithm.  For key management, either AE or AEAD algorithms can be
used.  See AE-algo for more details about the different types of
algorithms.
The "key_ops" element is prefered over the "use" element as the
information provided that way is more finely detailed about the
operations allowed.  It is strongly suggested that this element be
present for all keys.
The "key_ops" element is preferred over the "use" element as the
information provided that way is more finely detailed about the
operations allowed.  It is strongly suggested that this element be
present for all keys.
While it is permitted to have key values other than those specified
in this document in the outer maps (COSE_Sign, COSE_Signature,
COSE_encrypt, COSE_recipient and COSE_mac), doing so is not
encouraged.  Applications should make a determination if it will be
permitted for that application.  In general, any needed new fields
can be accomadated by the introduction of new header fields to be
carried in the protected or unprotected fields.  Applications that
need to have new fields in these maps should consider getting new
message types assigned for these usages.  Without this change, old
applications will not see and process the new fields.
While it is permitted to have key values other than those specified
in this document in the outer maps (COSE_Sign, COSE_Signature,
COSE_encrypt, COSE_recipient and COSE_mac), doing so is not
encouraged.  Applications should make a determination if it will be
permitted for that application.  In general, any needed new fields
can be accommodated by the introduction of new header fields to be
carried in the protected or unprotected fields.  Applications that
need to have new fields in these maps should consider getting new
message types assigned for these usages.  Without this change, old
applications will not see and process the new fields.
It is requested that IANA assign a new tag from the "Concise Binary
Object Represetion (CBOR) Tags" registry.  It is requested that the
tag be assigned in the 0 to 23 value range.
It is requested that IANA assign a new tag from the "Concise Binary
Object Representation (CBOR) Tags" registry.  It is requested that
the tag be assigned in the 0 to 23 value range.
It is requested that IANA create a new registry entitied "COSE Key
Map Registry".
It is requested that IANA create a new registry entitled "COSE Key
Map Registry".
The key is to be unqiue for every value of key type.  The range of
values is from -256 to -1.  Keys are expected to be re-used for
different keys.
This registry will be initially populated bythe values in
COSE_KEY_PARAM_KEYS.  The specification column for all of these
entries will be this document.
The key is to be unique for every value of key type.  The range of
values is from -256 to -1.  Keys are expected to be re-used for
different keys.
This registry will be initially populated by the values in
COSE_KEY_PARAM_KEYS.  The specification column for all of these
entries will be this document.
Use of direcct ECDH direct encryption is easy for people to leak
information on if there are other recipients in the message.
Use of direct ECDH direct encryption is easy for people to leak
information on if there are other recipients in the message.