The published STIP module referenced FCS_CKM.1 in the NDcPP as the basis for how public keys are generated. However, the latest version of the NDcPP now restricts key generation strictly to CNSA compliant algorithms. Since the STIP module deliberately requires non-CNSA TLS ciphers to be supported, would this imply that key generation algorithms not conformant to CNSA would be needed (e.g. 2048-bit RSA)?
If so, a STIP specific iteration of FCS_CKM.1 would need to be defined in the module, similar to how a STIP-specific iteration of FCS_COP was defined for obsolete symmetric key algorithms.
Regardless of how this is handled, FDP_CER_EXT.1.4/Server will need to be updated to specifically tie the mechanism used to generate the subject public key to a specific SFR.
The published STIP module referenced FCS_CKM.1 in the NDcPP as the basis for how public keys are generated. However, the latest version of the NDcPP now restricts key generation strictly to CNSA compliant algorithms. Since the STIP module deliberately requires non-CNSA TLS ciphers to be supported, would this imply that key generation algorithms not conformant to CNSA would be needed (e.g. 2048-bit RSA)?
If so, a STIP specific iteration of FCS_CKM.1 would need to be defined in the module, similar to how a STIP-specific iteration of FCS_COP was defined for obsolete symmetric key algorithms.
Regardless of how this is handled, FDP_CER_EXT.1.4/Server will need to be updated to specifically tie the mechanism used to generate the subject public key to a specific SFR.