iTC Meeting Minutes 2024 08 15 - DSC-iTC/cPP GitHub Wiki
Call started at 12:02pm EDT
The call started with a review of the open pull requests. Two pull requests had already been approved. These were reviewed quickly and merged (with one live edit to FCS_CKM.2 changes).
The call then moved to dependency updates. There are several questions about exactly how to note changes to the dependencies since the requirements with the changes are not Extended and so don’t have a definition of the dependencies defined anywhere in the document except this table. The update includes dependencies that are from the crypto catalog and CC:2022 (as they don’t always match). It seems that maybe anything that is not defined in the CC:2022 should have a sentence description. It was discussed to reference the catalog for the dependencies, but since it isn’t published yet, it isn’t possible to add the reference at this point.
The rest of the call then discussed the proposed crypto EA. Several comments were added about how to handle the test requirements. The general agreement is that as much as possible the real answer here is that the evaluator needs to follow the scheme requirements for how to evaluate the algorithms. The exact mechanism for that isn’t well-defined; Brian couldn’t think of any SD he had seen that said "ask the scheme how to do this" so something has to be written.
Bob has been working on this for the crypto WG, with a slimmed down version of the testing requirements (basically a high level overview of the requirements for each algorithm). Brian said this could work, but thought that would take a long time and it wasn’t clear about some of the APAC algorithms as to how those would be written (not to mention all the variants of things like AES or SHA and the sheer number of algorithms and modes in the catalog). Brian’s approach was to create high level test requirements that laid out expectations as to what would be included in the test and then let the lab/scheme fill in the details for the algorithms claimed in the ST.
It was pointed out that the current proposal only covers a KAT and that there are some other types of tests that need to be included (such as Monte Carlo tests). Joachim said he would look at other NIST ACVP tests to get an idea of how many tests were required for a variety of algorithms as well as to come up with other broad categories of tests. Brian said the goal would be to write maybe 4-6 total types of tests that would be able to be used across different types of algorithms and then to plug those test instructions in where needed based on the type of algorithm, not the specific algorithm in question. Brian’s approach is to have slightly more detailed expectations about what should be included in the test vectors to be tested, but nothing specific to the algorithms. This approach is likely to be the one used for this iteration of the DSC if only because it provides a method for providing evaluation activities that can be written in the timeframe left to meet the November publication target.
The call ended at 1:03pm EDT.