iTC Meeting Minutes 2024 09 12 - DSC-iTC/cPP GitHub Wiki
Call started at 12:02pm EDT
The started with a status update. Brian said he posted the documents as planned and asked NIAP to send out notifications. The end date will then start the final update period which should be accomplished in time for the ICCC. This could be changed if a lot of comments are submitted, but seems unlikely.
The call then moved on to open pull requests.
Brian noted that Publication Date was prepared for when the docs are ready to be published. He stated that he didn’t expect many comments in the final round and that this would then be merged to update all the dates in the 2 docs.
The only other pull request is tagged for v3 and so not discussed.
The only open issue tagged to the v2.0 release is FCS_CKM.5 EAs. This was discussed and it was determined that due to the number of variations in the supported algorithms that some additional clarity is needed on the steps for one of the algorithm types. There was some further discussion between FCS_CKM.5 and FCS_CKM_EXT.7 where there could be some updates to better simplify the SFRs, but this will be left to the Crypto WG to work out. Joachim will propose a pull request to add the clarification for what is needed now that will be merged as part of the final update.
Brian then reviewed the v2.0 Project. Other than the publication date PR and the FCS_CKM.5 issue there are no other issues remaining.
Brian then turned the discussion to the next steps after the publication of the v2.0.
His general proposal is to review the cPP along with PP_MDF, GPOS and GPCP and try to come up with a minimal DSC set of requirements that make up what those PPs may need. The goal is more like a minimum viable product set for the requirements, and use that as the basis for creating a set of requirements that may be able to be used with those evaluations (as opposed to requiring a full evaluation on its own).
There was a lot of discussion about the specific method for doing this. Brian wants to keep the documents together in such a way that this minimal set can be used in its entirety as a starting point for v3, with the possibility of then having modules for other components. There was a debate about whether this set needs to be a Package as the intent is to not allow a certification of a product using this minimal set in a stand-alone method, it could only be used as part of a larger evaluation. The issue Brian pointed out with a package is that it would mean it probably needs to be duplicated for use in the main DSC set of requirements, leading to a lot of extra overhead in the maintenance. This may be required, but some combination of requirements and modules may work. At the moment though the goal is to figure out what the requirements would be, not the packaging.
A big question was would this lead to vendors skipping the use of the main cPP. Brian thought that not doing it may lead to NIAP writing the requirements they want/need anyway, regardless of whether the cPP is used, so it is not going to be clear what the right way to go is, but that we do need to have something like this being worked on. His goal would be to use this lite version as the basis for v3.0 changes in some manner, and consider if the remaining requirements would be best separated into PP-Modules to allow for better separation and cohesion for future use.
The next call may be canceled depending on whether any feedback is submitted over the next 2 weeks.
Calls by January may move to every 4 weeks while working on the plans for the DSC-lite.
The call ended at 1:01pm EDT.