Questions about SCEP polling mode about sscep

[mbartosch]

At least OpenXPKI expects that the same transaction ID be used, otherwise it is impossible to properly handle latency or delayed certificate issuance on the backend (e. g. if a certificate request has to be approved manually). If you retry with a different transaction ID the PKI will see a new initial enrollment which will also end up as a new pending request in addition to the previous one.
My take on this is to reuse the same transaction ID for a pending request while polling until the client receives the issued certificate or the client determines that the request has failed (e. g. after a few hours or days).

[ml16685]

At least OpenXPKI expects that the same transaction ID be used, otherwise it is impossible to properly handle latency or delayed certificate issuance on the backend (e. g. if a certificate request has to be approved manually). If you retry with a different transaction ID the PKI will see a new initial enrollment which will also end up as a new pending request in addition to the previous one.
My take on this is to reuse the same transaction ID for a pending request while polling until the client receives the issued certificate or the client determines that the request has failed (e. g. after a few hours or days).

@mbartosch, Thank you for response. I will proceed with this approach then.

Also, regarding transaction Id value used by sscep for enroll. As I got from source ccode, it will remain the same as long as public key in csr file will be the same. Is that correct?

[mbartosch]

IIRC the code computes the TID from the public key via a hash. This is also suggested by the standard and good practice, IMO.

[ml16685]

Ok, thank you.