Draft: draft-ietf-core-oscore-groupcomm

Commentary: 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 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  [ 1 ] to harmonize with EDHOC [ 2 ] . [ 1 ] [ 2 ] ( 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 ] 
 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 should n'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
The Shared Secret is computed as a static-static Diffie-Hellman
shared secret NIST-800-56A, where the endpoint uses its private
key and the public key of the other endpoint X.  The Shared Secret
is used as Input Keying Material (IKM) in the HKDF.
If EdDSA asymmetric keys are used, the Edward coordinates are mapped
to Montgomery coordinates using the maps defined in Sections 4.1 and
Section 5 of RFC7748.
IKM-Recipient - the Input Keying Material (IKM) used in HKDF for
the derivation of the Recipient Sender Key - is the concatenation
of endpoint X's signature public key from the Recipient Context,
the endpoint's own signature public key, and the Shared Secret.
The Shared Secret is computed as a cofactor Diffie-Hellman shared
secret, see Section 5.7.1.2 of NIST-800-56A, where the endpoint
uses its private key and the public key of the other endpoint X.
Note the requirement of validation of public keys in ssec-crypto-
considerations.  For X25519 and X448, the procedure is described
in Section 5 of RFC7748 using public keys mapped to Montgomery
coordinates, see montgomery.
If EdDSA asymmetric keys are used, the Edward coordinates are mapped
to Montgomery coordinates using the maps defined in Sections 4.1 and
Section 5 of RFC7748.  For further details, see montgomery.
The y-coordinate of the other endpoint's Ed25519 public key is
decoded as specified in Section 5.1.3 of RFC8032.  The Curve25519
u-coordinate is recovered as u = (1 + y) / (1 - y) (mod p) following
the map in Section 4.1 of RFC7748.  Note that the mapping is not
defined for y = 1, and that y = -1 maps to u = 0 which corresponds to
the neutral group element and thus will result in a degenerate shared
secret.  Therefore implementations MUST abort if the y-coordinate of
the other endpoint's Ed25519 public key is 1 or -1 (mod p).
The private signing key byte strings (= the lower 32 bytes used for
generating the public key, see step 1 of Section 5.1.5 of RFC8032)
are decoded the same way for signing in Ed25519 and scalar
multiplication in X25519.  Hence, to compute the shared secret the
endpoint applies the X25519 function to the Ed25519 private signing
key byte string and the encoded u-coordinate byte string as specified
in Section 5 of RFC7748.
The y-coordinate of the other endpoint's Ed448 public key is decoded
as specified in Section 5.2.3. of RFC8032.  The Curve448 u-coordinate
is recovered as u = y^2 * (d * y^2 - 1) / (y^2 - 1) (mod p) following
the map from "edwards448" in Section 4.2 of RFC7748, and also using
the relation x^2 = (y^2 - 1)/(d * y^2 - 1) from the curve equation.
Note that the mapping is not defined for y = 1 or -1.  Therefore
implementations MUST abort if the y-coordinate of the peer endpoint's
Ed448 public key is 1 or -1 (mod p).
The private signing key byte strings (= the lower 57 bytes used for
generating the public key, see step 1 of Section 5.2.5 of RFC8032)
are decoded the same way for signing in Ed448 and scalar
multiplication in X448.  Hence, to compute the shared secret the
endpoint applies the X448 function to the Ed448 private signing key
byte string and the encoded u-coordinate byte string as specified in
Section 5 of RFC7748.
The EdDSA signature algorithm and the elliptic curve Ed25519 RFC8032
are mandatory to implement.  For endpoints that support the pairwise
mode, the ECDH-SS + HKDF-256 algorithm specified in Section 6.3.1 of
I-D.ietf-cose-rfc8152bis-algs and the X25519 curve RFC7748 are also
mandatory to implement.
The EdDSA signature algorithm Ed25519 RFC8032 is mandatory to
implement.  For endpoints that support the pairwise mode, the ECDH-SS
+ HKDF-256 algorithm specified in Section 6.3.1 of I-D.ietf-cose-
rfc8152bis-algs and the X25519 algorithm RFC7748 are also mandatory
to implement.
The derivation of pairwise keys defined in key-derivation-pairwise is
compatible with ECDSA and EdDSA asymmetric keys, but is not
compatible with RSA asymmetric keys.  The security of using the same
key pair for Diffie-Hellman and for signing is demonstrated in
Degabriele.
The derivation of pairwise keys defined in key-derivation-pairwise is
compatible with ECDSA and EdDSA asymmetric keys, but is not
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.