Overall structure of spec for KEM use should be improved

[DDvO]

@Akretsch wrote in #30:

https://github.com/lamps-wg/cmp-updates/blob/main/draft-ietf-lamps-rfc4210bis.md#key-encapsulation refers to https://github.com/lamps-wg/cmp-updates/blob/main/draft-ietf-lamps-rfc4210bis.md#variants-of-using-kem-keys-for-pki-message-protection-sect-e for implementation details. The implementer has to jump between both sections to get an sufficient understanding.

One more point to add on this, which he also mentioned to me this morning: The security considerations section 8.8: https://lamps-wg.github.io/cmp-updates/draft-ietf-lamps-rfc4210bis.html#name-recurring-usage-of-kem-keys contains an important functional requirement:

Each PKI entity using key encapsulation for MAC-based message protection, see Section 5.1.3.4, MUST use a fresh shared secret key (ssk) for each PKI management operation.

IMO this should be given already in Section 5.1.3.4 because otherwise this can easily be overlooked by implementers focusing on the main body of the spec, so regarding KEM use on Section 5.1.3.4.

[HBrock]

Appendix E contains additional explanation, but no normative text. To have the base-specification in Section 5.1.3.4 not too large, this additional guidance was shifted on purpose to an appendix.

Regarding Security Considerations: It is never a good idea to overlook the Security considerations section. See also cms-kemri draft for similar examples for normative text in the Security Considerations section.