A lack of clarity in the PP made it appear as if compliant TOEs were only required to check one of three possible scenarios that may be presented for EKU fields in certificates presented to the TOE by the server. This will be revisited in the next version of the PP.

FIA_X509_Ext.1/STIP in MOD_STIP_V1.1 is modified as follows, with green-highlighted underlines indicating additions and red-highlighted strikethroughs indicating deletions:

FIA_X509_EXT.1.1/STIP

The TSF shall validate certificates used for connections supporting STIP functions in accordance with the following rules:

• RFC 5280 certificate validation and certification path validation supporting a minimum path length of three certificates.
• The certification path must terminate with a trusted CA certificate designated as a trust anchor.
• The TSF shall validate a certification path by ensuring that all CA certificates in the certification path contain the basicConstraints extension with the CA flag set to TRUE.
• The TSF shall validate the revocation status of the certificate using [selection: the Online Certificate Status Protocol (OCSP) as specified in RFC 6960, a Certificate Revocation List (CRL) as specified in RFC 5280 Section 6.3, Certificate Revocation List (CRL) as specified in RFC 8603 ].
• The TSF shall validate the extendedKeyUsage field according to the following rules depending on the certificate type and purpose:
• Server certificates presented in a TLS certificate message for Thru-Traffic processing TLS shall have meet one of the following conditionschecks:

§  There is no extendedKeyUsage field

§  The extendedKeyUsage field is present and contains the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) and

§  [selection:

§  There is no extendedKeyUsage field,

§  The extendedKeyUsage field is present and contains the ‘any’ purpose (id-…),

§  No other conditions

].

• Server certificates presented for TLS not associated with the Thru-Traffic processing include an extendedKeyUsage field that contains the ServerAuthentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1).
• Code-signing certificates include the extendedKeyUsage field that contains the CodeSigning purpose.
• Client certificates presented for TLS for any purpose shall include the extendedKeyUsage field that contains the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage 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 extendedKeyUsage field.
• All other certificates used for any other purpose include an extendedKeyUsage field that DOES NOT contain the ‘any’ purpose.
• The TSF shall validate all extensions marked as critical and verify the value is appropriate for the functionality that uses the value.

The following is appended to the Application Note for FIA_X509_EXT.1/STIP:

It is highly recommended that the selection for extendedKeyUsage include both “There is no extendedKeyUsage field” and “The extendedKeyUsage field is present and contains the ‘any’ purpose” options to ensure the TOE is able to be used to inspect traffic to external servers that do not follow best practice certificate guidance. When either of these options is not supported, it is required that server certificates presented to the TOE that do not present supported features are considered invalid, and in accordance with FCS_TTTC_EXT.1.3, the inspected session is terminated, blocking access to such sites.

See Issue Description.