Archived
TD0669: FIA_X509_EXT.1 Test 4 Interpretation
Publication Date
2022.09.23
Protection Profiles
PP_APP_v1.4
Other References
FIA_X509_EXT.1.1
Issue Description
FIA_X509_EXT.1 Test 4 in App PP 1.4 requires testing the behavior of the TOE in the event that the CA signing the CRL or OCSP responder certificate contains the proper extendedKeyUsage attributes and requires that the OCSP or CRL validation fails. The intent of the test however is somewhat ambiguous as to how the TOE should handle the validation error. Resolution
This TD has been superseded by TD0780 and is archived as of 30 August, 2023. The following modifications are made to the FIA_X509_EXT.1.1 Evaluation Activities in Section B.2 of PP_APP_v1.4, with strikethroughs denoting deletion and underlines denoting additions: Evaluation Activities FIA_X509_EXT.1.1
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.
Guidance
None.
Tests
The tests described must be performed in conjunction with the other certificate services evaluation
activities, including 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. If the application supports chains of
length four or greater, the evaluator shall create a chain of at least four certificates: the node
certificate to be tested, two Intermediate CAs, and the self-signed Root CA. If the application supports
a maximum trust depth of two, then a chain with no Intermediate CA should instead be created.
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, OCSP Stapling or OCSP Multi-stapling is
selected; if multiple methods are selected, then the following tests shall be performed for each
method:
- The evaluator shall test revocation of the node certificate.
- The evaluator shall also test revocation of an intermediate CA certificate (i.e. the
intermediate CA certificate should be revoked by the root CA), if intermediate CA
certificates are supported. If OCSP stapling per RFC 6066 is the only supported
revocation method, this test 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 any OCSP option is selected, the evaluator shall ensure the TSF has no other source of
revocation information available and configure the OCSP server or use a man-in-the-middle tool
to present an OCSP response signed by a certificate that does not have the OCSP signing purpose
and which is the only source of revocation status information advertised by the CA issuing the
certificate being validated. The evaluator shall verify that validation of the OCSP
response fails and that the TOE treats the certificate being checked as invalid and rejects the
connection. If CRL is selected, the evaluator shall likewise configure the CA to be the only source
of revocation status information, and sign a CRL with a certificate that does not have the cRLsign key usage bit
set, and . The evaluator shall verify that validation of the CRL fails and that the TOE treats the certificate
being checked as invalid and rejects the connection.
Note: The intent of this test is to ensure a TSF does not trust invalid revocation status information. A TSF
receiving invalid revocation status information from the only advertised certificate status provider should
treat the certificate whose status is being checked as invalid. This should generally be treated differently
from the case where the TSF is not able to establish a connection to check revocation status information,
but it is acceptable that the TSF ignore any invalid information and attempt to find another source of
revocation status (another advertised provider, a locally configured provider, or cached information) and
treat this situation as not having a connection to a valid certificate status provider.
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 8: (Conditional on support for EC certificates as indicated in FCS_COP.1/Sig). 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 9: (Conditional on support for EC certificates as indicated in FCS_COP.1/Sig). 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. Justification
Fixed some small corrections/typos that the customer brought up: 1 - Inserted text seems to have resulted in "...CA to to be..." which appears to now contain an extra "to". 2 - The end of Test 4 also appears to have added the text "...and that the TOE treats the certificate being checked as invalid and rejects the connection" when referencing the ASPP14 yet this additional text is not underlined in accordance with the explanation for added text |