Changes needed in 3.5 (identity, credential, trust achor)

[emanjon]

While trying to add TOFU I noticed that 3.5 require quite big changes. The section 3.5 is not clear at all what is the responsibility of the Application and what is the responsibility of EDHOC. EDHOC provides proof-of-possession and transfers the credentials, but that is it.

• Authentication is purely outside of a normal EDHOC implementation. This need to be made clear. Identity handling, credentials, and trust anchors are purely the resposibility of the application. An EDHOC implementation could potentially implement authentication for a specific application. As some TLS implementation do for HTTPS, but this would be outside of the EDHOC specification. I think quite much text should be moved to an appendix.

• Interface between EDHOC and Application is not even mention. While the API should not be specified in detailed, it should likely be a requirement to be able to do mutual authentication. A simple interface for this is that EDHOC gives the credential to the application and the application can say YES or NO. An EDHOC implementation could also allow the implementation to give input to EDHOC, but this would be VERY application specific.

[gselander]

As a case in point, one of the comments in Sean's review that can be answered by this context:

Is a peer supposed to check status information for its peer’s certificate/key?

[emanjon]

Is a peer supposed to check status information for its peer’s certificate/key?

I think this type of considerations should be in an appendix. Very much depends on the application.

[gselander]

I think this issue is addressed with the merge of PR #240.