KEM protection is hard to follow and understand

[Akretsch]

• 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.
• KEM protection can be used only between two PKI entities (hop to hop) and the protection cannot be validated by third PKI entities (end to end)? So always a reprotection is needed to keep integrity?
• 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 shows some message flows:
  • Please make more clear that one message flow is covered by one transaction.
  • Please specify more in detail the required content of genm, genp and request.
  • The first message flow introduces KEM certificates:
    • How to obtain, how to validate such certificates?
    • How the right certificate to use can identified in extraCerts?
    • Should the chain also be in extraCerts?
  • The second message flow seems to use KEM keys without certificate:
  • What means "protection depending on available key material"?
  • How the PKI Entitiy (Bob) obtains the authenticated public key? Could this replace the KEM certificates in the first message flow too?
  • The third message flow shows a failed transaction.
  • How Bob identifies the right KEM certificate in extraCerts?

[DDvO]

Thank you for this interesting feedback.

For managing the various points mentioned, it would have helped to provide at least the three rather unrelated outer items in separate issues. I am not allowed to edit the above text, but I copied the text of your first two items to #32 and #33 and partly amended it there.

[DDvO]

It remains in this issue here to comment on the last item referring to Appendix E::

Please make more clear that one message flow is covered by one transaction.

I suggest adding this text, which also provides further clarification how the given message flows should be understood:

"For any PKI management operation started by a PKI entity with any type of request message, the following message flows describe the adaptations needed to support the use of a KEM key. There are three cases to distinguish, namely whether the PKI entity or the by PKI management entity uses a KEM key, and whether in the latter case the PKI entity already knows initially the KEM key of the PKI management entity. In case both sides use KEM keys, adaptations need to be combined such that for each direction a shared secret is established"

Please specify more in detail the required content of genm, genp and request.

In the first message flow, I suggest two small additions.

• extend "format unprotected genm" to "format unprotected genm with empty PKIBody". (BTW, this 'empty' genm will look much like the genm described in https://www.rfc-editor.org/rfc/rfc4210#appendix-E.5, but confusion is avoided because the latter sort of genm is required to be protected.)
• extend "KEM ciphertext in PKIBody" to "KEM ciphertext as the only InfoTypeAndValue in PKIBody".

In the second message flow, I suggest extending "KEM ciphertext in generalInfo" to "KEM ciphertext in generalInfo of PKIHeader"

BTW, I suggest replacing in the third message flow "as shown in Figure 4 above" by "as shown in the Figure before" because the constant number 4 cannot be a assumed to be fixed/correct.

The first message flow introduces KEM certificates: How to obtain, how to validate such certificates?

They should be obtained as usual by a CA, which of course needs to support producing certs for KEM public keys. The validation of such a cert and its chain does not depend on the KEM key in the EE cert.

How the right certificate to use can identified in extraCerts? Should the chain also be in extraCerts?

I suggest clarifying this by replacing "containing KEM certificate in extraCerts" by "with extraCerts consisting of the KEM certificate followed by this chain" and similarly in the third message flow.

The second message flow seems to use KEM keys without certificate:

There we do not make assumptions where the public KEM key comes from, but usually the client will have obtained it before from the server as part of a KEM certificate.

What means "protection depending on available key material"?

This just means that the entity protects its message in the usual way: If it has a signature key, it uses this, or else it uses MAC-based protection, using any pre-shared secret or shared symmetric key derived by (EC)DH or also using a key derived via KEM (in the opposite direction).

How the PKI Entity (Bob) obtains the authenticated public key?

By any means, for instance as described in the third message flow.

Could this replace the KEM certificates in the first message flow too?

No, the first message flow is for using KEM in the opposite direction.

The third message flow shows a failed transaction.

Not quite - the error message here just indicates to the client that it needs to use the KEM key contained in the extraCerts.

BTW, unfortunately the failInfo code is somewhat misleading because wrongIntegrity is normally used to indicate that the protection by the PKI entity is wrong, but here it indicates the inability of the PKI management entity to protect its first response using KEM. Here I propose using a new, to-the-point failInfo code or some other indication for this special case, for example giving no failInfo field, which would be less confusing than using wrongIntegrity.

Whether the PKI entity sees this error as a termination of the PKI management operation or uses the same transaction ID for the subsequent request is not specified and looks like it does no matter.

How Bob identifies the right KEM certificate in extraCerts?

As before: it should be stated that it must be in the first extraCert (and followed by the respective chain).

[HBrock]

Issue resolved with above mentioned commit