#9 handle transactionIdInUse PKIFailureInfo automatically

[Martin Peylo]

Automate resending the request with a newly generated transactionID in case the server replies with a PKIFailureInfo of transactionIdInUse as described in 5.1.1 (around line 1440) of RFC 4210.

[Martin Peylo]

However it appears to me that this is very unlikely - and it would need to be clarified with server implementations first how they handle this. Most interestingly is what "transactionID" do they set in this case?

In cmp_ses.c it appears to me that the the error would need to be handled here - and then also when an Error message is encountered.

241 / compare received transactionID with our current one /
242 if (ctx->transactionID && (!(rep)->header->transactionID ||
243 ASN1_OCTET_STRING_cmp(ctx->transactionID, (rep)->header->transactionID))) {
--> The check/handling needs to go here.
244 CMPerr(type_function, CMP_R_ERROR_TRANSACTIONID_UNMATCHED);
245 return 0;
246 }

and

248 / catch if the received message type is not one of the expected ones (e.g. error) /

249 if (rcvd_type != type_rep &&
250 !(type_rep == V_CMP_PKIBODY_POLLREP && / instead of pollrep there could be IP/CP/KUP /
251 (rcvd_type == V_CMP_PKIBODY_IP ||
252 rcvd_type == V_CMP_PKIBODY_CP ||
253 rcvd_type == V_CMP_PKIBODY_KUP))) {
254 char errmsg[256];
--> The check/handling needs to go here.
255 CMPerr(type_function, CMP_R_PKIBODY_ERROR);
256 ERR_add_error_data(1, PKIError_data(*rep, errmsg, sizeof(errmsg)));
257 return 0;
258 }