Code change:
The derivation of pairwise keys defined in key-derivation-pairwise is compatible with ECDSA and EdDSA asymmetric keys, but is not <del> compatible with RSA asymmetric keys.  The security of using the same key pair for Diffie-Hellman and for signing is demonstrated in Degabriele. </del> <ins> compatible with RSA asymmetric keys. For the public key translation from Ed25519 (Ed448) to X25519 (X448) specified in key-derivation-pairwise, variable time methods can be used since the translation operates on public information.  Any byte string of appropriate length is accepted as a public key for X25519 (X448) in RFC7748, it is therefore not necessary for security to validate the translated public key (assuming the translation was successful). The security of using the same key pair for Diffie-Hellman and for signing (by considering the ECDH procedure in sec-derivation-pairwise as a Key Encapsulation Mechanism (KEM)) is demonstrated in Degabriele and Thormarker. Applications using ECDH (except X25519 and X448) based KEM in sec- derivation-pairwise are assumed to verify that a peer endpoint's public key is on the expected curve and that the shared secret is not the point at infinity.  The KEM in Degabriele checks that the shared secret is different from the point at infinity, as does the procedure in Section 5.7.1.2 of NIST-800-56A which is referenced in sec- derivation-pairwise. Extending Theorem 2 of Degabriele, Thormarker shows that the same key pair can be used with X25519 and Ed25519 (X448 and Ed448) for the KEM specified in sec-derivation-pairwise.  By symmetry in the KEM used in this document, both endpoints can consider themselves to have the recipient role in the KEM -- as discussed in Section 7 of Thormarker - and rely on the mentioned proofs for the security of their key pairs. Theorem 3 in Degabriele shows that the same key pair can be used for an ECDH based KEM and ECDSA.  The KEM uses a different KDF than in sec-derivation-pairwise, but the proof only depends on that the KDF has certain required properties, which are the typical assumptions about HKDF, e.g., that output keys are pseudorandom.  In order to comply with the assumptions of Theorem 3, received public keys MUST be successfully validated, see Section 5.6.2.3.4 of NIST-800-56A. The validation MAY be performed by a trusted Group Manager.  For Degabriele to apply as it is written, public keys need to be in the expected subgroup.  For this we rely on cofactor DH, Section 5.7.1.2 of NIST-800-56A which is referenced in sec-derivation-pairwise. HashEdDSA variants of Ed25519 and Ed448 are not used by COSE, see Section 2.2 of I-D.ietf-cose-rfc8152bis-algs, and are not covered by the analysis in Thormarker, and hence MUST NOT be used with the public keys used with pairwise keys as specified in this document. </ins> 10.14.

Related discussion:
text: NAME Good point about being more explicit. I actually think is valuable to reference an existing encoding of public keys providing also key type and curve, like CREDX in URL Also, there is a discussion about format for public keys in COSE, which if it is specified probably will be referenced by EDHOC instead of CREDX. I would be good if there is a common format used in all these instances. For the time being I propose that we reference CRED_X with empty text string subject name, and keep track of the COSE activity.
We should consider replace the NIST reference with SECG [1] to harmonize with EDHOC [2]. [1] URL [2] URL (edit) ... but the commits in [3] mainly refers to the NIST spec. so I propose we keep it as is for the time being. [2] URL
It looks good to me; we can give more details on one point. For the two HKDF invocations in Section 2.3.1, we can define more explicitly how the public keys are expressed when concatenated to form IKM-Sender and IKM-Recipient. Given a public key, that can simply be: For OKP signature keys, the compressed 'x' coordinate, i.e. what would be expressed in the key parameter -2 of a corresponding COSE Key. For EC2 signature keys, the 'x' coordinate followed by the 'y' coordinate in this order, i.e. what would be expressed in the key parameters -2 and -3 of a corresponding COSE Key. This should be sufficient, i.e. it shouldn't be needed to have a more structured encoding of public keys providing also key type and curve, e.g. like done for CRED_X in URL