Make PKIMessage.PKIHeader.senderKID optional for PBE/PBMAC1

[mt-johan]

…since it is not used to "uniquely identify a key" as stated in RFC 4210 5.1.1. Contributed under SPDX "LGPL-2.1-or-later".

Describe your changes

RFC 4210 5.1.1 describes the purpose of CMP's PKIMessage.PKIHeader.senderKID.

For PBE/PBMAC1, EJBCA CE only uses this as a courtesy in CmpMessageHelper.protectPKIMessageWithPBMAC1(...) to help a client distinguish between protection keys when present in the request.

   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)
   and SHOULD be omitted otherwise.

How has this been tested?

Shared secret bootstrap use-case where CMP clients gets a cert and trust anchor in IP.

CMP config:

• RA mode
• HMAC authentication module with "Specify secret"
• Random username generation with prefix
• Response protection set to pbe
• Response Additional CA certificates with 1 CA cert.
• No renewal
• No server gen keys

Sending IR protected with PBMAC1 (hmacWithSHA256 due to a bug in BC.)

• Not setting PKIMessage.PKIHeader.senderKID results in a signed PKIMessage (IP).
• Setting PKIMessage.PKIHeader.senderKID to an empty KeyIdentifier (OCTET STRING) returns a PBMAC1 protected PKIMessage (IP).

Checklist before requesting a review

• I have performed a self-review of my code
• I have kept the patch limited to only change the parts related to the patch
• This change requires a documentation update

See also Contributing Guidelines.

[primetomas]

Damn it. I found missing things in this PR. There are some other places where the same thing happens, for other types of messages.
CmpConfirmResponseMessage and CmpErrorResponseMessage

funnily CmpRevokeResponseMessage does already ignore the KeyID. That's how I found it, I started updating a system test (I forgot to mention that tests were missing :-)), and I could not repeat this with a revocation message.

[primetomas]

Can you create a new PR fixing the missing entries.

[mt-johan]

→ #878 created.