(superceded by TD0524)

The Protection Profile for Application Software Version 1.3 specifically calls out OCSP stapling in FIA_X509_EXT.1 X.509 Certificate Validation. However, OCSP stapling as a selection is missing from PP_MDM_v4.0.

FIA_X509_EXT.1(1)

FIA_X509_EXT.1.1(1) is modified as follows:

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 and that the CA flag is set to TRUE for all CA certificates.
• The TSF shall validate the revocation status of the certificate using [selection: the Online Certificate Status Protocol (OCSP) as specified in RFC 2560, a Certificate Revocation List (CRL) as specified in RFC 5280 Section 6.3, a Certificate Revocation List (CRL) as specified in RFC 5759 Section 5, an OCSP TLS Status Request Extension (i.e., OCSP stapling) as specified in RFC 6066].
• 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 extendedKeyUsage field.
• CSP 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 extendedKeyUsage 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 extendedKeyUsage field.

Application Note: FIA_X509_EXT.1.1(1) lists the rules for validating certificates. The ST author must select whether revocation status is verified using OCSP, OCSP stapling, 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.

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(1) Test 3 under "If "implement functionality" is selected:" is modified as follows, with underlines indicating additions:

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 multiple methods 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). 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.

FIA_X509_EXT.1.1(1) Test 4 under "If "implement functionality" is selected:" is modified as follows, with underlines indicating additions:

Test 4: If OCSP or OCSP stapling 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 Keyusage extension but does not have the cRLsign key usage bit set, and verify that validation of the CRL fails.

FIA_X509_EXT.2

The Application Note for FIA_X509_EXT.2.2 is modified as follows, with underlines indicating additions:

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.

See issue description.