Draft: draft-ietf-lake-edhoc

Commentary: Ready to merge I think . 
 Fine by me , but I find this unesthetical : " IDCREDR is intended to facilitate for the Initiator to retrieve the Responder 's authentication key . " then a few lines later : " parameters in IDCREDR are used to identify the Responder 's public key " same for IDCREDI . Seems redundant to have two slightly different formulations like this . 
 Let 's merge this anyway - need to prepare for submission . 
 For a bit unclear reasons . COSE specifies different x5 t header parameters for SS - ECDH sender and recipient , e.g. , x5 t and x5t - sender . When kid is used for SS - ECDH , the same header parameter is used for both sender and recipient ... Unless this is changed in COSE . EDHOC need to add some additional specification or clarification . used in EDHOC all header parameters always refer to sender . 5t - sender is not used etc . 5 t is not used etc . 
 For EDHOC , the header parameter is either transported in IDCREDI or IDCREDR . So it is clear whether the header parameter refers to I or R , i.e. always to the sender . If we want to allow x5t - sender etc , then we need to provide an interpretation of the listing of algorithms associated to x5t - sender ( but not x5 t ) in relation to the EDHOC cipher suite . Does this list limit the EDHOC cipher suite or can it be ignored ? In the former case , the list may need to be updated when new EDHOC cipher suites are defined . This seems like an unnecessary complication when the objective of the header parameter in EDHOC is just to identify the credential and for that purpose x5 t etc . seems sufficient . I propose we state : header parameter in IDCREDx refers to x ( i.e. sender ) x5 - sender MUST NOT be used 
 For EDHOC , the header parameter is either transported in IDCREDI or IDCREDR . So it is clear whether the header parameter refers to I or R , i.e. always to the sender . I think the same could be said for COSE where the recipient structure makes the separation clear . If we want to allow x5t - sender etc , then we need to provide an interpretation of the listing of algorithms associated to x5t - sender ( but not x5 t ) in relation to the EDHOC cipher suite . Does this list limit the EDHOC cipher suite or can it be ignored ? In the former case , the list may need to be updated when new EDHOC cipher suites are defined . This seems like an unnecessary complication when the objective of the header parameter in EDHOC is just to identify the credential and for that purpose x5 t etc . seems sufficient . I do n't undestand this part . EDHOC does not use COSE header parameters to detemine algorithms . I propose we state : That sounds great . 
 For EDHOC , the header parameter is either transported in IDCREDI or IDCREDR . So it is clear whether the header parameter refers to I or R , i.e. always to the sender . From the joint effort in the recent COSE interim , to the best of our knowledge , we think this is all about making distinctions between certificates for different endpoints , although it was stated that this is probably not strictly necessary , so , e.g. two instances of x5 t would do the job . There may perhaps be situations where this is not the case , maybe  was aware of one . All I 'm saying is that at least in EDHOC it is possible to make the distinction . 
 If we want to allow x5t - sender etc , then we need to provide an interpretation of the listing of algorithms associated to x5t - sender ( but not x5 t ) in relation to the EDHOC cipher suite . Does this list limit the EDHOC cipher suite or can it be ignored ? In the former case , the list may need to be updated when new EDHOC cipher suites are defined . This seems like an unnecessary complication when the objective of the header parameter in EDHOC is just to identify the credential and for that purpose x5 t etc . seems sufficient . I do n't undestand this part . EDHOC does not use COSE header parameters to detemine algorithms . Exactly . So what is the significance of the algorithms in table 2 if these COSE header parameters would be used in EDHOC ? I 'm trying to argue that it may be confusing to use in EDHOC a COSE header parameter which has associated algorithms if those algorithms are not relevant in EDHOC . 
 I propose we state : In the recent PR I did instead : header parameter in IDCREDx refers to x ( i.e. sender ) x5 - sender SHOULD NOT be used I think there is a value in allowing applications to apply any COSE header parameter with IDCREDx as long as they can identify the credential . But at the same time discourage the use " -sender " for those who do n't see any use for it . 
 I read  's original issue , and I could n't understand the issue . I do n't think we need x5 - sender ever . 
 The problem is that COSE says the following about x5 t , x5u , x5chain , x5bag : " The header parameters defined in the previous section are used to identify the recipient certificates for the ECDH key agreement " EDHOC needs to state that this is not the case when they are used in EDHOC . 
 Resolved in , now merged .
Paragraph (version A):
ID_CRED_R and ID_CRED_I are transported in message_2 and message_3,
respectively (see asym-msg2-proc and asym-msg3-proc).  They are used
to identify and optionally transport the authentication keys of the
Initiator and the Responder, respectively.  ID_CRED_I and ID_CRED_R
do not have any cryptographic purpose in EDHOC since EDHOC integrity
protects the authentication credential.  EDHOC relies on COSE for
identification of authentication credentials and supports all COSE
header parameters used to identify authentication credentials
including X.509, C509, CWT and CCS.
Paragraph (version B):
ID_CRED_R and ID_CRED_I are transported in message_2 and message_3,
respectively (see asym-msg2-proc and asym-msg3-proc).  They are used
to identify and optionally transport the authentication keys of the
Initiator and the Responder, respectively.  ID_CRED_I and ID_CRED_R
do not have any cryptographic purpose in EDHOC since EDHOC integrity
protects the authentication credential.  EDHOC relies on COSE for
identification of authentication credentials and supports all types
of COSE header parameters used to identify authentication credentials
including X.509, C509, CWT and CCS.
Paragraph (version B):
COSE header parameters in EDHOC are used to identify the sender's
public key credential, i.e., parameters in ID_CRED_R are used to
identify the Responder's public key and parameters in ID_CRED_I are
used to identify the Initiator's public key.  There is therefore no
reason to use the "-sender" header parameters, such as x5t-sender,
defined in Section 3 of I-D.ietf-cose-x509.  Instead, the
corresponding parameter without "-sender", such as x5t, SHOULD be
used.