Provide a Mechanism to Correlate CSRC Validation ID with ACVP Validation ID

[AlexThurston]

Some context for this issue can be traced to #919

The idea being that as time passes and potentially different labs are involved in certifications, it's possible that the re-use of certain resources is required: module, OE, Vendor. Currently the only way to "search" existing certificates is through https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/details?validation=31757 which only shows the CSRC ID (A35) for example. From that, to get the ACVP OE and Module that was used to build that certificate, I would have to somehow know the ACVP ID. In this case, it happens to appear in the URL (ie. 31757) but this doesn't appear to always be the case.

@celic mentioned in the aforementioned issue that there are two separate systems at play and synchronizing the two of them is somewhat onerous.

The use case I'm thinking of could be solved in one of two ways. The first would be to display the ACVP validation Id that was used to produce the entry on the CSRC site. That would allow users to get the ACVP validation ID and read its meta data.

Alternatively, since it appears as the the CSRC ID is stored within the validation record, simply allow for the standard query GET to work.

[
  {
    "acvVersion": "1.0"
  },
  {
    "url": "/acvp/v1/validations/31757",
    "validationId": "A35"
  }
]

GET validationID[0]=contains:A35

[shaneshaffer]

Validations on CSRC can be accessed 3 ways

1. details?validation=31757 - this is a single validation, and is what you get when you click on the value in the Validation Number column in the search results.
2. details?product=1234 - This is all the validations for the implementation, and is what you get when you click on the (soon to be renamed) Product column in the search results, or the Product Name value on the details display. Ideally we'll only ever have 1 validation per implementation, but implementations that were previously tested in CAVS and have since been tested with ACVTS, or were tested with CAVS before December 2018 may have multiple validations.
3. details?source=A&number=35 - This is sort of an undocumented way to get to a validation on CSRC

So depending on how you navigated to a validation, you may or may not have the validation ID. As we're working on a CSRC revision now we'll make sure to make any instance of the "A35" style validation number drill down using the validation ID, so then any way you navigate the ID will be no more than a hover away.

That said, we'll consider adding support for that style of parameter on the ACVTS validation endpoint.

BTW, the response from that validation endpoint in the Demo environment now includes the module url and OE urls.

[AlexThurston]

So depending on how you navigated to a validation, you may or may not have the validation ID. As we're working on a CSRC revision now we'll make sure to make any instance of the "A35" style validation number drill down using the validation ID, so then any way you navigate the ID will be no more than a hover away.

This is perfect.

That said, we'll consider adding support for that style of parameter on the ACVTS validation endpoint.

This would also be perfect.

BTW, the response from that validation endpoint in the Demo environment now includes the module url and OE urls.

I saw. Looks great to me.

Thanks - as always @shaneshaffer. Do you want me to leave this open so that you can close it when there is some action on the above two things being worked on.

[Kritner]

this change is now on production https://github.com/usnistgov/ACVP-Server/releases/tag/v1.1.0.12