The Network Interpretations Team (NIT) has issued a technical decision regarding Reference identifiers for TLS certificate checking in the NDcPP v1.0 and FW cPP v1.0.

To align with NIT interpretation # 201650, the following response applies:

The NIT endorses the NIAP response and gives the following additional response. Taking the three suggested contradictions in turn:

(1) Support for the SAN in reference identifiers and presented certificates is required for FCS_TLSC_EXT.1.2 & FCS_TLSC_EXT.2.2. Neither the SFR nor the TSS part of the Evaluation Activity present it as a selection, and optional support is only suggested by the TSS Evaluation Activity text in the context of support for application-specific SAN values.

(2) Support for the CN in reference identifiers and presented certificates is required for FCS_TLSC_EXT.1.2 & FCS_TLSC_EXT.2.2, as clarified in Application Notes 75 & 79. Neither the SFR nor the TSS part of the Evaluation Activity present it as a selection, and while the TSS Evaluation Activity includes it in a list of example types of reference identifiers this is not intended to suggest that it is optional. A wording clarification will be made as in ‘Further Action’ in Rfi201650.

(3) Application Notes 75 & 79 (for FCS_TLSC_EXT.1 and FCS_TLSC_EXT.2) state “[T]he client should avoid constructing reference identifiers using wildcards. However, if the presented identifiers include wildcards, the client must follow the best practices regarding matching; these best practices are captured in the assurance activity.” The “assurance activity” in this case is found in the Evaluation Activity in SD v1.0 sections 2.2.13 & 2.2.14.

In the TSS requirements in SD v1.0 sections 2.2.13.1 & 2.2.14.1 the text “The evaluator shall ensure that the TSS describes … whether … wildcards are supported” is interpreted as referring to the statement in Application Notes 75 & 79 that “[T]he client should avoid constructing reference identifiers using wildcards”. The tests in sections 2.2.13.3 & 2.2.14.3 examine the way the client responds when presented with server certificates that contain wildcards, which refers to the other part of the statement in Application Notes 75 & 79 that “if the presented identifiers include wildcards, the client must follow the best practices regarding matching; these best practices are captured in the assurance activity”. The difference is thus between use of wildcards in a reference identifier list that the TOE constructs (which is discouraged, but optional), and support for the use of wildcards in a certificate that is presented to the TOE (which is required).

Regarding IP addresses as identifiers in certificates: Application Notes 75 & 79 already state that “support for use of IP addresses in the Subject Name or Subject Alternative name is discouraged as against best practices but may be implemented”.

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

Rationale provided in https://www.niap-ccevs.org/Documents_and_Guidance/ccevs/NITDecisionRfi201650.pdf.