Clarification needed for FIA_X509_EXT.1 test case 4

[mclearn]

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.

[robertmclemons]

Sent this to the SME, the recommended solution was to add clarification to the AppNote and a small modification to the test. I'm including the entire response here for the record. (Red text has been replaced with bold due to the limitations of the github wiki markup format):

It’s fuzzy – RFC5280 only says that the extended key usage OCSP Signing purpose is compatible with key usage values of digital signature and/or non-repudiation; it does not include keyCertSign which is required in a CA certificate. As a result, RFC6960 says clients should check that the OSCP response is signed either by the CA that issued the certificate, or by a delegated certificate that asserts the OCSP signing purpose.

The question then is whether the CA certificate used to sign an OCSP response is actually an ‘OCSP certificate’ referred to in the SFR. An easy solution would be to say it is not. In this case, the test clarifies the SFR to say OCSP support must include support for delegated OCSP responders – in any client that must validate certificates issued by DoD or another large enterprise PKI, this is certainly a desired interpretation. It would be reasonable to clarify this via an application note:

OCSP responses are signed using either the certificate’s issuer’s CA certificate or an OCSP certificate issued to an OCSP responder delegated by that issuer to sign OCSP responses. A compliant TOE is able to validate OCSP responses in either case, but the OCSP signing extended key usage purpose is only required to be checked in OCSP certificates.

With this interpretation, the test becomes:

Test 4: If any OCSP option is selected, the evaluator shall configure the OCSP server using a delegated OCSP certificate or use a man-in-the-middle tool to present a delegated OCSP 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

The red (bold) strike-out indicates unnecessary constraints on the test environment and can be omitted, but I’m ok leaving it as is; the italicized text is inferred from the interpretation, and can be added if it helps.

I think the real objection is that the test is not a comprehensive check that any potential OCSP response is valid – I agree with that. I’ve been advocating for extensive revision of FIA_X509_EXT into a certificate verification package, both to provide uniformity and to deal with this and other assumptions/gaps.

[robertmclemons]

I'm leaving this issue open for the time being in case we want to make the same changes in other PPs. And also for reference in a future X509/Cert Auth package.