Draft: draft-schaad-cose

Commentary: More changes to deal with the move from arrays . Update examples Change the grammar to correctly deal with integer keys . Pickup some review updates . Start dealing with IANA tables for the COSE_Key structure .
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
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC2119.
Implementations SHOULD be prepared to find an integer in the location
which does not correspond to the values 0 to 2.  If this is found
then the client MUST stop attempting to parse the structure and fail.
Clients need to recognize that the set of values could be extended at
a later date, but should not provide a security service based on
guesses of what is there.
Implementations SHOULD be prepared to find an integer in the location
which does not correspond to the values 1 to 3.  If this is found
then the client MUST stop attempting to parse the structure and fail.
Clients need to recognize that the set of values could be extended at
a later date, but should not provide a security service based on
guesses of what is there.
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.
Both buckets are implemented as CBOR maps.  The maps can be keyed by
negative integers, unsigned integers and strings.  The negative 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.
TODO: Should we move table Header-Table to here or leave it as an
appendix.  Some what redundant if we document things in text.
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.
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 in this 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 int his 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.
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.
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.
contains the information about the plain text or encryption
process that is to be integrity protected.  The field is encoded
in CBOR as a 'bstr' if present and the value 'nil' if there is no
data.  The contents of the protected field is a CBOR map of the
protected data names and values.  The map is CBOR encoded before
placing it into the bstr.  Only values associated with the current
cipher text are to be placed in this location even if the value
would apply to multiple recipient structures.
contains information about the plain text that is not integrity
protected.  If there are no field, then the value 'nil' is used.
Only values associated with the current cipher text are to be
placed in this location even if the value would apply to multiple
recipient structures.
contains the initialization vector (IV), or it's equivalent, if
one is needed by the encryption algorithm.  If there is no IV,
then the value 'nil' is used.
contains additional authenticated data (aad) supplied by the
application.  This field contains information about the plain text
data that is authenticated, but not encrypted.  If the application
does not provide this data, the value 'nil' is used.
contains the encrypted plain text.  If the cipherText is to be
transported independently of the control information about the
encryption process (i.e. detached content) then the value 'nil' is
encoded here.
A 'nil' value if there are no recipients.
contains the information about the plain text or encryption
process that is to be integrity protected.  The field is encoded
in CBOR as a 'bstr'.  The contents of the protected field is a
CBOR map of the protected data names and values.  The map is CBOR
encoded before placing it into the bstr.  Only values associated
with the current cipher text are to be placed in this location
even if the value would apply to multiple recipient structures.
contains information about the plain text that is not integrity
protected.  Only values associated with the current cipher text
are to be placed in this location even if the value would apply to
multiple recipient structures.
contains the initialization vector (IV), or it's equivalent, if
one is needed by the encryption algorithm.
contains additional authenticated data (aad) supplied by the
application.  This field contains information about the plain text
data that is authenticated, but not encrypted.
contains the encrypted plain text.  If the cipherText is to be
transported independently of the control information about the
encryption process (i.e. detached content) then the field is
omitted.
The 'protected', 'iv', 'aad', 'ciphertext' and 'recipients' fields
MUST be nil.
The 'protected', 'iv', 'aad', 'ciphertext' and 'recipients' fields
MUST be absent.
The 'protected', 'aad', and 'recipients' fields MUST be nil.
The 'protected', 'aad', and 'recipients' fields MUST be absent.
Verify that the 'protected' field is empty.
Verify that the 'aad' field is empty.
Verify that the 'protected' field is absent.
Verify that the 'aad' field is absent.
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 entitied "COSE Key
Map 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 used for key parameters specific to a single algoirthm
delegated to the "COSE Key Parameter Key" registry.  Integer
values beyond -65536 are marked as private use.
This field denotes the registry that values come from, if one
exists.
This registry will be initially populated bythe values in
COSE_KEY_KEYS.  The specification column for all of these entries
will be this document.
It is requested that IANA create a new registry "COSE Key
Parameters".
This field contains a descriptive string of a key type.  This
should be a value that is in the COSE General Values table and is
placed in the 'kty' field of a COSE Key structure.
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.