Change:
The CFRG EC algorithms are currently too far in the future to keep. Remove the ad put in the to be done later document.

Discussion:
12.4.1. The basic mathematics for Elliptic Curve Diffie-Hellman can be found <del> in RFC6090.  Two new curves have been defined in I-D.irtf-cfrg- curves. </del> <ins> in RFC6090. </ins> ECDH is parameterized by the following:

in table-ecdh-es-table. This document defines these algorithms to be used with the curves <del> P-256, P-384, P-521, X25519 and X448.  Implementations MUST verify that the key type and curve are correct, different curves are restricted to different key types.  Implementations MUST verify that the curve and algorithm are appropriate for the entities involved. </del> <ins> P-256, P-384, P-521.  Implementations MUST verify that the key type and curve are correct, different curves are restricted to different key types.  Implementations MUST verify that the curve and algorithm are appropriate for the entities involved. </ins> 12.5.

13.1. <del> Two different key structures are being defined for Elliptic Curve </del> <ins> Two different key structures could be defined for Elliptic Curve </ins> keys.  One version uses both an x and a y coordinate, potentially with point compression.  This is the traditional EC point representation that is used in RFC5480.  The other version uses only the x coordinate as the y coordinate is either to be recomputed or <del> not needed for the key agreement operation.  An example of this is Curve25519 I-D.irtf-cfrg-curves.  [CREF13] </del> <ins> not needed for the key agreement operation Currently no algorithms are defined using this key structure. </ins> 13.1.1. <del> One class of Elliptic Curve mathematics allows for a point to be completely defined using the curve and the x coordinate of the point on the curve.  The two curves that are initially setup to use is point format are Curve 25519 and Curve 448 which are defined in I- D.irtf-cfrg-curves. For EC keys with only the x coordinates, the 'kty' member is set to 1 (EC1).  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. [CREF14] 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.1.2. </del> The traditional way of sending EC curves has been to send either both the x and y coordinates, or the x coordinate and a sign bit for the y coordinate.  The latter encoding has not been recommend in the IETF

contains the x coordinate for the EC point.  The integer is converted to an octet string as defined in SEC1.  Zero octets MUST <del> NOT be removed from the front of the octet string.  [CREF15] </del> <ins> NOT be removed from the front of the octet string.  [CREF13] </ins> contains either the sign bit or the value of y coordinate for the EC point.  For the value, the integer is converted to an octet

This document defines a key structure for both the public and private halves of RSA keys.  Together, an RSA public key and an RSA private <del> key form an RSA key pair.  [CREF16] </del> <ins> key form an RSA key pair.  [CREF14] </ins> The document also provides support for the so-called "multi-prime" RSA where the modulus may have more than two prime factors.  The

if one exists This registry will be initially populated by the values in table- <del> ec1-keys, table-ec2-keys, table-rsa-keys, and table-symmetric-keys. The specification column for all of these entries will be this document. </del> <ins> ec2-keys, table-rsa-keys, and table-symmetric-keys.  The specification column for all of these entries will be this document. </ins> 15.7.

15.8.1. This section registers the "application/cose" and "application/ <del> cose+cbor" media types in the "Media Types" registry.  [CREF17] These </del> <ins> cose+cbor" media types in the "Media Types" registry.  [CREF15] These </ins> media types are used to indicate that the content is a COSE_MSG. Type name: application

fields defined in the table are transported and thus why they have labels. <del> [CREF13] Ilari: Check to see what the curves are renamed to during final publishing.  It appears to be X25519 now. [CREF14] JLS: Do we create a registry for curves?  Is is the same registry for both EC1 and EC2? [CREF15] JLS: Should we use the bignum encoding for x, y and d instead </del> <ins> [CREF13] JLS: Should we use the bignum encoding for x, y and d instead </ins> of bstr? <del> [CREF16] JLS: Looking at the CBOR specification, the bstr that we are </del> <ins> [CREF14] JLS: Looking at the CBOR specification, the bstr that we are </ins> looking in our table below should most likely be specified as big numbers rather than as binary strings.  This means that we would use the tag 6.2 instead.  From my reading of the

the resulting output.  The specification of bignum does explicitly allow for integers encoded with leading zeros. <del> [CREF17] JLS: Should we register both or just the cose+cbor one? </del> <ins> [CREF15] JLS: Should we register both or just the cose+cbor one? </ins>