Original text:
signature can be computed.  Details on computing counter signatures are found in counter_signature. <del> This parameter provides the time the content cryptographic operation is performed.  For signatures and recipient structures, this would be the time that the signature or recipient key object was created.  For content structures, this would be the time that the content structure was created.  The unsigned integer value is the number of seconds, excluding leap seconds, after midnight UTC, January 1, 1970.  The field is primarily intended to be to be used for counter signatures, however it can additionally be used for replay detection as well. </del> The CDDL fragment that represents the set of headers defined in this section is given below.  Each of the headers is tagged as optional because they do not need to be in every map, headers required in authenticated by the signature, or just present.  An example of a parameter about the content is the content type.  Examples of parameters about the signature would be the algorithm and key used to <del> create the signature, when the signature was created, and counter signatures. </del>  When more than one signature is present, the successful validation of one signature associated with a given signer is usually treated as a COSE supports two different encryption structures.  COSE_Encrypted is used when a recipient structure is not needed because the key to be <del> used is known implicitly.  COSE_Enveloped is used the rest of time time.  This includes cases where there are multiple recipients, a recipient algorithm other than direct is to be used, or the key to be used is not known. </del>  5.1. mitigated by including the signature algorithm identifier in the data to be signed.  9. Message Authentication Codes (MACs) provide data authentication and 12.4.1. The mathematics for Elliptic Curve Diffie-Hellman can be found in <del> RFC6090. </del>  ECDH is parameterized by the following: When using a COSE key for this algorithm, the following checks are made: <del> The 'kty' field MUST be present and it MUST be 'EC2'. </del>  If the 'alg' field present, it MUST match the Key Agreement algorithm being used. 13.2.  Occasionally it is required that a symmetric key be transported between entities.  This key structure allows for that to happen. 17.  There are a number of security considerations that need to be taken into account by implementers of this specification.  The security considerations that are specific to an individual algorithm are to prevent or discourage such analysis.  (For example the strings could be defined as 'YES' and 'NO '.) <del> 18. </del>  This document is a product of the COSE working group of the IETF. [CREF1] JLS: I have not gone through the document to determine what needs to be here yet.  We mostly want to grab terms that are used in unusual ways or are not generally understood. 

Reviewer comments:
Deemed not used in enough locations - counter signatures suffer because of this but the group did not care.

