Draft: draft-ietf-lake-edhoc

Commentary: 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 does n't want to reveal to passive evesdroppers that it 's talking to B. It does n'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 do n'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 , , 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 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
Paragraph (version A):
authentication keys are called G_I and G_R, respectively.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
EDHOC can be used with all algorithms and curves defined for COSE.
Implementation can either use one of the pre-defined cipher suites
(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.
Paragraph (version B):
EDHOC can be used with all algorithms and curves defined for COSE.
Implementation can either use one of the pre-defined cipher suites
(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.
Paragraph (version A):
The different methods use the same cipher suites, but some algorithms
are not used in some methods.  The EDHOC signature algorithm and the
EDHOC signature algorithm curve are not used in methods without
signature authentication.
Paragraph (version B):
The different methods use the same cipher suites, but some algorithms
are not used in some methods.  The EDHOC signature algorithm is not
used in methods without signature authentication.
Paragraph (version A):
Authentication credentials (CRED_I, CRED_R; see auth-cred).
Paragraph (version B):
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).