Three items are addressed via this TD: revocation checking, and validation of ECC certificates.

Revocation methods do not include OCSP stapling or OCSP multi-stapling, limiting the functionality that could be evaluated. Adding these methods requires updates to the testing, as well. In addition, there are cases where certificates are short lived, or used in scenarios where revocation checking is not possible (e.g., when a network connection is not available at the time the certificate is intended to be validated).

Validation of certificates, if not done correctly, can introduce vulnerabilities (like CVE-2020-0601). Testing to ensure proper validation of Elliptic Curve Cryptography (ECC) certificates is lacking allowing spoofing attacks to exist in evaluated products.

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

This TD was superseded by TD 0742 on 23 August 2023.

This TD supersedes TD0526.

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

FIA_X509_EXT.1.1            The TSF shall validate certificates in accordance with the following rules:

• RFC 5280 certificate validation and certificate path validation

• The certificate path must terminate with a trusted certificate

• The TOE 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 TSF shall validate that any CA certificate includes caSigning purpose in the key usage field

• The TSF shall validate revocation status of the certificate using [selection: OCSP as specified in RFC6960, a CRL as specified in RFC8603, 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] with [selection: no exceptions, exceptions as specified in FIA_X509_EXT.4].

•  

• The TSF shall validate the extendedKeyUsage 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 extendedKeyUsage 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.

  • 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.

Application Note: This SFR must be included in the ST if the selection for FPT_TUD_EXT.1.3 is “digital signature mechanism,” or if the selection for FTP_ITC_EXT.1 includes “IPsec,” “TLS,” or “TLS/HTTPS.” If "certificate-based authentication of the remote peer" is selected in FTP_ITC_EXT.1.1, or if "authentication based on X.509 certificates" is selected in FIA_UAU.5.1.

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 IPsec; this use requires that the extendedKeyUsage rules are verified. Certificates may optionally be used for SSH, TLS, and HTTPs and, if implemented, must be validated to contain the corresponding extendedKeyUsage.

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. If OCSP is not supported the EKU provision for checking the OCSP Signing purpose is met by default.

Regardless of the selection of TSF or TOE platform, the validation is expected to end in a trusted root CA certificate in a root store managed by the platform.

If the TOE cannot perform revocation in accordance with one of the specified methods in FIA_X509_EXT.1.1, then "exceptions as specified in FIA_X509_EXT.4" should be chosen and FIA_X509_EXT.4 included in the ST.

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.

The evaluator shall examine the TSS to confirm that it describes the behavior of the TOE when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. If the requirement that the administrator is able to specify the default action, then the evaluator shall ensure that the operational guidance contains instructions on how this configuration action is performed.

TEST

The tests described must be performed in conjunction with the other Certificate Services assurance activities, including the use cases in FIA_X509_EXT.2.1. The tests for the extendedKeyUsage rules are performed in conjunction with the uses that require those rules.

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: (conditional, performed except for use cases identified in exceptions that cannot be configured to allow revocation) 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, and then a test is performed for each method. The evaluator has to only test one up in the trust chain (future revisions may require to ensure the validation is done up the entire chain). The evaluator shall ensure that a valid certificate is used, and that the validation function succeeds. The evaluator shall then attempt the test with a certificate that will be revoked (for each method chosen in the selection) and verify that the validation function fails.If the exceptions are configurable, the evaluator shall attempt to configure the exceptions to allow revocation checking for each function indicated in FIA_X509_EXT.2. 

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 5a: (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 5b: (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 5a 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 5a, 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.4 is a a selection-based SFR added as follows:

FIA_X509_EXT.4 Exceptions to X509 Certificate Revocation Checking

FIA_X509_EXT.4.1 The OS shall provide alternate functionality to standard X509 certificate revocation checking for the following exceptions: [selection: firmware checking of updates: invalidate automatic updates if the firmware certificate is compromised; [assignment: other exceptions and corresponding functionality]].

Evaluation Activity

The evaluator will ensure the TSS describes, for each exception, the alternate functionality the TOE implements to handle the lack of certificate revocation. The description must be consistent with the selection in the requirement.

TESTS

Test 1: For each exception, the evaluator shall configure the TSF as necessary to meet the exceptional condition described, and exercise the function using a certificate chain without revocation information. The evaluator shall attempt to examine TSF logging or behavior as described in the TSS to confirm the alternative action described is performed. For example, in the case of firmware updates that invalidate automatic updates, the evaluator shall invoke an automatic update and observe that the update is not performed. In other cases, the TSS describes the alternative action.

The new revocation methods and associated testing and the (conditional) test for ECC validation address gaps and help prevent exploitation of spoofing vulnerabilities.

 In cases where certificates are short lived, or used in scenarios where revocation checking is not possible (e.g., when a network connection is not available at the time the certificate is intended to be validated - especially when presence of a network connection introduces unacceptable risk), it is acceptable for the issuer to convey continued certificate validity information via other mechanisms, such as removing a certificate in the certificate validation chain from the trust-store or from certificate pinning mechanisms.

RFC5759 should be replaced with RFC8603 per RFC8423.