Clarification needed for FIA_X509_EXT.1 test case 4

Start with FIA_X509_EXT.1.1 and Test 4 in the assurance activities, then compare the proposed alternatives with RFC 6960 sections 4.2.2.2 and the cited RFC 6066 and RFC 6961 guidance. Done means the protection profile clearly defines supported OCSP trust models and makes the corresponding validation tests conditional where needed.

In the assurance activities, test 4 says the following:

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.

Based on RFC 6960, the OCSP signing purpose is only required when the OCSP response is signed by a delegate certificate (see section 4.2.2.2 of RFC 6960). It is entirely permissible to sign OCSP responses directly by the issuing CA certificate without requiring the OCSP signing bit be present. Therefore, the SFR and AA may need to be modified to either require that the delegate model be supported by the TOE (if that is NIAP's stance) or that delegates be considered optional.

Rewriting the SFR element FIA_X509_EXT.1.1 to include conditional use of OCSP delegates or OCSP responses signed directly by issuing CAs as an assertion is more difficult than expected. Here's a draft proposal which doesn't appear to be too wrong and tries to include all three of the possible OCSP response trust models.

Even if this proposal is too complex to include, perhaps modifying the AA (and the application note) to informally indicate that the OCSP signing EKU is only for delegated OCSP response signers would provide an avenue to ensure that other RFC-compliant means to validate signed responses are permitted.

_
Proposed changes that simply make the test case optional:
Test 4a: If any OCSP option is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present a delegated OCSP response signing certificate that does not have the OCSP signing purpose and verify that validation of the OCSP response fails. Regardless of the means by which OCSP is claimed, the definition of a "delegated OCSP response signing certificate" is found in RFC 6960 section 4.2.2.2. If delegated OCSP responses are not supported by the TOE, then this test shall be skipped.

Test 4b: 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.

_
Comprehensive change that seeks to more accurately formalize the applicable choices and tests:
FIA_X509_EXT.1.1
The TSF shall validate certificates in accordance with the following rules:
...
• The TSF shall validate revocation status of the certificate using [selection: OCSP [selection: as specified in RFC 6960, using OCSP TLS Status Request Extension (OCSP stapling) as specified in RFC 6066, using OCSP TLS Multi-Certificate Status Request Extension (i.e., OCSP Multi-Stapling) as specified in RFC 6961] having responses signed by [selection: delegated, issuing CA, locally configured OCSP signing authority] certificates, a CRL as specified in RFC 5759].
...
o OCSP delegate 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.

Evaluation Activities:
TSS:
...
If OCSP is selected, then the TSS author must summarize the rules around the OCSP response trust model.

Tests
...
Test 4a: [conditional if delegated OCSP response signing certificates are claimed] If any OCSP option is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present a delegated OCSP response signing certificate that does not have the OCSP signing purpose and verify that validation of the OCSP response fails.

Test 4b: [conditional if issuing CA OCSP response signing certificates are claimed] If any OCSP option is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present an OCSP response signing CA certificate (such that this certificate would be identified as a legitimate CA under other circumstances) that is not the same as the issuing CA and verify that validation of the OCSP response fails.

Test 4c: [conditional if locally configured OCSP signing authority certificates are claimed] If any OCSP option is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present an OCSP response signing certificate that fails to meet at least one locally configured OCSP signing authority rule and verify that validation of the OCSP response fails.

Test 4d: 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.

(Based on my reading of RFC 6066 (OCSP stapling) and RFC 6961 (OCSP Multi-stapling), there are no additional requirements above-and-beyond RFC 6960 with regards to delegate certificates and the OCSP signing EKU capability.)

_
Note that there is the potential for another OCSP test based on the RFC for delegates as per section 4.2.2.2 of RFC 6960:

Test 4e: [conditional if delegated OCSP response signing certificates are claimed] If any OCSP option is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present a delegated OCSP response signing certificate correctly having the OCSP signing purpose that is not issued directly (rather, indirectly) by the issuing CA and verify that validation of the OCSP response fails. The OCSP response should include the signing delegate's chain of certificates such that it would be conceivable to verify the chain of trust from the signing delegate certificate back up to the issuing CA. If such an arrangement is already permitted by claiming locally-configured signing authority rules, then this test shall be skipped.

Note, however, that test 4e may have some behavioural differences as per the discussion provided in RFC 6960 section 4.2.2.2 (bottom of page 16, top of page 17) and may introduce additional TRRTs if those edge cases arise.