Clarify in section 5.1.1 how to determine the symmetric key being used

[DDvO]

[this issue has been carved out from #3]

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.

[HBrock]

There is already a ToDo in the text to add some content to the description of senderKID and recipKID. My proposal would be to use the subjectKID of the KEM certificates used by the end entity and the PKI. What do you think?

[DDvO]

There is already a ToDo in the text to add some content to the description of senderKID and recipKID.

You mean < ToDo: Possibly add a protection mechanism using KEM keys. >?

The recipKID is not needed for KEM keys.

My proposal would be to use the subjectKID of the KEM certificates used by the end entity and the PKI. What do you think?

So you mean, to place in the senderKID field the subject key identifier (SKID) of the KEM cert used by the respective sender?

Certainly it is preferable to use the SKID if it is available, so I support requiring its use in this case. Yet note that RFC 5280 requires its presence in X.509v3 compliant certs only for CA certs. So we should also mention somehow that the sender field may be used if needed. Which is already stated by RFC 4210 (though not specifically for symmetric keys) and inherited in 5.1.1:

The sender field contains the name of the sender of the PKIMessage. This name (in conjunction with senderKID, if supplied) should be sufficient to indicate the key to use to verify the protection on the message.

[HBrock]

As we need two HPKE exchanges to establish a shared secret capable authenticating the server and the client, the KEM certificates of both sides are needed, like with D-H. Therefore, I think we need to use both senderKID and recipKID. We can discuss later in our meeting.

[HBrock]

Design team meeting minutes: This issue was not discussed.

[HBrock]

done

[HBrock]

@DDvO can you please check if this is what you requested?

[HBrock]

@DDvO Ping

[HBrock]

As we changed to unilateral authenticated KEM key establishment, there is no need to identify a KEM key from the recipient. Therefore in Section 5.1.1 the subsentence in parentheses (recipKID will normally only be required where protection of the message also uses the recipient's KEM key) must be removed.

[DDvO]

Actually better return to the original subsentence in parentheses referring to DH keys: (recipKID will normally only be required where protection of the message uses Diffie-Hellman (DH) keys)

such that the paragraph becomes

senderKID and recipKID are usable to indicate which keys have been used to protect the message (recipKID will normally only be required where protection of the message uses Diffie-Hellman (DH) keys). These fields MUST be used if required to uniquely identify a key (e.g., if more than one key is associated with a given sender name). The senderKID SHOULD be used in any case.

[HBrock]

done