How does a Client obtain the DH key of a Server

[malishav]

From John Mattsson's review (https://mailarchive.ietf.org/arch/msg/ace/h85KdNLkMxqzCZjJlY-fGlPEyVw/):

• ” The EST client obtained the CA certs including the CA's DH certificate using the /crts function” This seems very inefficient. Why not just use G_Y from EDHOC? The Client/Initiator can use the cipher suite to get the curve it wants. I think this should be added as on option.

[malishav]

Using G_Y, i.e. the EDHOC ephemeral key of the responder, to generate the PoP in the CSR would bind the current run of EDHOC to the enrollment request: Similarly to #17 this does not play nicely with re-enrollment because EDHOC may not be executed during re-enrollment.

However, since the client (EDHOC Initiator) authenticated the server (EDHOC Responder) during the execution of EDHOC, the client must know the server's CRED_R. Therefore, as a possible optimization, the client can use the server's CRED_R to generate a PoP in its CSR, and skip querying the /crts resource. Would that make sense @emanjon?

CC: @gselander

[malishav]

Proposal:

• if EDHOC precedes the enrollment and combined delivery is being used, MUST use G_Y of the server/Responder to generate PoP.
• If EDHOC does not precede the enrollment, use the available static DH key of the server/Responder or request from /crts

( if a combined delivery through draft-ietf-core-oscore-edhoc is being used, we are already in the EDHOC session and G_Y is readily available.)