Draft: draft-ietf-lake-edhoc

Commentary: Ed25519 instead of EdDSA 
 Comment from Loïc : 
 let 's just be careful that we are aligned with RFC 8152 definitions here . 
 What [ 1 ] says it not particulary important . We only care the standadized versions which often are not equal to the original academic papers . In this case we want to follow firstly COSE RFC 8152 and secondly RFC 8032 . COSE calls the signature algorithm " EdDSA " so I think 9.2 is correct . All uses of " EdDSA " in the EDHOC draft refer to the generalized signature system EdDSA , so also according to [ 1 ] , I do not see a problem either . 9.2 talks about the generalized signature system EdDSA used with the curves Ed25519 and Ed448 ( following RFC 8152 ) . Do we need some more references to COSE . Some of the other reviewers asked about references to LMS . Should be clear in the EDHOC draft that basicaaly everything concerning algorithms and IDCREDx follows from COSE and than any details or futher references can be found there . 
 I think the EDHOC document needs to be clearer that all terminology follows COSE and that all definitions is found in COSE .  has strange naming that COSE has borrowed . And maybe COSE some strange names on it own . The curve registry list X25519 , X448 , Ed25519 , Ed448 , as curves ( the CFRG names are  and Curve25519 etc . , ) AES-128 is often called A128 ECDSA with SHA-256 is called ES256 RSASSA - PSS with SHA-256 is called PS256 RSASSA - PKCS1 - v15 using SHA-256 is called RS256 RSASSA - PKCS1 - v15 using SHA-1 is called RS1 HKDF - AES-128 ............ I genuinly hate a lot of these names . I get many questions from people internally at my company from people asking about these weird names . They cause a lot of confusion and extra work for no apperent benefit . However , I think EDHOC needs to follow COSE . We should just explain that better . 
 Note that " EdDSA " in Section 9.2 is not even " Ed25519 " . The choice between Ed25519 and Ed448 depends on the authentication key as specified by COSE . 
 Closing this since is now merged .
Mailing list commentary: Hello LAKE , Sorry for this very late remark . But it seems that " EdDSA " is not the proper wording to use in the draft ( at least in Section 9.2 ) . I quote the original paper by Bernstein , Duif , Lange , Schwabe and [ 1 ] : " This section specifies the signature system used in this paper , and a generalized signature system EdDSA that can be used with other choices of elliptic curves . " " Our recommended curve for EdDSA is a twisted curve birationally equivalent to the curve Curve25519 [ ... ] We use the name Ed25519 for EdDSA with this particular choice of curve . " Therefore " Ed25519 " should be used in place of " EdDSA " ( at least in Section 9.2 ) . What do you reckon ? Best regards [ 1 ] High - speed high - security signature , ,  , , Schwabe and , 2011 . – Applied Cryptography Group +33 ( 0)2 31 15 91 24 Orange Restricted
Paragraph (version A):
An EDHOC cipher suite consists of an ordered set of algorithms from
the "COSE Algorithms" and "COSE Elliptic Curves" registries as well
as the EDHOC MAC length.  Algorithms need to be specified with enough
parameters to make them completely determined.  The MAC length MUST
be at least 8 bytes.  EDHOC is currently only specified for use with
key exchange algorithms of type ECDH curves, but any Key
Encapsulation Method (KEM), including Post-Quantum Cryptography (PQC)
KEMs, can be used in method 0, see pqc.  Use of other types of key
exchange algorithms to replace static DH authentication (method
1,2,3) would likely require a specification updating EDHOC with new
methods.
Paragraph (version B):
An EDHOC cipher suite consists of an ordered set of algorithms from
the "COSE Algorithms" and "COSE Elliptic Curves" registries as well
as the EDHOC MAC length.  All algorithm names and definitions follows
from COSE I-D.ietf-cose-rfc8152bis-algs.  Note that COSE sometimes
uses peculiar names such as ES256 for ECDSA with SHA-256, A128 for
AES-128, and Ed25519 for the curve edwards25519.  Algorithms need to
be specified with enough parameters to make them completely
determined.  The MAC length MUST be at least 8 bytes.  EDHOC is
currently only specified for use with key exchange algorithms of type
ECDH curves, but any Key Encapsulation Method (KEM), including Post-
Quantum Cryptography (PQC) KEMs, can be used in method 0, see pqc.
Use of other types of key exchange algorithms to replace static DH
authentication (method 1,2,3) would likely require a specification
updating EDHOC with new methods.