The NIT acknowledges the issue described in the 'Issue' section but regards the proposed change as major change that should be performed in a future version of the NDcPP. In particular since FMT_MTD.1/CryptoKeys should be shifted to the selection-based SFR section of the NDcPP when there is an explicit selection in FMT_SMF.1. As an intermediate resolution the following changes shall be performed:

NDcPP V2.0e, FWcPP V2.0e, FAU_GEN.1, Application Note 1

The following paragraphs shall be added to Application Note 1:

"The requirement to audit the "Generating/import of, changing, or deleting of cryptographic keys" refers to all types of cryptographic keys which are intended to be used longer than for just one session (i.e. it does not refer to ephemeral keys/session keys). The requirement applies to all named changes independently from how they are invoked. A cryptographic key could e.g. be generated automatically during initial start-up without administrator intervention or through administrator intervention. This requirement also applies to the management of cryptographic keys by adding, replacing or removing trust anchors in the TOE's trust store. In all related cases the changes to cryptographic keys need to be audited together with a unique key name, key reference or unique identifier for the corresponding certificate."

NDcPP V2.0e, FWcPP V2.0e, FAU_GEN.1, Application Note 2

The following paragraph shall be deleted from Application Note 2:

"The TSS should identify what information is logged to identify the relevant key for the administrative task of generating/import of, changing, or deleting of cryptographic keys."

For further information, please see the NIT interpretation at: https://www.niap-ccevs.org/Documents_and_Guidance/ccevs/NITDecisionRfI201802.pdf

All changes to persistent cryptographic keys need to be audited. All affected keys need to be uniquely identified in the audit log.

Changes to temporary keys like ephemeral keys/session keys don't need to be audited since related events that need to be audited are explicitly defined for the related SFRs (e.g. FTP_ITC.1, FTP_TRP.1, FCS_*).

The updated application note is intended to clarify the focus of the audit requirement which not only applies to active and direct administrator intervention but also to automated key generation as well as key management through administration of X.509 certificates. It is expected that all TOEs compliant with the cPP should be capable of some sort of key management within the clarified scope. Therefore the audit requirement has been kept 'as-is' as a general mandatory requirement.