search

certnanny / sscep

SSCEP is a command line client for the SCEP protocol
Other
175 stars 92 forks source link

Questions about SCEP polling mode #136

Open ml16685 opened 3 years ago

ml16685 commented 3 years ago

Hello,

Could you please advice about a few questions related to SCEP polling mode:

1) Do I correctly understand that as long as I execute sscep with the same csr file (provided via -r option), tansaction Id for enroll will stay the same, and it is in fact MD5 hash of the public key from the csr file?

2) I need to implement the following polling scheme:

Initially there should be a PKCSReq and a number of CertPolls with a small retry interval. If response is still Pending, the service should sleep for several hours and then resume polling.

What is the correct approach to resume polling after that several hours sleep?

As I understand, RFC 8894 advices to resume polling with a new PKCSReq (section "5.2. Transactions with Errors").

But is it possible that SCEP servers will maintain transaction even for several hours? In this case it seems more rational to first try resume with CertPoll and in case of Failure response to start a new PKCSReq.

Or it is not common for the servers to maintain long transactions and starting a new PKCSReq is a more correct appoach anyway?

mbartosch commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Ok, thank you.