Use of EAD fields of EDHOC to transport EST?

[malishav]

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

“External Authorization Data (EAD) fields of EDHOC are intentionally not used to carry EST payloads because EDHOC needs not be executed in the case of re-enrollment.” This seems to me like the wrong decision. Using EAD would be much more efficient for the first enrollment. How common and important is re-enrollment? By using EDHOC efficiently I think the client might be able to send the CSR in message_3 and get the cert in message_4.

[malishav]

@emanjon With a lifetime of an IoT device on the order of several years, we definitely need to support the case of re-enrollment which may occur pending certificate expiration. Having separate code paths for re-enrollment and initial enrollment significantly complicates the implementation of the protocol. This would be the case if we opt for EDHOC EAD transport during initial enrollment and OSCORE-based transport during re-enrollment.

One option would be to require EDHOC be executed on re-enrollment, just like during the initial enrollment. Given the PSK-based rekeying work that is going to happen in LAKE, we could transport the re-enrollment messages in the optimized rekeyed handshake. We'd still need to keep the dependency on OSCORE in the draft in order to support other EST functions, like /crts. Given that, there would still be two separate code paths in the implementation: one for /sen and /sren-targeted interactions transported via EDHOC and its EAD fields; one code path for e.g. the /crts function transported via OSCORE.

Second option would be to keep things as-is, but to mention the use of draft-ietf-core-oscore-edhoc and piggyback OSCORE message within the EDHOC handshake. That way, the initial enrollment can happen, as you suggest, in message_3 and message_4.

I think I am in favor of option 2. What are your thoughts on this?

CC: @gselander

[gselander]

Agree, option 2 is good.

[malishav]

The draft discusses the use of draft-ietf-core-oscore-edhoc in Section 3.4 on Optimizations. Closing the issue.