celic
commented
9 months ago Yes, we acknowledge this error. I have been discussing this with Joachim from atsec who let me know via email. This is an unintentional change and we are working to fix it. See the email to Prod users for more details on what happened.
Since a couple of days now, the ESV server shows a difference in behavior that broke our ESV client. Please consider the following steps of events in our client:
1) Register the entropy assessment 2) Upload the data files for processing 3) Upload the supporting documentation 4) Wait for data files to finish processing on server side 5) Submit certification
The NIST Python client performs the following steps - which do work:
1) Register the entropy assessment 2) Upload the data files for processing 3) Wait for data files to finish processing on server side 4) Upload the supporting documentation 5) Submit certification
For some reason, when step 3 and 4 are switched around, the certification breaks. On a technical level, the "sdType" of the EAR/PUD is somehow changed from its original value (submitted in step 3 of the proxy) to "Other". Then, in step 5, the ESV server checks this value and it errors.
I would like to bring that to your attention to ask to revert the change in the ESV server back that triggers this change. The reason for that is not so much a change to our client (which we now have), but rather it is a departure from the general ACVP (et al) protocol to allow any arbitrary order of events as long as they do not depend on each other. Further, I personally think that submitting data before or while waiting for the processing of data is more efficient. Thanks a lot.