The transaction ID shouldn't be created (from random) while from CMP_PKIHEADER_init(), but rather through a context setting. The current way of events is somewhat non-natural.
This should then give more control to the API user to do all of the following from RFC 4210 - if ever needed:
The transactionID field within the message header is to be used to
allow the recipient of a message to correlate this with an ongoing
transaction. This is needed for all transactions that consist of
more than just a single request/response pair. For transactions that
consist of a single request/response pair, the rules are as follows.
A client MAY populate the transactionID field of the request. If a
server receives such a request that has the transactionID field set,
then it MUST set the transactionID field of the response to the same
value. If a server receives such request with a missing
transactionID field, then it MAY set transactionID field of the
response.
This will need changes to of CMP_CTX_set1_transactionID() and CMP_PKIHEADER_set1_transactionID().
Per implementation of CMP_PKIHEADER_init(), API users already have the freedom to set any transactionID they want, via calling CMP_CTX_set1_transactionID().
In case ctx->transactionID is NULL, a suitable transactionID is (randomly) created automatically.
In my view, only a minor issue remains here:
CMP_PKIHEADER_set1_transactionID(hdr, transactionID) leaks memory in case the hdr already contains a transaction ID that is overwritten by non-NULL transactionID.