Draft: draft-schaad-cose

Commentary: Check point in a number of changes : Change top level objects from arrays to maps Start working on IANA considerations Put in text dealing with protected and unprotected headers as a separate section .
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.
Both buckets are implemented as CBOR maps.  The maps can be keyed by
signed integers, unsigned integers and strings.  The signed and
unsigned integers are used for compactness of encoding.  The value
portion is dependent on the key definition.  Both maps use the same
set of key/value pairs.  The integer key range has been divided into
several sections with a standard range, a private range, and a range
that is dependent on the algorithm selected.  The tables of keys
defined can be found in Header-Table.
contains attributes about the layer which are to be
cryptographically protected.  This bucket MUST NOT be used if it
is not going to be included in a cryptographic computation.
contains attributes about the layer which are not
cryptographically protected.
TODO: Do we need to repeat definitions for all or just for some and
refer to the JOSE documents?
The keys in the COSE_Sign map are keyed by the values in TOP-Level-
Keys.  While other keys can be present in the map, it is not
generally a recommended practice.  The other keys can be either of
integer or string type, use of other types is strongly discouraged.
See the note in CBOR-Canonical about options for allowing or
disallowing other keys.
contains attributes about the payload which are to be protected by
the signature.  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 signature, even if those attributes
are common across multiple signatures.
contains attributes about the payload which are not protected by
the signature.  An example of such an attribute would be the
content type ('cty') attribute.  This field MUST NOT contain
attributes about a signature, even if the attributes are common
across multiple signatures.
contains attributes about the payload which are to be protected by
the signature.  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 signature, even if those attributes
are common across multiple signatures.  This fields inthis map are
typically keyed by Header-Table.  Other keys can be used either as
int or tstr values.  Other types MUST NOT be present in the map as
key values.
contains attributes about the payload which are not protected by
the signature.  An example of such an attribute would be the
content type ('cty') attribute.  This field MUST NOT contain
attributes about a signature, even if the attributes are common
across multiple signatures.  This fields inthis map are typically
keyed by Header-Table.  Other keys can be used either as int or
tstr values.  Other types MUST NOT be present in the map as key
values.
The keys in the COSE_signature map are keyed by the values in TOP-
Level-Keys.  While other keys can be present in the map, it is not
generally a recommended practice.  The other keys can be either of
integer or string type, use of other types is strongly discouraged.
See the note in CBOR-Canonical about options for allowing or
disallowing other keys.
Create a Sig_structure object and populate it with the appropriate
fields.
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
should be used.
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.
It is requested that IANA create a new registry entitled "COSE Header
Key".
The name is present to make it easier to refer to and discuss the
registration entry.  The value is not used in the protocol.  Names
are to be unique in the table.
This is the value used for the key.  The key can be either an
integer or a string.  Registration in the table is based on the
value of the key requested.  Integer values between 0 and 255 and
strings of length 1 are designated as Standards Track Document
required.  Integer values from 256 to 65535 and strings of length
2 are designated as Specification Required.  Integer values of
greater than 65535 and strings of length greater than 2 are
designated as first come first server.  Integer values in the
range -1 to -65536 are delegated to the "COSE Header Algorithm
Key" registry.  Integer values beyond -65536 are marked as private
use.
The initial contents of the registry can be found in Header-Table.
The specification column for all rows in that table should be this
document.
NOTE: Need to review the range assignments.  It does not necessarily
make sense as specification required uses 1 byte positive integers
and 2 byte strings.
It is requested that IANA create a new registry entitled "COSE Header
Algorithm Keys".
The name is present to make it easier to refer to and discuss the
registration entry.  The value is not used in the protocol.
The algorithm(s) that this registry entry is used for.  This value
is taken from the "COSE Algorithm Value" registry.  Multiple
algorithms can be specified in this entry.  For the table, the
algorithm, key pair MUST be unique.
This is the value used for the key.  The key is an integer in the
range of -1 to -65536.
The initial contents of the registry can be found in Header-
Algorithm-Table.  The specification column for all rows in that table
should be this document.
It is requested that IANA create a new registry entitled "COSE
Algorithm Registry".
The value to be used to identify this algorithm.  Algorithm keys
MUST be unique.  The key can be a positive integer, a negative
integer or a string.  Integer values between 0 and 255 and strings
of length 1 are designated as Standards Track Document required.
Integer values from 256 to 65535 and strings of length 2 are
designated as Specification Required.  Integer values of greater
than 65535 and strings of length greater than 2 are designated as
first come first server.  Integer values in the range -1 to -65536
are delegated to the "COSE Header Algorithm Key" registry.
Integer values beyond -65536 are marked as private use.
A short description of the algorithm.
A document where the algorithm is defined (if publicly available).
The initial contents of the registry can be found in ALG_TABLE.  The
specification column for all rows in that table should be this
document.