Revised text:
signature can be computed.  Details on computing counter signatures are found in counter_signature.  The CDDL fragment that represents the set of headers defined in this section is given below.  Each of the headers is tagged as optional because they do not need to be in every map, headers required in authenticated by the signature, or just present.  An example of a parameter about the content is the content type.  Examples of parameters about the signature would be the algorithm and key used to  <ins> create the signature and counter signatures. </ins> When more than one signature is present, the successful validation of one signature associated with a given signer is usually treated as a COSE supports two different encryption structures.  COSE_Encrypted is used when a recipient structure is not needed because the key to be  <ins> used is known implicitly.  COSE_Enveloped is used the rest of time. This includes cases where there are multiple recipients, a recipient algorithm other than direct is to be used, or the key to be used is not known. </ins> 5.1. mitigated by including the signature algorithm identifier in the data to be signed. <ins> 8.2. I-D.irtf-cfrg-eddsa describes the elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA).  In that document, the signature algorithm is instantiated using parameters for edwards25519 and edwards448 curves.  The document additionally describes two variants of the EdDSA algorithm: Pure EdDSA, where no hash function is applied to the content before signing and, HashEdDSA where a hash function is applied to the content before signing and the result of that hash function is signed.  For use with COSE, on the pure EdDSA version is used.  This is because it is not expected that extremely large contents are going to be needed and, based on the arrangement of the message structure, the entire message is going to need to be held in memory in order to create or verify a signature.  Thus, the use of an incremental update process would not be useful.  Applications can provide the same features by defining the content of the message as a hash value and transporting the COSE message and the content as separate items. The algorithms defined in this document can be found in table-eddsa- algs.  A single signature algorithm is defined which can be used for multiple curves. I-D.irtf-cfrg-eddsa describes the method of encoding the signature value. When using a COSE key for this algorithm the following checks are made: The 'kty' field MUST be present and it MUST be 'OKP'. The 'crv' field MUST be present, and it MUST be a curve defined for this signature algorithm. If the 'alg' field is present, it MUST match 'EdDSA'. If the 'key_ops' field is present, it MUST include 'sign' when creating an EdDSA signature. If the 'key_ops' field is present, it MUST include 'verify' when verifying an EdDSA signature. </ins> 9. Message Authentication Codes (MACs) provide data authentication and 12.4.1. The mathematics for Elliptic Curve Diffie-Hellman can be found in  <ins> RFC6090.  In this document the algorithm is extended to be used with the two curves defined in I-D.irtf-cfrg-curves. </ins> ECDH is parameterized by the following: When using a COSE key for this algorithm, the following checks are made:  <ins> The 'kty' field MUST be present and it MUST be 'EC2' or 'OKP'. </ins> If the 'alg' field present, it MUST match the Key Agreement algorithm being used. 13.2. <ins> A new key type is defined for Octet Key Pairs (OKP).  Do not assume that keys using this type are elliptic curves.  This key type could be used for other curve types (for example mathematics based on hyper-elliptic surfaces). The key parameters defined in this section are summarized in table- ec1-keys.  The members that are defined for this key type are: contains an identifier of the curve to be used with the key. [CREF2] The curves defined in this document for this key type can be found in table-ec-curves.  Other curves may be registered in the future and private curves can be used as well. contains the x coordinate for the EC point.  The octet string represents a little-endian encoding of x. contains the private key. For public keys, it is REQUIRED that 'crv' and 'x' be present in the structure.  For private keys, it is REQUIRED that 'crv' and 'd' be present in the structure.  For private keys, it is RECOMMENDED that 'x' also be present, but it can be recomputed from the required elements and omitting it saves on space. 13.3. </ins> Occasionally it is required that a symmetric key be transported between entities.  This key structure allows for that to happen. 17. <ins> This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC6982.  The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF.  Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors.  This is not intended as, and must not be construed to be, a catalog of available implementations or their features.  Readers are advised to note that other implementations may exist. According to RFC6982, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". 17.1. Implemenation Location: https://github.com/cose-wg/COSE-JAVA Primary Maintainer: Jim Schaad Description: A JAVA library version of the COSE message specification.  The cryptography for the library is the Bouncy Castle JAVA implementation. Coverage: The library does not currently implement counter signatures.  The library includes some self testing both internally and againist the examples library Licensing: Revised BSD License 17.2. Implemenation Location: https://github.com/cose-wg/COSE-C Primary Maintainer: Jim Schaad Description: A C library version of the COSE message specification.  The cryptography for the library is currently OPENSSL version 1.0. Coverage: The library does not currently implement counter signatures.  The library includes some self testing both internally and againist the examples library. Licensing: Revised BSD License 17.3. Implemenation Location: https://github.com/cose-wg/cose- implementations Primary Maintainer: Jim Schaad Description: A C# library version of the COSE message specification.  The cryptography for the library is the Bouncy Castle C# implementation. Coverage: The library does only partially implements counter signatures.  The library includes some self testing both internally and againist the examples library Licensing: Revised BSD License 17.4. Implemenation Location: https://github.com/cose-wg/Examples Primary Maintainer: Jim Schaad Description: A set of tests for the COSE library is provided as part of the implementation effort.  Both success and fail tests has been provided.  All of the examples in this document are are part of this example set. Coverage: The attempt has been to have test cases for every message type and algorithm in the document.  Current examples dealing with counter signatures, EdDSA and ECDH with Curve24459 and Goldilocks are missing. Licensing: Public Domain 18. </ins> There are a number of security considerations that need to be taken into account by implementers of this specification.  The security considerations that are specific to an individual algorithm are to prevent or discourage such analysis.  (For example the strings could be defined as 'YES' and 'NO '.)  <ins> 19. </ins> This document is a product of the COSE working group of the IETF. [CREF1] JLS: I have not gone through the document to determine what needs to be here yet.  We mostly want to grab terms that are used in unusual ways or are not generally understood. <ins> [CREF2] JLS: Is is the same registry for both OKP and EC2? </ins>