The current draft of the module (as of 12/15/25) says that support for AES-CCMP is mandatory and support for AES-GCMP is optional. If this remains the case, then the FCS_COP.1/DataEncryption SFR in the NDcPP must be modified to mandate the CCM selection while leaving GCM (and everything else) as selectable.
However, the NDcPP now defines the crypto requirements as tables underneath the SFR, consistent with the CCDB crypto catalog. The general instruction of those SFRs is to present the table columns as assignments with instructions to the ST author to select the supported rows. But there is no practical way to mandate that one or more of the rows to be selected.
Since CCM is (currently) mandatory, the most correct thing to do would be to update FCS_COP.1/AEAD to force the selection of the CCM row, but there is no obvious way in the schema to do that. This is being opened as an issue as a note to ensure that the updated release is not published without some resolution of how (if at all) to address this in the Modified SFR language.
The current draft of the module (as of 12/15/25) says that support for AES-CCMP is mandatory and support for AES-GCMP is optional. If this remains the case, then the FCS_COP.1/DataEncryption SFR in the NDcPP must be modified to mandate the CCM selection while leaving GCM (and everything else) as selectable.
However, the NDcPP now defines the crypto requirements as tables underneath the SFR, consistent with the CCDB crypto catalog. The general instruction of those SFRs is to present the table columns as assignments with instructions to the ST author to select the supported rows. But there is no practical way to mandate that one or more of the rows to be selected.
Since CCM is (currently) mandatory, the most correct thing to do would be to update FCS_COP.1/AEAD to force the selection of the CCM row, but there is no obvious way in the schema to do that. This is being opened as an issue as a note to ensure that the updated release is not published without some resolution of how (if at all) to address this in the Modified SFR language.