In a discussion with @HBrock we concluded that the use of the transactionID field in the PKI header should be more clarified for KEM-based message protection.
Currently, the transactionID is an optional field of the KemOtherInfo datastructure. Now, the specification of transactionID in Section 5.1.1 allows the following scenario:
When the PKI entity knows that the PKI management entity uses a KEM key pair and has the authentic public key (Appendix E, Fig. 4), the transaction can be reduced a single request/response pair (if implicitConfirm is used). In that case, no transactionID is required. Since the transactionID is only an optional parameter of the KemOtherInfo data structure, this may result in a KDF context with the KEM ciphertext as the only source of entropy (in the absence of senderNonce and recipNonce).
Suggestion:
There could be a note in Section 5.1.3.4 recommending (or even mandating) the usage of transactionID. This would make the transactionID a mandatory field of KemOtherInfo.
Doing so, a higher entropy of the KDF context and consequently, of the shared secret key (ssk) can be achieved in the absence of senderNonce and recipNonce.
As Section 5.1.1 describes all usage scenarios of the transactionID field, it should be appended with the treatment of the field in KEM use cases.
In a discussion with @HBrock we concluded that the use of the
transactionIDfield in the PKI header should be more clarified for KEM-based message protection.Currently, the
transactionIDis an optional field of theKemOtherInfodatastructure. Now, the specification oftransactionIDin Section 5.1.1 allows the following scenario: When the PKI entity knows that the PKI management entity uses a KEM key pair and has the authentic public key (Appendix E, Fig. 4), the transaction can be reduced a single request/response pair (ifimplicitConfirmis used). In that case, notransactionIDis required. Since thetransactionIDis only an optional parameter of theKemOtherInfodata structure, this may result in a KDF context with the KEM ciphertext as the only source of entropy (in the absence of senderNonce and recipNonce).Suggestion: There could be a note in Section 5.1.3.4 recommending (or even mandating) the usage of
transactionID. This would make thetransactionIDa mandatory field ofKemOtherInfo. Doing so, a higher entropy of the KDF context and consequently, of the shared secret key (ssk) can be achieved in the absence of senderNonce and recipNonce.As Section 5.1.1 describes all usage scenarios of the
transactionIDfield, it should be appended with the treatment of the field in KEM use cases.