NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
TD0524:  Updates to Certificate Revocation (FIA_X509_EXT.1)

Publication Date
2020.07.01

Protection Profiles
PP_MDM_V4.0

Other References
FIA_X509_EXT.1

Issue Description

(supercedes TD 467)

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.

 

Resolution

The following replaces the SFR, Application Note, and EA for FIA_X509_EXT.1.1(1) and FIA_X509_EXT.1.1(2).

FIA_X509_EXT.1.1(1)          The TSF 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 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 that any CA certificate includes caSigning purpose in the key usage field

  • The TSF 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, a CRL as specified in RFC 5759 Section 5, an OCSP TLS Status Request Extension (i.e., 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 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.

    • 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(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 trusted channels; this use requires that the extendedKeyUsage rules are verified.  Certificates may optionally be used to code signing and policy signing 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 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.

 

FIA_X509_EXT.1.1(2)          The TSF 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 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 that any CA certificate includes caSigning purpose in the key usage field

  • The TSF 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, a CRL as specified in RFC 5759 Section 5, an OCSP TLS Status Request Extension (i.e., OCSP stapling) as specified in RFC 6066, OCSP TLS Multi-Certificate Status Request Extension (i.e., OCSP Multi-Stapling) as specified in RFC 6961, no revocation method].

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

    • 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(2) should be chosen if the TOE is distributed and the protocol(s) selected in FPT_ITT.1(1) utilize X.509 certificates for peer authentication. In this case, the use of revocation list checking is optional as there are additional requirements surrounding the enabling and disabling of the ITT channel as defined in FCO_CPC_EXT.1. If revocation checking is not supported, the ST author should select 'no revocation method.' However, if certificate revocation checking is supported, the ST author selects whether this is performed using OCSP or CRLs.

This SFR 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 trusted channels; this use requires that the extendedKeyUsage rules are verified. Certificates may optionally be used for code signing and policy signing 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 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:

If invoke platform-provided functionality is selected:

TSS

The evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity.)

The TSS must describe when revocation checking is performed. It is expected that revocation checking is performed when a certificate is used in an authentication step. It is not sufficient to verify the status of an X.509 certificate only when it is loaded onto the device.

If implement funcationality is selected:

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 TSS must describe when revocation checking is performed. It is expected that revocation checking is performed when a certificate is used in an authentication step. It is not sufficient to verify the status of an X.509 certificate only when it is loaded onto the device.

TEST

The tests described must be performed in conjunction with the other certificate services evaluation activities, including each of 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. The evaluator shall create a chain of at least three certificates: the node certificate to be tested, an Intermediate CA, and the self-signed Root CA.

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, or OCSP stapling is selected; if both are selected, then a test shall be performed for each method. The evaluator shall test revocation of the node certificate and revocation of the intermediate CA certificate (i.e. the intermediate CA certificate should be revoked by the root CA). If OCSP stapling per RFC 6066 is the only supported revocation method, testing revocation of the intermediate CA certificate 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 OCSP option is selected, the evaluator shall send the TOE an OCSP response signed by 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 cause a CA to sign a CRL with a certificate that has a key usage extension but 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 Application Note is modified as follows:

Application Note: If a valid OCSP response is not provided by the server during a TLS handshake, to include when the TOE does not support OCSP stapling, a connection may need to be established to perform a verification of the revocation status of a certificate - either to download a current, valid CRL or to perform OCSP. The selection is used to describe the behavior in the event that such a connection cannot be established (for example, due to a network error). If the TOE has determined the certificate is valid according to all other rules in FIA_X509_EXT.1(1), the behavior indicated in the second selection must determine the validity. The TOE must not accept the certificate if it fails any of the other validation rules in FIA_X509_EXT.1(1) or if valid revocation information (a cached CRL, or recent or stapled OCSP response) indicates the certificate has been revoked. If the administrator-configured option is selected by the ST Author, the ST Author must also select function d in FMT_SMF.1(2).

If the TOE is distributed and FIA_X509_EXT.1(2) is selected, then certificate revocation checking is optional. This is due to additional authorization actions being performed in the enabling and disabling of the intra-TOE trusted channel as defined in FCO_CPC_EXT.1. In this case, a connection is not required to determine certificate validity and this SFR is trivially satisfied.

Justification

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

 
 
Site Map              Contact Us              Home