Original text:
The MAC is implemented with an AEAD algorithm.  When using static Diffie-Hellman keys the Initiator's and Responder's private authentication keys are called I and R, respectively, and the public <del> authentication keys are called G_I and G_R, respectively. </del>  Only the Responder SHALL have access to the Responder's private authentication key. 3.4. <del> An EDHOC cipher suite consists of an ordered set of COSE code points from the "COSE Algorithms" and "COSE Elliptic Curves" registries: </del>  EDHOC AEAD algorithm EDHOC hash algorithm <del> EDHOC ECDH curve </del>  EDHOC signature algorithm <del> EDHOC signature algorithm curve </del> Application AEAD algorithm Application hash algorithm EDHOC can be used with all algorithms and curves defined for COSE. Implementation can either use one of the pre-defined cipher suites <del> (suites-registry) or use any combination of COSE algorithms to define their own private cipher suite.  Private cipher suites can be identified with any of the four values -24, -23, -22, -21. </del>  The following cipher suites are for constrained IoT where message overhead is a very important factor: CNSA suite CNSA. The different methods use the same cipher suites, but some algorithms <del> are not used in some methods.  The EDHOC signature algorithm and the EDHOC signature algorithm curve are not used in methods without signature authentication. </del>  The Initiator needs to have a list of cipher suites it supports in order of preference.  The Responder needs to have a list of cipher How message_1 is identified, in particular if the optional initial C_1 = "null" of message_1 is present; see <del> Authentication credentials (CRED_I, CRED_R; see auth-cred). </del>  Type used to identify authentication credentials (ID_CRED_I, ID_CRED_R; see id_cred).

Reviewer comments:
Added clarification. Ready to merge?
EDHOC looks to me like it should be usable in situations where one party has no need (or intention) to authenticate, but still wants to authenticate the other party or just use opportunistic encryption. One use case might be a constrained device A obtaining the certificate indicated by device B in the A-B EDHOC exchange from the certificate URI at C indicated by B. A has no need to present credentials (C hosts the certs publicly), but doesn't want to reveal to passive evesdroppers that it's talking to B. It doesn't need to authenticate C, but that might still be a good idea to lock out active MITMs. My impression is that this is possible with EDHOC as it is and that EDHOC is suitable for the task (if not, stop reading and tell me). If it is suitable, would both of these work? Create (in COSE) a key ID type where a RPK that is CREDx can be transported in IDCREDx (useful where you want to come back w/o having any original claims on first use) Have a key where your IDCRED_x says "just what my ephemeral key is". That'd make exchanges just as compact as short-ID'd RPKs, and still be good-enough for unilateral authentication.
From just in the WG meeting: RPK-by-value sounds doable in COSE and would be good enough for a start. The extended case is probably exceeding the LAKE requirements and is to be postponed. (Personally I'd like to keep looking into it, if only to influence any left-over decisions that don't have any other influencing factors and one would rule this out -- but that can happen outside WG activity).
Covered by
The more I think about this, the more I think that specifying a new type in the C509 draft is the right way to go. COSE_Key was not meant to be sent over the wire. It does not have a order and it is not very optimized. When working on issue and PR I realized that the singature curve has nothing to do with the signature alg and is completely detemined by the public key. It would be messy to have to types of public key formation and algorithms. Only using X.509 / C509 seems simpler in my view. A new type in C509 naturally allows optional sending of parameters like key usage, subject name, and life time, which might be useful in a RPK setting as well. Below is an example using the example certificate in the C509 draft. The type is changed to 2, the signature is removed, and all parameters are set to there minimum size. This PRK has key usage digital signature. Could be discussed if fields should be removed or have a non-present value. The RPK has size 43 bytes: 2, h'', [], null, null, [], 1, h'02B1216AB96E5B3B3340F5BDF02E693F16213A04525ED44450 B1019C2DFD3838AB', 1 Below is another example where a serial number, expiery time, and subject name (EUI-64) is provided, size 55 bytes. 2, h'01f5', [], null, 1612224000, h'0123456789AB', 1, h'02B1216AB96E5B3B3340F5BDF02E693F16213A04525ED44450B1019C2DFD3838AB', 1
I think this is important to define, I will start to make some more concrete suggestion and analysis.
The use of UCCS for trust-on-first-use is now included in the master branch, see a1b25ba and commits in its vicinity. Can we close the issue?
I think this can be closed.
The specification that a cipher suite includes "EDHOC signature algorithm curve" make it seems like only ECC signature algorithms can be used. That is not the intension. PS256, HSS-LMS, and future PQC should be allowed.
I made a PR to begin to adress this problem . This was an old know issue that was not transfered from the old GitHub repository. In the PR is it explained that algorithms might have parameters and that parameters need to be included so hat the algorithm is determined. While making the PR, it struck me that the signature algorithm curve is not needed at all and in COSE and X.509 terms this is determined by the public key algorithm. I think this needs to be addresses. Either we remove the signature curve from the cipher suite completely or we specify it as a profiling of the public key. Profiling the public key is however problematic as it is not a COSE key and may be any PKIX algorithm that may not even be standardized for COSE at all. I do not think there is any reason to restrict PKIX. My suggestion is that we remove the public key parameters from the cipher suite.
PR is merged with master. Any further comments on this?
The PR has been discussed and merged. Closing

Revised text:
The MAC is implemented with an AEAD algorithm.  When using static Diffie-Hellman keys the Initiator's and Responder's private authentication keys are called I and R, respectively, and the public  <ins> authentication keys are called G_I and G_R, respectively.  The authentication key algorithm needs to specified with enough parameters to make it completely determined.  Note that for most signature algorithms, the signature is detemined by the signature algorithm and the authentication key algorithm together.  For example, the curve used in the signature is typically determined by the authentication key parameters. </ins> Only the Responder SHALL have access to the Responder's private authentication key. 3.4.  <ins> An EDHOC cipher suite consists of an ordered set of algorithms from the "COSE Algorithms" and "COSE Elliptic Curves" registries. Algorithms need to be specified with enough parameters to make them completely determined.  Currently, none of the algorithms require parameters.  EDHOC is only specified for use with key exchange algorithms of type ECDH curves.  Use with other types of key exchange algorithms would likely require a specification updating EDHOC.  Note that for most signature algorithms, the signature is detemined by the signature algorithm and the authentication key algorithm together, see auth-keys. </ins> EDHOC AEAD algorithm EDHOC hash algorithm  <ins> EDHOC key exchange algorithm (ECDH curve) </ins> EDHOC signature algorithm  Application AEAD algorithm Application hash algorithm EDHOC can be used with all algorithms and curves defined for COSE. Implementation can either use one of the pre-defined cipher suites  <ins> (suites-registry) or use any combination of COSE algorithms and parameters to define their own private cipher suite.  Private cipher suites can be identified with any of the four values -24, -23, -22, -21. </ins> The following cipher suites are for constrained IoT where message overhead is a very important factor: CNSA suite CNSA. The different methods use the same cipher suites, but some algorithms  <ins> are not used in some methods.  The EDHOC signature algorithm is not used in methods without signature authentication. </ins> The Initiator needs to have a list of cipher suites it supports in order of preference.  The Responder needs to have a list of cipher How message_1 is identified, in particular if the optional initial C_1 = "null" of message_1 is present; see  <ins> Profile for authentication credentials (CRED_I, CRED_R; see auth- cred), e.g., profile for certificate or COSE_key, including supported authentication key algorithms (subject public key algorithm in X.509 certificate). </ins> Type used to identify authentication credentials (ID_CRED_I, ID_CRED_R; see id_cred).