Draft: draft-ietf-lake-edhoc

Commentary: 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 . I did n't want to include this kind of notation as it requires explanation . Is it good enough ? 
 Suggest to give it a bullet as well .   schreef op 2021 - 02 - 22 11:26 : Links : [ 1 ] [ 2 ] [ 3 ]
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
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.
Implementations should provide countermeasures to side-channel
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.
Paragraph (version B):
All private keys, symmetric keys, and IVs MUST be secret.
Implementations should provide countermeasures to side-channel
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.