Change:
This PR is the same as , but rebased on the current master. PR consisted of 4 commits, two already merged and the two in this PR
Merging this now to have an updated master to work on for and
Make a normative statement in relevant section
Resolved with indicated commit.
From non-nits: 3.5.2, 2nd para: on what basis is rfc5280 a normative ref whilst [I-D.ietf-cose-cbor-encoded-cert] is informative? They seem to be equally required for implementation based on this text. Given [I-D.ietf-cose-x509] is normative, perhaps it wouldn't add delay if both were? I made RFC 5820 informative. 3.5.2: I forget if use of the full DER-encoded X.509 cert was discussed on the list or not? If not, the alternative would have been to use the SPKI which has some slightly different properties that can sometimes be beneficial (potentially easier use of different CAs on each side). I'm not asking for a change here btw, just to check was this discussed on the list. (I see appendix D.2 talks a bit about this.) The use of (full DER-encoded) X.509 is described and planned to be used in deployments. I think Marek mentioned that in his presentation at IETF 113. Should be known. I don't think SPKI has been discussed. Any action you propose? 5.2.3: what happens if the decode of message1 fails? (Say due to an unknown suite.) Does EAD1 get provided to the application? I hope not! Maybe the text after the bullets needs to specify this explicitly? Same for other sections wrt providing EAD to the application (esp EAD1 and EAD2). The current text says: The intent here and all other message processing is that you carry out the processing in steps and if any step fail then you don't carry out the subsequent steps. Is that clear enough? Then that would cover the case of unknown suite. But perhaps it doesn't cover other errors occuring at reception of message_1. Does the state machine make this more clear (though just an example)? Should we move some of that text here? 9.4: As the method field is how we handle breaking changes, do we really want that registry to be specification required? The alternative might be standards action, if we prefer the IESG to be involved in such changes. This has been discussed. One option is to require standards action for low method numbers. Anyone else has an opinion?
Hmm - is that the right plan? If they're all informative references that'd imply that the CRED_I/R handling code (whether x.509, cbor or whatever) wasn't really part of an edhoc implementation. Is/should one of 'em be mandatory to implement (and hence normative)?
Only action I'm proposing is checking we're ok with that as I don't recall it being discussed on the list. On the basis that it's been in the draft for >1 year and implementers haven't complained and it's been raised on the list (in my recent review), I think we're good as-is (unless someone yells). Edit [GS]: OK, I wait for further input or else done.
I'm not sure it's clear enough - esp wrt passing on EAD which can have side-effects that could be bad (e.g. if some identifier were stored even though message processing had failed for some reason). I think the EAD stuff is the only way that kind of thing might happen - if so, then maybe saying that EAD should only be passed to applications after all processing steps have succeeded might be right? Edit [GS]: Proposal in
To be clear - I'm fine with it as-is, but just wanted to check. As it's been raised on the list, people there can express their opinions as they wish so I don't see a need to specifically survey opinions further. Edit [GS]: OK, I wait for further input or else done.
Hmm - certs and RPK are quite different cases. It is not clear why mandate one if some only use the other. If something must to be mandated, I would say it is the use of CCS identified with a kid, i.e. RPK, not certs. Should we mandate this?
To be honest, I'd have to re-read the draft to be sure, but I thought raw public keys were in practice mandatory:-) If all the implementations do support those (which I guess is the case), then it'd probably be no harm to explicitly say that's mandatory to implement maybe, if that's not already there somewhere.
No credential or identification of credential is mandatory currently.
ok so I guess if they're all optional to implement then yes having them be informative references is defensible - it might come up in later reviews I guess but can be dealt with then if needed. Might be no harm if you can summarise that as the response to that comment on the list (though maybe wait a bit to see if someone else chimes in here) Edit: Mail sent to the list
The use of (full DER-encoded) X.509 has been included since -00. Actually even draft-selander-lake-edhoc-00. I think the use of 'x5t' (which is full DER-encoded X.509) has been discussed quite a lot. Full DER-encoded X.509 is also part of the test vectors and the traces document. If anybody wants SPKI in EDHOC/COSE they just need to define a COSE header parameter at a later stage.
I would personally prefer that...
PR is merged. Separate issue opened for the remaining comment. Closing this.

Discussion:
5.2.3. <del> The Responder SHALL process message_1 as follows: </del> <ins> The Responder SHALL process message_1 in the following order: </ins> Decode message_1 (see CBOR). <del> Verify that the selected cipher suite is supported and that no prior cipher suite in SUITES_I is supported. </del> <ins> Process message_1, in particular verify that the selected cipher suite is supported and that no prior cipher suite in SUITES_I is supported. </ins> <del> If EAD_1 is present then make it available to the application for EAD processing. </del> <ins> If all processing completed successfully, and if EAD_1 is present, then make it available to the application for EAD processing. </ins> If any processing step fails, then the Responder MUST send an EDHOC error message back as defined in error, and the protocol MUST be

5.3.3. <del> The Initiator SHALL process message_2 as follows: </del> <ins> The Initiator SHALL process message_2 in the following order: </ins> Decode message_2 (see CBOR).

Decrypt CIPHERTEXT_2, see asym-msg2-proc. <del> Make ID_CRED_R and (if present) EAD_2 available to the application for authentication- and EAD processing. </del> <ins> If all processing completed successfully, then make ID_CRED_R and (if present) EAD_2 available to the application for authentication- and EAD processing. </ins> Obtain the authentication credential (CRED_R) and the authentication key of R from the application (or by other means).

5.4.3. <del> The Responder SHALL process message_3 as follows: </del> <ins> The Responder SHALL process message_3 in the following order: </ins> Decode message_3 (see CBOR).

and 5.3 of RFC9052, with the EDHOC AEAD algorithm in the selected cipher suite, and the parameters defined in asym-msg3-proc. <del> Make ID_CRED_I and (if present) EAD_3 available to the application for authentication- and EAD processing. </del> <ins> If all processing completed successfully, then make ID_CRED_I and (if present) EAD_3 available to the application for authentication- and EAD processing. </ins> Obtain the authentication credential (CRED_I) and the authentication key of I from the application (or by other means).