[Ace] EDHOC support

["Damm, Benjamin" <[e-mail]>]

Hello ace,

We've done an internal review of EDHOC and support its movement towards
RFC.  A few questions:

* It isn't clear (to us) how EDHOC's message 2 achieves proof of
  possession prior to use. NIST SP-800-56A seems fairly clear that proof
  of possession is required before confirmation of a derived key, but
  message 2 seems to force U to derive and use a key before PoP can be
  done.  A pointer to why this is considered safe would be appreciated.

* The requirement to support curve x25519 is an odd one for us because
  our device fleet is using P-256. This is not a request to require
  P-256, but rather, that a required curve is not needed. Instead of a
  MUST I'd like to see this be a SHOULD.

* Given the spectre of PQC we think providing for some flexibility in
  algorithms a must. We use P-256 today but might use P-384 or other
  higher-order curves tomorrow. Transition periods mandate algorithm
  flexibility.

We're looking forward to applying EDHOC/OSCORE to secure end-to-end CoAP
application traffic that is transiting multiple proxies.

Ben