No need for `id-hpke-mac` and `HpkeMacParameter` nor for key identifiers

[DDvO]

Currently, section 5.1.3.4 contains the definitions

  id-hpke-mac OBJECT IDENTIFIER ::= { TBD2 }

When id-hpke-mac is used, the parameters MUST employ the HpkeMacParameter syntax. The syntax for HpkeMacParameter is as follows:

  HpkeMacParameter ::= SEQUENCE {
     mac                 AlgorithmIdentifier
     -- the MAC AlgId
  }

I see no need for these.

Any MAC-based message protection is sufficiently determined by the algorithm identifier of the MAC alg used for the given message and by (the selection of) the symmetric key being used. This general case is already covered by section 5.1.3.1 and by the beginning of section 5.1.1 giving hints on how to address the symmetric key. For instance, for the PBM defined in RFC 4211 section 4.4, the set of core algorithms and auxiliary values (such as the salt) used are encoded in a PBMParameter structure, and the shared secret may be implicit or determined by sender field, plus optionally the senderKID field, of the message header. This way, the message protection can be interpreted without further input/history. [moved to #6:]~BTW, IMO it would be helpful if section 5.1.1 also mentioned how to determine the symmetric key being used, namely using the sender and senderKID message header fields.~

[moved to #6:]~Actually, the HPKE+MAC-based message protection is 'just' another special case of the MAC-based message protection very briefly described in section 5.1.3.1. So IMO all the text of 5.1.3.4 should better move there (strictly speaking, as a subsection of 5.1.3.1, but I'd say we can and should save the extra nesting).~

The only special/new thing about this MAC method is how to arrive at the shared symmetric key. Here its is not a pre-shared one, but it is produced on-the-fly using a preparatory message exchange with the KEM cert and the respective KEM key pair of each party.

When the first two messages have been exchanged, the symmetric 'session' key to use for MAC-protecting all further messages of the given transaction has been established. Note that because it is ephemeral, it cannot be (sufficiently) addressed by any static info such as the sender/recipient name and/or the sender/recipient cert or their subject key identifiers (SKID). Therefore, it does not really help to place the SKID anywhere in the message, be it as part of the HpkeMacParameter structure or as the the senderKID and recipKID message header fields.

Anyway, the established symmetric 'session' key needs to be remembered by both parties as long as the transaction is active. Therefore, it must be stored along with their transaction contexts, and it is entirely sufficient to identify/address this symmetric 'session' key using the transactionID.

The fact that all messages starting with the third one are protected using a symmetric key established by then is implicitly clear for the rest of the transaction. So semantically there is no need to give any indication about this (such as id-hpke-mac) in the protected messages. OTOH, for technical reasons some protection alg identifier should be given, and it is most straightforward to place the MAC alg identifier directly in the protectionAlg field. (BTW, the sender of each message could even choose a different MAC algorithm each time, though this flexibility is not needed.)

Thus, for the reasons given, id-hpke-mac and HpkeMacParameter are not needed, neither do we need any way of further referencing the KEM certs and keys used in the first steps.

[HBrock]

David, thank you for this issue. You point at some additional issues unrelated to the topic in the tile. Please open separate issues, it makes it easier to separately discuss them. It confuses me to mx things. thank you.

I support you proposal to directly use the MAC algorithm OID instead of id-hpke-mac in the protectionAlg field of the request message. I will provide an update of the text reflecting this change and we can possibly discuss it in the afternoon.

[DDvO]

You point at some additional issues unrelated to the topic in the tilte. Please open separate issues, it makes it easier to separately discuss them. It confuses me to mix things. thank you.

I noticed two such topics - done for them.

I support you proposal to directly use the MAC algorithm OID instead of id-hpke-mac in the protectionAlg field of the request message. I will provide an update of the text reflecting this change and we can possibly discuss it in the afternoon.

Pleased to hear.

[HBrock]

Resolved in https://github.com/lamps-wg/cmp-updates/commit/ec4fa3e3b120a151a3448a0e17490957424b587c