Menu

#34 Move creation of transactionID to from cmp_lib.c to cmp_ctx.c

Upstream submission
open
None
5
2017-11-15
2017-06-07
No

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().

Discussion

  • David von Oheimb

    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.

     
  • David von Oheimb

    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.

     
  • Martin Peylo

    Martin Peylo - 2017-07-19
    • Group: v1.0 (example) --> Upstream submission
     
  • Martin Peylo

    Martin Peylo - 2017-11-15
    • assigned_to: Martin Peylo
     

Log in to post a comment.