Draft: draft-schaad-cose

Commentary: Add new tables to the end of the document about parameters which talk about types and possible column for integer indexes in the future
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.
The signature structure allows for one or more signatures to be
applied to a message payload.  There are provisions for attributes
about the content and attributes 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.
with one algorithm or the other.  (Source of text is RFC5652.)
More detailed information on multiple signature evaluation can be
found in RFC5752.
with one algorithm or the other.  (Source of text is RFC5652.)  More
detailed information on multiple signature evaluation can be found in
RFC5752.
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 either a single signature or an array of signature values.
A single signature value can be represented using either data
type.  Implementations MUST be able to parse both data types.
Create the value to be hashed by encode the Sig_structure to a
byte string.
Create the value to be hashed by encoding the Sig_structure to a
byte string.
One of the by products 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.
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 structure has two maps where data about the content can be
placed.  The data placed here is also the data which is used to
control how the decryption is to be done for this object.  When data
is placed in these two structures, it is extremely poor practice to
have data which is applicable to a different level.  For example, the
unprotected field at the level of a key management decryption should
not contain information either about how to interpret the plain text
(i.e. content type) or how to convert the cipher text back to plain
text (i.e. the kid for the recipient).
One of the by products 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.
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 'null' 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.
contains information about the plain text that is not integrity
protected.  If there are no field, then the value 'null' is 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 'null' 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 'null' 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 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.
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.
Any item which is string (but not base64) encoded in JWK, is tstr
encoded for COSE.
Considerations about protected vs unprotected header fields.