Should there be a flag for critical EAD?

[emanjon]

There is a new PR #311 suggesting this. There is no background discussion in the PR #311. There would be good with some use case.

The definition of what critical need and how the recipient handles critical would need a lot of discussion and fine-tuning.The handling of critical extensions in C.509 is to my understanding confusing and problematic. Both in the specification and in implementations.

[gselander]

Please see #275 for background discussion and use cases.

[emanjon]

Seems very unclear that the current PR can be the basis for a ECH type mechanism. PR #311 should motivate why it is the basis for an ECH type mechanism or we should have some discussion regarding use cases for a general critical non-critical EAD mechanism. I do not see that #311 follow from #275.

[emanjon]

Having critical/non-critical EAD seems like a reasonable thing in its own, but it is not clear to me that it is a step on the way to a ECH mechanism in EDHOC.

[gselander]

Should we add another column in IANA register?

Type: always critical / always non-critical / application determines criticality

[gselander]

If we define such a Type, the following text can be removed from specification and replaced by IANA consideration:

"A specification registring a new EAD label MUST describe if the EAD item is always critical, always non-critical, or if it can be decided by the application in the sending endpoint."

[gselander]

I merged #311 which addresses some points raised in this issue. Please review and comment if there is anything missing.

The consequences of EDHOC processing of critical / non-critical EAD items is described, but how the security application makes use of this property is left to the associated specification. (In particular, no registration of criticality in the IANA register.)