The intent of the relationship between FTP_DIT_EXT and FIA_X509_EXT SFRs needs clarity; currently, it is not clear whether these SFRs are applicable when platform-provided functionality is selected in FTP_DIT_EXT.1 or when the TOE is acting as a server with no mutual authentication.

Suite B Documents were moved to historical status (RFC 8423) and the Commercial National Security Algorithm (CNSA) Suite has replaced Suite B.

TD0587 created Client and Server iterations of FCS_HTTPS_EXT.1 and a new FCS_HTTPS_EXT.2. It mandated changes to the AppNote of FTP_DIT_EXT.1, but did not change the actual selection in DIT, which still refers to only the now non-existant FCS_HTTPS_EXT.1 requirement.

This TD supersedes TD0444, TD0473, TD0521 and TD0587.

Section 5.1.6

FTP_DIT_EXT.1.1 is replaced as follows:

FTP_DIT_EXT.1.1 The application shall [selection:

·         not transmit any [selection: data, sensitive data] ,

·         encrypt all transmitted [selection: sensitive data, data] with [selection: HTTPS  as a client in accordance with FCS_HTTPS_EXT.1/Client, HTTPS as a server in accordance with FCS_HTTPS_EXT.1/Server, HTTPS as a server with mutual authentication in accordance with FCSHTTPS_EXT.2, TLS as defined in the TLS Package, DTLS as defined in the TLS Package, SSH as conforming to the Extended Package for Secure Shell, IPsec as defined in the PP-Module for VPN Client],

·         invoke platform-provided functionality to encrypt all transmitted sensitive data with [selection: HTTPS, TLS, DTLS, SSH] ,

·         invoke platform-provided functionality to encrypt all transmitted data with [selection: HTTPS, TLS, DTLS, SSH]

] between itself and another trusted IT product.

Application Note: Encryption is not required for applications transmitting data that is not sensitive.

If encrypt all transmitted is selected and TLS is selected, then evaluation of elements from either FCS_TLSC_EXT.1 or FCS_TLSS_EXT.1 is required.

If encrypt all transmitted is selected, and HTTPS is selected, and the TOE acts as a client, FCS_HTTPS_EXT.1/Client is required. If encrypt all transmitted is selected, and HTTPS is selected, and the TOE acts as a server, FCS_HTTPS_EXT.1/Server is required. If the TOE acts as a server using mutual authentication, then FCS_HTTPS_EXT.2 is also required, and "mutual authentication" must be selected in the TLS Package.

If encrypt all transmitted is selected and DTLS is selected, FCS_DTLS_EXT.1 is required.

If encrypt all transmitted is selected and SSH is selected, the TSF shall be validated against the Extended Package for Secure Shell.

If encrypt all transmitted is selected and IPsec is selected, the TSF must claim conformance to a PP-Configuration that includes the VPN Client PP-Module.

If encrypt all transmitted is selected the corresponding FCS_COP.1 requirements will be included.

In addition to the above, FIA_X509_EXT.1 and FIA_X509_EXT.2 are required when the following is true:

- encrypt all transmitted is selected and the TOE implements a protocol that requires certificates

- invoke platform-provided functionality to encrypt all transmitted sensitive data is selected and the platform implements a protocol that requires certificates

- invoke platform-provided functionality to encrypt all transmitted data is selected and the platform implements a protocol that requires certificates

Note: FIA_X509_EXT.1 and FIA_X509_EXT.2 are not applicable when the TOE acts as a HTTPS/TLS server with no mutual authentication.

Evaluation Activity:

TSS

For platform-provided functionality, the evaluator shall verify the TSS contains the calls to the platform that TOE is leveraging to invoke the functionality.

Guidance

None.

Tests

The evaluator shall perform the following tests.

·         Test 1: The evaluator shall exercise the application (attempting to transmit data; for example by connecting to remote systems or websites) while capturing packets from the application. The evaluator shall verify from the packet capture that the traffic is encrypted with HTTPS, TLS, DTLS, SSH, or IPsec in accordance with the selection in the ST.

