Test Session API suggestion

[AlexThurston]

As a suggestion, it might be valuable/beneficial to provide an API or add the data within the existing API to get the algorithm capabilities that were used to create a test session.

If it were me, I'd say that a GET on the test session resource would provide this info. Currently it returns:

[
  {
    "acvVersion": "1.0"
  },
  {
    "url": "/acvp/v1/testSessions/<ID>",
    "vectorSetsUrl": "/acvp/v1/testSessions/<ID>/vectorSets",
    "status": "new"
  }
]

Maybe this could be:

[
  {
    "acvVersion": "1.0"
  },
  {
    "url": "/acvp/v1/testSessions/75731",
    "capabilities": <JSON ARRAY OF CAPABILITIES>,
    "vectorSetsUrl": "/acvp/v1/testSessions/75731/vectorSets",
    "status": "new"
  }
]

[smuellerDD]

Am Montag, 20. April 2020, 17:32:25 CEST schrieb Alex Thurston: Hi Alex,

As a suggestion, it might be valuable/beneficial to provide an API or add the data within the existing API to get the algorithm capabilities that were used to create a test session.

There is a way to get all cipher definitions using the "algorithms" endpoint.

If it were me, I'd say that a `GET` on the test session resource would provide this info. Currently it returns: ```json [ { "acvVersion": "1.0" }, { "url": "/acvp/v1/testSessions/<ID>", "vectorSetsUrl": "/acvp/v1/testSessions/<ID>/vectorSets", "status": "new" } ] ``` Maybe this could be: ```json [ { "acvVersion": "1.0" }, { "url": "/acvp/v1/testSessions/75731", "capabilities": <JSON ARRAY OF CAPABILITIES>, "vectorSetsUrl": "/acvp/v1/testSessions/75731/vectorSets", "status": "new" } ] ```

Ciao Stephan

[AlexThurston]

Sorry, maybe I wasn't clear. I'm not asking for a list of ALL the cipher definitions. I'm asking for the list of those that were provided to ACVP when a test session was created, (ie. the body of the POST)

[smuellerDD]

It just occurred to me that what you want is actually implemented, I think.

At the end of the publication phase when a cert is issued, the server returns a URL to fetch the certificate details (e.g. /acvp/v1/validations/). The data you get from there not only contains the cert ID but also all cipher options.

[AlexThurston]

Hey @smuellerDD, not quite. I'm asking for the ciphers used in a test session resource, not a validation resource.

[smuellerDD]

Am Donnerstag, 23. April 2020, 15:02:52 CEST schrieb Alex Thurston: Hi Alex,

Hey @smuellerDD, not quite. I'm asking for the ciphers used in a test session resource, not a validation resource.

Ok, but maybe that helps the NIST developers - the code seems to be there. Adding another RESTAPI endpoint for those may be cheap then. Ciao Stephan

[AlexThurston]

My thought here was that rather than a new endpoint, it could be added to the response body of the GET of /acvp/v1/testSessions/<ID> route.

[celic]

I understand. You are interested in the exact capabilities you registered for that vector set. Right now we expect the client to store that somewhere linked to the vsID. We will talk about this and see. It would not be a high priority though.

[AlexThurston]

Two years later, I thought I'd resurrect/bump this question to see if there was any thought or possibility in making this available. While the CAVP list does display what was algorithm capabilities were registered for the various OEs for a certificate, having access the the exact JSON that was registered when submitting for validation would be helpful in those situation where a vendor or lab does not have access to the originally registered algorithms sets. It's also worth noting that I also believe that the CAVP list webpage doesn't show ALL the fields for an algorithm. As an example, I think in the case of KAS-FFC, the noKDFnoKC field isn't displayed. I can't say for certain if there are others.

[livebe01]

Hi Alex, we don't have any plans for this right now.

I can see adding this capability for the scenario where someone has gotten a bit mixed up or has perhaps overwritten a file and wants to get back to the ground truth of what was registered for a given test session. But we don't have the cycles to implement this right now. The current expectation is that the clients and labs will be managing/saving/archiving this data in the spirit of Handbook 150-17 G.3.2.

The biggest challenge with what you're mentioning specifically is permissions on data. I don't think we want to get into transferring the ownership of data between users (from one lab to another).

Also, we show the fields that are relevant for the validation on the CAVP list. There are some fields that are kept internal because they aren't meant to be displayed, i.e., for readability. Displaying them would cause confusion for the reader.

[AlexThurston]

Thanks very much for the update.