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

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.

01/25/2021 - Fixed typo in SFR (id-dp replaced with id-kp)

Updated 10/16/2020 wrt delegated OCSP signers

FIA_X509_EXT.1.1  The TSF shall [selection: validate, interface with the OE to validate] certificates in accordance with the following rules:

• IETF RFC 5280 certificate validation and certificate path validation.

• The certificate path must terminate with a certificate in the Trust Anchor Database.

• The TSF 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 the revocation status of the certificate using [selection: OCSP as specified in RFC 6960, CRL as specified in RFC 5280 and refined by RFC 8603, an OCSP TLS Status Request Extension (i.e., OCSP stapling) as specified in RFC 6066, an OCSP TLS Multi-Certificate Status Request Extension (i.e., OCSP Multi-stapling) as specified in RFC 6961].

• The TSF shall validate the extendedKeyUsage (EKU) field according to the following rules:

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

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

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

o Delegated OCSP signer’s 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.

o 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: The TSF may rely on the Operational Environment to perform certificate handling functionality in cases where the TOE relies on an environmental component to provide trusted remote communications.

FIA_X509_EXT.1 lists the rules for validating certificates. The ST author shall select whether revocation status is verified using OCSP or CRLs. 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. 

Certificates may optionally be used for trusted updates of TSF Software (FPT_TUD_EXT.1) and for data/software integrity verification (FPT_TST_EXT.2) and, if implemented, must be validated to contain the Code Signing purpose extendedKeyUsage.

Whenever TLS or HTTPS is used by the TSF to protect communications originating from external IT entities, certificates used to perform authentication must be validated to contain the Client Authentication purpose extendedKeyUsage.

Whenever the TOE originates messaging to external IT services using TLS or HTTPS, certificates must be used to perform the authentication and must be validated to contain the Server Authentication purpose extendedKeyUsage.

When OCSP is used for certificate validation, the response is signed either by the CA that issued the certificate in the request, or by a CA delegated by the signing CA to issue OCSP responses on its behalf (a delegated OSCP signer). Only delegated OCSP signers are required to have the OCSP signing purpose in the EKU.

If OCSP or EST are not supported validating the EKU purpose is met by default.

It should be noted that in all cases, the validation is expected to end in a trusted root certificate.

Evaluation Activities:

TSS

The evaluator shall examine the TSS to ensure it describes where the check of validity of the certificates takes place. The evaluator shall ensure the TSS also provides a description of the certificate path validation algorithm for each certificate format supported by the TOE.

TEST

The evaluator shall perform the following tests 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 anywhere in a certificate path 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, 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.

Test 4: If any OCSP option is selected, the evaluator shall configure a delegated OCSP server to use a certificate that does not have the OCSP signing purpose to sign a valid response, 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 a single byte in the certificate and verify that the certificate fails to validate.

Test 6a: (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 6b: (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 6a 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 6a, 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.

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