That is fine for us as we follow the suggestion to derive the transaction ID from the public key. But SCEP also allows to use something different as long as it is unique. So what if someone calculates it differently (e.g. a different hash sum or something else)? The scep_get_cert_initial only provides one way.
Solution: In my opinion, the transaction ID must either be provided directly or come from the PKCSReq message. As GetCertInitial is the message that is periodically sent right after a PKCSReq message and only used in this context, the PKCSReq message should always be available at this time.
I think we should derive the transaction id from the PKCSReq message instead of the public key thus requiring an additional function parameter. What do you think @Javex ?
The function derives the transaction ID from the public key:
https://github.com/Javex/libscep/blob/develop/src/message.c#L491
That is fine for us as we follow the suggestion to derive the transaction ID from the public key. But SCEP also allows to use something different as long as it is unique. So what if someone calculates it differently (e.g. a different hash sum or something else)? The scep_get_cert_initial only provides one way.
Solution: In my opinion, the transaction ID must either be provided directly or come from the PKCSReq message. As GetCertInitial is the message that is periodically sent right after a PKCSReq message and only used in this context, the PKCSReq message should always be available at this time.
I think we should derive the transaction id from the PKCSReq message instead of the public key thus requiring an additional function parameter. What do you think @Javex ?