·         Test 2: The evaluator shall exercise the application (attempting to transmit data; for example by connecting to remote systems or websites) while capturing packets from the application. The evaluator shall review the packet capture and verify that no sensitive data is transmitted in the clear.

·         Test 3: The evaluator shall inspect the TSS to determine if user credentials are transmitted. If credentials are transmitted the evaluator shall set the credential to a known value. The evaluator shall capture packets from the application while causing credentials to be transmitted as described in the TSS. The evaluator shall perform a string search of the captured network packets and verify that the plaintext credential previously set by the evaluator is not found.

For Android: If "not transmit any data" is selected, the evaluator shall ensure that the application's AndroidManifest.xml file does not contain a uses-permission or uses-permission-sdk-23 tag containing android:name="android.permission.INTERNET". In this case, it is not necessary to perform the above Tests 1, 2, or 3, as the platform will not allow the application to perform any network communication.

For iOS: If "encrypt all transmitted data" is selected, the evaluator shall ensure that the application's Info.plist file does not contain the NSAllowsArbitraryLoads or NSExceptionAllowsInsecureHTTPLoads keys, as these keys disable iOS's Application Transport Security feature.

Appendix B

FCS_HTTPS_EXT.1 is rewritten as follows:

FCS_HTTPS_EXT.1/Client HTTPS Protocol

This selection-based component depends upon selection in FTP_DIT_EXT.1.1.

FCS_HTTPS_EXT.1.1/Client The application shall implement the HTTPS protocol that complies with RFC 2818.

Evaluation Activity

TSS

The evaluator shall examine the TSS and determine that enough detail is provided to explain how the implementation complies with RFC 2818.

Guidance
None.
Tests
The evaluator shall attempt to establish an HTTPS connection with a webserver, observe the traffic with a packet analyzer, and verify that the connection succeeds and that the traffic is identified as TLS or HTTPS.

FCS_HTTPS_EXT.1.2/Client The application shall implement HTTPS using TLS as defined in the TLS package.

Evaluation Activity

TSS
None.
Guidance
None.
Tests
Other tests are performed in conjunction with the TLS package.

FCS_HTTPS_EXT.1.3/Client The application shall [selection: not establish the application-initiated connection, notify the user and not establish the user-initiated connection , notify the user and request authorization to establish the user-initiated connection ] if the peer certificate is deemed invalid.

Application Note: Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280.

Evaluation Activity

TSS
None.
Guidance
None.
Tests
Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1, and the evaluator shall perform the following test:

• Test 1: The evaluator shall demonstrate that using a certificate without a valid certification path results in the selected action in the SFR. If "notify the user" isselected in the SFR, then the evaluator shall also determine that the user isnotified of the certificate validation failure. Using the administrative guidance, the evaluator shall then load a certificate or certificates to the Trust Anchor Database needed to validate the certificate to be used in the function, and demonstrate that the function succeeds. The evaluator then shall delete one of the certificates, and show that again, using a certificate without a valid certification path results in the selected action in the SFR, and if "notify the user" was selected in the SFR, the user is notified of the validation failure.

FCS_HTTPS_EXT.1/Server HTTPS Protocol

This selection-based component depends upon selection in FTP_DIT_EXT.1.1.

FCS_HTTPS_EXT.1.1/Server The application shall implement the HTTPS protocol that complies with RFC 2818.

Evaluation Activity

TSS

The evaluator shall examine the TSS and determine that enough detail is provided to explain how the implementation complies with RFC 2818.

Guidance
None.
Tests
The evaluator shall attempt to establish an HTTPS connection to the TOE using a client, observe the traffic with a packet analyzer, and verify that the connection succeeds and that the traffic is identified as TLS or HTTPS.

FCS_HTTPS_EXT.1.2/Server The application shall implement HTTPS using TLS as defined in the TLS package.

Evaluation Activity

TSS
None.
Guidance
None.
Tests
Other tests are performed in conjunction with the TLS package.

A new SFR, FCS_HTTPS_EXT.2, is added as follows:

FCS_HTTPS_EXT.2 HTTPS Protocol with Mutual Authentication

This selection-based component depends upon selection in FTP_DIT_EXT.1.1.

