Original text:
3.5. <del> The ECDH ephemeral public keys are formatted as a COSE_Key of type EC2 or OKP according to Sections 7.1 and 7.2 of I-D.ietf-cose- rfc8152bis-algs, but only the 'x' parameter is included G_X and G_Y. For Elliptic Curve Keys of type EC2, compact representation as per RFC6090 MAY be used also in the COSE_Key.  If the COSE implementation requires an 'y' parameter, any of the possible values of the y-coordinate can be used, see Appendix C of RFC6090.  COSE always use compact output for Elliptic Curve Keys of type EC2. </del>  3.6. most preferred cipher suite of those (note that error messages are not authenticated and may be forged). <del> Generate an ephemeral ECDH key pair as specified in Section 5 of SP-800-56A using the curve in the selected cipher suite and format it as a COSE_Key.  Let G_X be the 'x' parameter of the COSE_Key. </del>  Choose a connection identifier C_I and store it for the length of the protocol. If corr (METHOD_CORR mod 4) equals 1 or 3, C_I is omitted, otherwise C_I is not omitted. <del> Generate an ephemeral ECDH key pair as specified in Section 5 of SP-800-56A using the curve in the selected cipher suite and format it as a COSE_Key.  Let G_Y be the 'x' parameter of the COSE_Key. </del>  Choose a connection identifier C_R and store it for the length of the protocol. parties can derive application keys with other labels or run EDHOC again.  8.3. For many constrained IoT devices it is problematic to support more rfc8152bis-algs this can be addressed by combining randomness and determinism. <del> The referenced processing instructions in SP-800-56A must be complied with, including deleting the intermediate computed values along with any ephemeral ECDH secrets after the key derivation is completed. The ECDH shared secrets, keys, and IVs MUST be secret. </del>  Implementations should provide countermeasures to side-channel <del> attacks such as timing attacks.  Depending on the selected curve, the parties should perform various validations of each other's public keys, see e.g.  Section 5 of SP-800-56A. </del>  The Initiator and the Responder are responsible for verifying the integrity of certificates.  The selection of trusted CAs should be

Reviewer comments:
This was suggested in CFRG during the discussion on HPKE Elliptic-Curve-Point-to-Octet-String Conversion. The compact representation used in EDHOC can be used whenever compact output is used in ECDH (which it almost always is). Important to differenctiate between the wire format, the validation done, and the algorithm for multiplication. EDHOC only touch the wire format, and do not loosen any validation requirements or recommend any particular algorithms form multiplication. Suggestion oflline that it might be better to specify that the "y-bit" is set to 0 instead of giving the implementor an option. Suggestion offline that the draft should refer to SECG in addition or instead of NIST.
I made a PR trying to capture the suggestion from CFRG. I think the PR is ready to merge.
on page 14 would it not be suitable to add that IDCREDx = { x5chain : certificate in DER }, for x = I or R,
Very timely comment. I just made an update to this effect, see b5346fb. I didn't want to include this kind of notation as it requires explanation. Is it good enough?
Suggest to give it a bullet as well. Göran Selander schreef op 2021-02-22 11:26: Links: [1] URL [2] URL [3] URL

Revised text:
3.5.  <ins> EDHOC always uses compact representation of elliptic curve points, see comrep.  In COSE compact representation is achieved by formatting the ECDH ephemeral public keys as COSE_Keys of type EC2 or OKP according to Sections 7.1 and 7.2 of I-D.ietf-cose-rfc8152bis-algs, but only including the 'x' parameter in G_X and G_Y.  For Elliptic Curve Keys of type EC2, compact representation MAY be used also in the COSE_Key.  If the COSE implementation requires an 'y' parameter, the value y = false SHALL be used.  COSE always use compact output for Elliptic Curve Keys of type EC2. </ins> 3.6. most preferred cipher suite of those (note that error messages are not authenticated and may be forged).  <ins> Generate an ephemeral ECDH key pair using the curve in the selected cipher suite and format it as a COSE_Key.  Let G_X be the 'x' parameter of the COSE_Key. </ins> Choose a connection identifier C_I and store it for the length of the protocol. If corr (METHOD_CORR mod 4) equals 1 or 3, C_I is omitted, otherwise C_I is not omitted.  <ins> Generate an ephemeral ECDH key pair using the curve in the selected cipher suite and format it as a COSE_Key.  Let G_Y be the 'x' parameter of the COSE_Key. </ins> Choose a connection identifier C_R and store it for the length of the protocol. parties can derive application keys with other labels or run EDHOC again. <ins> Requirement for how to securely generate, validate, and process the ephermeral public keys depend on the elliptic curve.  For X25519 and X448, the requirements are defined in RFC7748.  For secp256r1, secp384r1, and secp521r1, the requirements are defined in Section 5 of SP-800-56A.  For secp256r1, secp384r1, and secp521r1, at least partial public-key validation MUST be done. </ins> 8.3. For many constrained IoT devices it is problematic to support more rfc8152bis-algs this can be addressed by combining randomness and determinism.  <ins> All private keys, symmetric keys, and IVs MUST be secret. </ins> Implementations should provide countermeasures to side-channel  <ins> attacks such as timing attacks.  Intermediate computed values such as ephemeral ECDH keys and ECDH shared secrets MUST be deleted after key derivation is completed. </ins> The Initiator and the Responder are responsible for verifying the integrity of certificates.  The selection of trusted CAs should be