Change:
Add new tables to the end of the document about parameters which talk about types and possible column for integer indexes in the future

Discussion:
3. The signature structure allows for one or more signatures to be <del> applied to a message payload.  There are provisions for there to be attributes about the content and about the signature to be carried </del> <ins> applied to a message payload.  There are provisions for attributes about the content and attributes about the signature to be carried </ins> 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

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 <del> with one algorithm or the other.  (Source of text is RFC5652.) More detailed information on multiple signature evaluation can be found in RFC5752. </del> <ins> with one algorithm or the other.  (Source of text is RFC5652.)  More detailed information on multiple signature evaluation can be found in RFC5752. </ins> <del> The CDDL grammar structure for a signature is: ~~~~ COSE_Sign : { protected : bstr | null; unprotected : map(tstr) | null; payload : bstr | null; signatures: COSE_signature_a* | COSE_signature; } ~~~~ </del> <ins> The CDDL grammar structure for a signature message is: </ins> The fields is the structure have the following semantics:

transported without changes. is either a single signature or an array of signature values. <del> It is legal to use the array of signature values for a single signature. Implementations MUST be able to parse both layouts. </del> <ins> A single signature value can be represented using either data type.  Implementations MUST be able to parse both data types. The CDDL grammar structure for a signature is: </ins> The fields is the structure have the following semantics:

contains the computed signature value. <ins> The COSE structure used to create the byte stream to be signed uses the following CDDL grammar structure: </ins> How to compute a signature: Create a Sig_structure object and populate it with the appropriate fields. <del> Create the value to be hashed by encode the Sig_structure to a </del> <ins> Create the value to be hashed by encoding the Sig_structure to a </ins> byte string. Sign the hash

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. <del> 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). </del> <ins> (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 CDDL grammar structure for encryption is: </ins> Description of the fields:

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 <del> placing it into the bstr. </del> <ins> 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. </ins> contains information about the plain text that is not integrity protected.  If there are no field, then the value 'null' is used. <ins> 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. </ins> contains the initialization vector (IV), or it's equivalent, if one is needed by the encryption algorithm.  If there is no IV,

is encoded here. contains the recipient information.  The field can have one of <del> 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. </del> <ins> three types: 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. </ins> 4.1.

Any item which is integer encoded in JWK, is int encoded for COSE. <del> Any item which is string (but not base64) encoded in JWK, is tstr encoded for COSE. </del>

9. <del> There are security considertions: </del> <ins> There are security considerations: </ins> Protect private keys

Use of direcct ECDH direct encryption is easy for people to leak information on if there are other recipients in the message. <ins> Considerations about protected vs unprotected header fields. </ins> Editorial Comments [CREF3] JLS: Do we defined a cku as well?