FCS_HTTPS_EXT.2.1 The application shall [selection: not establish the connection, establish or not establish the connection based on an administrative or user setting] if the peer certificate is deemed invalid.

Application Note: Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280.

TSS
None.
Guidance
None.
Tests
Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1, and the evaluator shall perform the following test:

• Test 1: The evaluator shall demonstrate that using a certificate without a valid certification path results in the selected action in the SFR. Using the administrative guidance, the evaluator shall then load a certificate or certificates to the Trust Anchor Database needed to validate the certificate to be used in the function, and demonstrate that the function succeeds. The evaluator then shall delete one of the certificates, and show that again, using a certificate without a valid certification path results in the selected action in the SFR.

The following replaces the SFR, Application Note, and Test EA for FIA_X509_EXT.1.1.

FIA_X509_EXT.1.1            The application shall [selection: invoke platform provided functionality, implement functionality] to validate certificates in accordance with the following rules:

• RFC 5280 certificate validation and certificate path validation
• The certificate path must terminate with a trusted CA certificate
• The application shall validate a certificate path by ensuring the presence of the basicConstraints extension, that the CA flag is set to TRUE for all CA certificates, and that any path constraints are met
• The application shall validate that any CA certificate includes caSigning purpose in the key usage field
• The application shall validate the revocation status of the certificate using [selection: OCSP as specified in RFC 6960, CRL as specified in RFC 5280 Section 6.3, CRL as specified in RFC 8603, an OCSP TLS Status Request Extension (OCSP stapling) as specified in RFC 6066, OCSP TLS Multi-Certificate Status Request Extension (i.e., OCSP Multi-Stapling) as specified in RFC 6961]
• The application shall validate the extendedKeyUsage (EKU) field according to the following rules:
• Certificates used for trusted updates and executable code integrity verification shall have the Code Signing Purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field.
• Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the EKU field.
• Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the EKU field.
• S/MIME certificates presented for email encryption and signature shall have the Email Protection purpose (id-kp 4 with OID 1.3.6.1.5.5.7.3.4) in the EKU field.
• OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the EKU field.
• Server certificates presented for EST shall have the CMC Registration Authority (RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in the EKU field.

Application Note: FIA_X509_EXT.1.1 lists the rules for validating certificates. The ST author shall select whether revocation status is verified using OCSP or CRLs. FIA_X509_EXT.2 requires that certificates are used for HTTPS, TLS, and DTLS; this use requires that the extendedKeyUsage rules are verified.  If OCSP is not supported the EKU provision for checking the OCSP Signing purpose is met by default.

This requirement is included if the protocol(s) selected in FTP_DIT_EXT.1.1 require the use of certificates. If the TOE implements TLS as a HTTPS/TLS server with no mutual authentication, this requirement is not applicable.

OCSP stapling and OCSP multi-stapling only support TLS server certificate validation. If other certificate types are validated, either OCSP or CRL should be claimed.

Regardless of the selection of implement functionality or invoke platform-provided functionality, the validation is expected to end in a trusted root CA certificate in a root store managed by the platform.

Evaluation Activities:

TSS

The evaluator shall ensure the TSS describes where the check of validity of the certificates takes place. The evaluator ensures the TSS also provides a description of the certificate path validation algorithm.

Test

The tests described must be performed in conjunction with the other certificate services evaluation activities, including the functions in FIA_X509_EXT.2.1. The tests for the extendedKeyUsage rules are performed in conjunction with the uses that require those rules. If the application supports chains of length four or greater, the evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. If the application supports a maximum trust depth of two, then a chain with no Intermediate CA should instead be created.

Test 1: The evaluator shall demonstrate that validating a certificate without a valid certification path results in the function failing, for each of the following reasons, in turn:

• by establishing a certificate path in which one of the issuing certificates is not a CA certificate,
• by omitting the basicConstraints field in one of the issuing certificates,
• by setting the basicConstraints field in an issuing certificate to have CA=False,
• by omitting the CA signing bit of the key usage field in an issuing certificate, and
• by setting the path length field of a valid CA field to a value strictly less than the certificate path.

The evaluator shall then establish a valid certificate path consisting of valid CA certificates, and demonstrate that the function succeeds. The evaluator shall then remove trust in one of the CA certificates, and show that the function fails.

Test 2: The evaluator shall demonstrate that validating an expired certificate results in the function failing.

Test 3: The evaluator shall test that the TOE can properly handle revoked certificates-“conditional on whether CRL, OCSP, OCSP Stapling or OCSP Multi-stapling is selected; if multiple methods are selected, then the following tests shall be performed for each method:

The evaluator shall test revocation of the node certificate.

The evaluator shall also test revocation of an intermediate CA certificate (i.e. the intermediate CA certificate should be revoked by the root CA), if intermediate CA certificates are supported. If OCSP stapling per RFC 6066 is the only supported revocation method, this test is omitted.

The evaluator shall ensure that a valid certificate is used, and that the validation function succeeds. The evaluator then attempts the test with a certificate that has been revoked (for each method chosen in the selection) to ensure when the certificate is no longer valid that the validation function fails.

Test 4: If any OCSP option is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present a certificate that does not have the OCSP signing purpose and verify that validation of the OCSP response fails. If CRL is selected, the evaluator shall configure the CA to sign a CRL with a certificate that does not have the cRLsign key usage bit set, and verify that validation of the CRL fails.

Test 5: The evaluator shall modify any byte in the first eight bytes of the certificate and demonstrate that the certificate fails to validate. (The certificate will fail to parse correctly.)

Test 6: The evaluator shall modify any byte in the last byte of the certificate and demonstrate that the certificate fails to validate. (The signature on the certificate will not validate.)

Test 7: The evaluator shall modify any byte in the public key of the certificate and demonstrate that the certificate fails to validate. (The signature on the certificate will not validate.)

Test 8a: (Conditional on support for EC certificates as indicated in FCS_COP.1(3)). The evaluator shall establish a valid, trusted certificate chain consisting of an EC leaf certificate, an EC Intermediate CA certificate not designated as a trust anchor, and an EC certificate designated as a trusted anchor, where the elliptic curve parameters are specified as a named curve. The evaluator shall confirm that the TOE validates the certificate chain.

Test 8b: (Conditional on support for EC certificates as indicated in FCS_COP.1(3)). The evaluator shall replace the intermediate certificate in the certificate chain for Test 8a with a modified certificate, where the modified intermediate CA has a public key information field where the EC parameters uses an explicit format version of the Elliptic Curve parameters in the public key information field of the intermediate CA certificate from Test 8a, and the modified Intermediate CA certificate is signed by the trusted EC root CA, but having no other changes. The evaluator shall confirm the TOE treats the certificate as invalid.

FIA_X509_EXT.2.1 is replaced as follows:

FIA_X509_EXT.2.1 The application shall use X.509v3 certificates as defined by RFC 5280 to support authentication for [selection: HTTPS , TLS , DTLS, SSH, IPsec ].

Application Note: This requirement is included if the protocol(s) selected in FTP_DIT_EXT.1.1 require the use of certificates to authenticate the remote entity. For example, if the TOE or platform implements TLS as a HTTPS/TLS server with no mutual authentication, X509 authentication is not claimed for TLS. If the TOE or platform operates as a TLS client, X509 authentication must be claimed.

There is no change to the Evaluation Activity.

The intent is that the FIA_X509_EXT SFRs are required when the protocols that require certificates are selected in FTP_DIT_EXT - as described in the FIA_X509_EXT.1 application note.

When the TOE is acting as a HTTPS/TLS Server with no mutual authentication functionality the X509 SFRs do not apply for TLS. TD0473 doesn't require mutual authentication for HTTPS - now has HTTPS server and HTTPS client. Therefore, if the appropriate selections are made to not do mutual authentication on the server side, then  X509 SFRs are not required for HTTPS.

 If TOE is acting as HTTPS/TLS Server with mutual authentication, then X509 SFRs apply.

All other TOEs  either implementing or invoking platform-functionality, using a protocol that uses certifcates, must include the X509 SFRs.

RFC5759 should be replaced with RFC8603 per RFC8423.