The NIT has issued a technical decision for Key Pair Generation for Authentication.

The TOE must be able to generate asymmetric keys (public/private key pairs) for each FCS_CKM.1 selection made by the ST author. In FCS_CKM.1 the ST author must select all the key generation schemes necessary to cover all protocols selected in FTP_ITC.1, FTP_TRP.1/Admin, FTP_TRP.1/Join, and FPT_ITT.1 that depend on the TOE containing an asymmetric key pair (e.g. not needed for a D/TLS client that is not supporting mutual authentication).

Wherever asymmetric keys are used for any trusted path/channel using any protocol, the TOE must be able to use keys (public and private) generated by the TOE. While the TOE may also optionally support using keys generated by a non-TOE entity, defining secure key injection functionality is outside the scope of this cPP.

In NDcPPv2.2e, Table 1 footnote 4 shall be replaced as follows:

The overall TOE is required to support on-board key generation and (if the TOE uses X.509 certificates as in Appendix B.4.1) RFC 2986 Certificate Request generation. If not all TOE components are supporting on-board key generation (and generation of certificate requests, where applicable), the TOE shall support distribution of keys to the TOE components that are not supporting key generation themselves. Depending on the life-cycle phase, either a secure registration channel shall be used for key distribution at the point where the component is joined to the TOE or an inter-component secure channel shall be used for key distribution post-registration.

For further information, please see NIT Interpretation at:  https://www.niap-ccevs.org/Documents_and_Guidance/ccevs/NITDecisionRFI202101.pdf

See Issue Description.