Functional Package for X.509 1.0 National Information Assurance Partnership 2024-10-21 X.509; certificates; PKI 1.0 2024-10-21 Initial version. TDs Applied X.509 is an International Telecommunication Union Telecommunication Standardization Sector (ITU-T) standard for public key certificates. Public key certificates are used as authentication mechanisms for trusted communications protocols and as integrity verification methods. This Functional Package (FP) for X.509 provides a collection of X.509 Security Functional Requirements (SFRs) and Evaluation Activities (EAs) for the verification and assertion identities of X.509 certificates, for the limited issuance of certificates used locally by TOE functions, and for the generation and provision of certificate status information of such TOE-issued certificates to the TOE functions that rely on such TOE-issued certificates. The intent of this FP is to provide Protection Profile (PP), collaborative Protection Profile (cPP), and Protection Profile Module (PP-Module) authors with a readily consumable collection of SFRs and EAs to be integrated into their documents. Extended Package, TSF Interface A certificate extension that provides a means of identifying the public key corresponding to the private key used to sign a certificate or CRL. A Boolean flag that is used to designate whether a certificate is a CA certificate. If this flag is present and set to TRUE on a certificate, that certificate also has a pathLen attribute. An entity that is responsible for the issuance and maintenance of digital certificates. A method by which a CA has the ability to communicate that a certificate it issued has been revoked and should no longer be trusted, originally described in RFC 5280. A message that a subject sends to a certification authority to apply for a digital certificate. A unique identifier for a subject. An optional attribute of an X.509 certificate that designates the intended usage of the certificate, such as for server authentication, client authentication, or code signing. A method of certificate management that uses HTTPS to transmit certificate requests and responses. A method by which a CA has the ability to communicate that a certificate it issued has been revoked and should no longer be trusted, originally described in RFC 6960. An expedited version of OCSP where the CA includes an assertion of a leaf certificate's validity as part of a connection handshake. An expedited version of OCSP where the CA includes an assertion of a leaf certificate's validity, as well as the validity of any intermediate CA certificates between the root and the leaf, as part of a connection handshake. A numeric string that uniquely represents object types in certificates. An attribute of CA certificates that specifies the maximum length of a certificate chain that terminates with that certificate. The practice of associating subjects with public keys for the purpose of trusted communications, and the physical, logical, and personnel mechanisms used in support of implementing this. An optional component of public key infrastructure to which a CA can delegate certain management functions. A certificate extension that allows identities to be bound to the subject of a digital certificate. A certificate extension that provides a means of identifying certificates that contain a particular public key. The Target of Evaluation (TOE) in this functional package (FP) is a product that uses X.509 capabilities for certificates. A certificate user that depends on the public key of a certificate is required to process certificates using the ‘verify’ capabilities included in this FP. Such certificate users verify certificates for a variety of TOE functions, including subject authentication, trusted communications, validation of TOE software and firmware updates, or integrity verification as part of self testing. A certificate user that is represented as the subject of a certificate depends on the ‘assert’ capabilities included in this FP. TOE functions use certificates issued by a certification authority trusted by a relying party to convey a subject and context information associated with the certificate to the relying party. TOE functions that use certificates include external entity initiated communications with the TOE such as web services or email, and TOE-initiated communications with entities requiring client authentication. When all verifiers of a certificate are associated with TOE functions, it is permissible to use an embedded certification authority that is only trusted by the TOE (i.e., only locally trusted). When such functionality is provided, the TOE depends on the provider functionality of the FP. TOE functions that verify TOE provided certificates depend on the certificate status provider functionality in this FP; TOE functions that use TOE provided certificates depend on the certificate issuance functionality of this FP. A conformant TOE will include the ability to validate X.509 certificates presented to it, including: cryptographic validity of the digital signature. time-based validity. issuer-based validity. revocation status using a Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP). validation that the certificate's extensions are consistent with its intended use. A conformant TOE must also define its intended uses for X.509 certificates and how to proceed when a certificate with undetermined revocation status is presented to it. This FP also defines mechanisms by which the TSF can generate a Certificate Signing Request (CSR) for receiving a signed certificate from a Certification Authority (CA). This may be generated either as a file that is provided to a CA manually or done via an active network connection to the CA using Enrollment over Secure Transport (EST). There may also be some situations where revocation checking is not performed. This FP defines an optional requirement for cases where exceptions to the claimed revocation functionality exist. Lastly, the X.509 functionality defined by this FP is part of a TOE, but is not considered to be an entire TOE on its own. X.509 functionality is implemented by a wide variety of technology products, some of which are standalone and some dependent on a trusted platform (such as a software application on a general-purpose computer or mobile device). Auditable events have been defined for the SFRs in this FP for cases where the TOE boundary includes an audit function specified by FAU_GEN.1. A TOE that conforms to this FP may also implement or rely on its OE to implement appropriate management functionality for X.509 functionality that may include: specifying root and intermediate CA certificates to be used as trust anchors. generating certificate requests and loading signed certificates for the TOE's own use into its trust store. specifying the revocation method that is used. configuring how the TOE behaves in the event that certificate revocation information is unavailable. Any conformant TOE must consider the extent to which X.509 functionality must be managed, and ensure that appropriate management claims are made in the TOE's ST or that the TOE conforms to a PP that allows a trusted platform in its OE to implement them. This FP describes the extended security functionality of X.509 in terms of . The contents of this FP must be appropriately incorporated into a PP, cPP, or PP-Module. When this FP is incorporated as such, the ST must include selection-based requirements in accordance with the selections or assignments indicated in the incorporating document. The PP, cPP, or PP-Module that instantiates this FP must typically include the following components in order to satisfy dependencies of this FP. It is the responsibility of the PP, cPP, or PP-Module author who incorporates this FP to ensure that dependence on these components is satisfied, either by the TOE or by assumptions about its OE. An ST must identify in its conformance claims the applicable version of the PP, cPP, or PP-Module, and of this FP. : Dependent Components Required for Package Functionality FCS_CKM.1 To support public and private key pair generation for creating an X.509 CSR, the PP or PP-Module must include FCS_CKM.1 and specify the corresponding algorithms. FCS_COP.1 To support the cryptography needed for X.509 validation, the PP or PP-Module must include FCS_COP.1 (iterating as needed) to specify appropriate digital signature validation and hash algorithms for the X.509 certificates presented to the TOE. FCS_HTTPS_EXT.1 To support EST when claimed, or when CMC using HTTPS is claimed, the PP or PP-Module must include an SFR for HTTPS communications. Note that support for EST is not mandatory. FCS_RBG.1 To support the Random Bit Generation (RBG) needed for public and private key pair generation, the PP or PP-Module must include FCS_RBG.1 or an extended SFR that defines comparable functionality. FCS_TLSC_EXT.1 To support EST when claimed, the PP or PP-Module must include an SFR for TLS client communications. Note that support for EST is not mandatory. FPT_KST_EXT.1 To support CA signing keys, whether the CA is using a certificate or the corresponding public key is loaded into the relying party’s trust store, the PP or PP-Module must include FPT_KST_EXT.1 to protect the private keys used. FPT_KST_EXT.2 To support CA signing keys, whether the CA is using a certificate or the corresponding public key is loaded into the relying party’s trust store, the PP or PP-Module must include FPT_KST_EXT.2 to protect the private keys used. FPT_STM.1 To support validating whether a presented X.509 certificate is expired, the PP or PP-Module must include FPT_STM.1 or some other requirement that ensures reliable system time. FTP_ITC.1 To support EST when claimed, the PP or PP-Module must include FTP_ITC.1 to define a trusted channel between the TOE and a trusted CA. Note that support for EST is not mandatory. The following use cases are distinct and may be combined for any given TOE. They include the TOE as a relying party verifying the identity of entities using certificates obtained from an external CA the TOE asserting an identity in a certificate provided by an external CA and providing identity verification (authentication) to external relying parties the TOE acting as the sole relying party of entities issued certificates using an embedded CA Combining the verify and subject use cases also includes authentication and verification between internal entities. Combining all three use cases allows external CAs to be used for both internal and external entities, but an internal embedded CA is only to be used for internal relying parties. Note: A TOE that provides general Certification Authority functionality for external entities should be validated against the Certification Authority Protection Profile instead of this FP. Note: TOEs that provide certification authority functionality as an embedded CA in support of TLS inspection should use the SSL/TLS Inspection Proxy (STIP) Protection Profile module instead of this FP. The ‘provide’ functionality in this FP is a generalization of the security requirements of the embedded CA functionality for STIP PP module, but this FP does not include the proxy and TLS processing requirements from the STIP PP module. The following diagrams show each TOE use case (within the red box) with respect to its role in an overall system.

exact extended conformant The auditable events specified in this FP are included in an ST if the incorporating PP, cPP, or PP-Module supports audit event reporting through FAU_GEN.1, and if all other criteria in the incorporating PP or PP-Module are met. : Auditable Events for Mandatory SFRs Components in this family define requirements for the TOE’s ability to generate and issue certificates. The ST author claims the TOE functions that will rely on the certificates issued by the embedded CA. A TOE may support different certificate profiles, each associated with unique embedded CA supporting a subset of the supported functions or the TOE may support a common profile that uses the key usage and extended key usage extensions to differentiate the intended use of a certificate. When a single CA supports multiple functions requiring explicit EKU values, the extendedKeyUsage extension is claimed in to distinguish which functions are supported by the certificate. The ST author describes the certificates issued by an embedded CA and the methods for obtaining the data contained in the certificates. The supported fields and default values specified for all TOE functions are described in this element. The ST author claims the methods for determining the maximum validity period in the selection for the validity field. Both options are claimed if the administrator can configure a time up to a TSF defined maximum. The ST author describes the methods for determining the name of the embedded CA in the selection for issuer field. The ST author claims the method for constraining the signature field and the algorithm specification in the subjectPublicKeyInfo field. The selection ‘…in accordance with RFC 8603’ is claimed if the TOE supports the algorithms indicated in the RFC for signing certificates, and also supports other algorithms not intended for signing certificates. The ST author describes each extension supported and how values for the extension are determined. It is recommended that the extendedKeyUsage is claimed and populated with specific EKU purposes when the supported functions expect explicit EKU values; it is required that the extendedKeyUsage field is claimed when the embedded CA supports code signing or integrity functions. It is expected that if a single embedded CA issues certificates supporting multiple functions requiring explicit EKU values, the explicit EKU purposes for each function, including IPsec/IKE if supported, are claimed. Other supported EKU values specific to supported functions are indicated in the assignment. Any supported EKU values are consistent with the KU usage indicators claimed. For example, "codeSigning" is claimed only if "digitalSignature" is claimed for keyUsage, and TLS key usages "serverAuth" or "clientAuth" are claimed only when "digitalSignature," "keyEncipherment," or "keyAgreement" are supported according to the supported TLS function's version and ciphersuite capabilities. If “subjectAltName” is claimed as a supported extension, the ST author claims all RFC 5280 name types supported and designates any other standard name types in the assignment, indicating the formatting and normalization standard used for each supported name type. Standards used to refine or provide alternate normalization for RFC 5280 name types are claimed via the assignment. General profiles described in are refined by specific configurations of the issuing CA in the SFR element. The ST author claims the source of these inputs A certificate profile is further refined by inputs of the function(s) supported. In the first bullet, the ST author describes the name types indicated for each supported function (a subset of the supported name types indicated in ), how subjects of certificates are determined, and how the requested subject names are validated. Note that when multiple names are included in a request, 'validated' applies to all names populated in a certificate. When the subject of a certificate represents an entity external to the TOE or when an internal TOE entity supports it, a standard certificate request formatting or protocol is supported, and all certificate values requested by the entity are included in the request; the internal TOE function which exclusively trusts these external certificates may act as a registration authority as specified in the claimed RFC. When the subject of the certificate is associated with an internal TOE function, the values in the populated certificate may use any method that is under the control of the subject. PKCS-10 is claimed when the supported function interfaces directly with an embedded CA to generate a certificate representing a TOE entity. When the EST, CMC, or CMP method is claimed, the ST author will claim FDP_ESTS_EXT.1, FDP_CMCS_EXT.1, or FDP_CMPS_EXT.1, respectively. In the second bullet, the ST author indicates where the key pair is generated and how the embedded CA validates that the entity represented in the certificate is in possession of the associated private key. In the third bullet, the ST author describes the additional certificate constraints, if any, provided by the supported function that may override the values included in a certificate request (if supported). The evaluator shall examine the TSS to ensure it describes the TOE functions using certificates generated by the embedded CA and how the certificate is used. For each such function, the evaluator shall verify the TSS describes one or more certificate profiles used by the embedded CA in support of the function that are compliant with the requirements. The evaluator shall further examine the TSS to ensure that it describes how the TSF updates and enforces each certificate profile based on the configuration of the CA and inputs provided by the supported function. For each subject DN or subjectAltName name type supported, the evaluator shall verify that the ST indicates the normalization standard used for the name type and the method used for ensuring the name populated in the certificate is appropriately normalized. The evaluator shall examine the AGD guidance and verify it describes instructions for configuring the embedded CA and its certificate profiles to meet the requirements. The evaluator shall perform the following test. For each supported function claimed in , and for each certificate profile associated to the function, the evaluator shall cause the TOE to issue a certificate and observe that the certificate meets the appropriate profile, including constraints determined by the embedded CA configuration and inputs provided by the function. If multiple name types are supported, the evaluator shall repeat this test as necessary to include all supported name types. [conditional] If “subjectName” is claimed and standard certificate requests are supported that allow a general DN to be input, the evaluator shall send the TSF a certificate request that includes a DN with an RDN component containing multiple elements and verify that TSF rejects the request. [conditional] If “subjectAltName” is claimed, and standard certificate requests are supported that allow multiple SAN entries, then for each name type supported, the evaluator shall send the TSF a certificate request with multiple SAN entries of the indicated name type, where the first entry is valid and the second entry is invalid. The evaluator shall confirm that the TSF issues a certificate containing only the first entry. Note: the method to create an invalid entry depends on the validation methods claimed. Certificate generation Success: Certificate value Certificate object identifier requires the TSF to implement a TOE-trusted certificate profile function that conforms to profiles when acting as a CA. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Certificate generation FCS_CKM.1 Cryptographic Key Generation FCS_COP.1 Cryptographic Operation FMT_SMR.1 Security Roles There are no EAs for this component. requires the TSF to maintain a linkage between supported certificate requests and certificates it has issued to be able to associate each certificate with each request No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Linking of certificate to certificate request FDP_CER_EXT.1 Leaf Certificate Profiles [FIA_ESTS_EXT.1 Enrollment Over Secure Transport (EST) Server OR FIA_CMCS_EXT.1 Certificate Management Over CMS (CMC) Server OR FIA_CMPS_EXT.1 Certificate Management Protocol (CMP) Server] This SFR is claimed when certificate requests to an embedded CA are supported. It ensures that administrators of the TSF are able to associate any issued certificate to a request from an authorized entity associated with a supported function, and identify certificates issued in response to requests from unauthorized entities, as the result of the misuse of access to the TOE. If the association in is performed as a condition of issuance, the ST author claims ‘not issue’; if the association is performed after issuance, the ST author claims ‘revoke’. Revoke should be claimed only if one or more of ‘generate certificate status information’ or ‘provide access to…’ is claimed in . The method of validating a request is specific to the request method. If ‘An EST request…’ is claimed, is also claimed; If ‘A CMC request…’ is claimed, is also claimed. If ‘A CMP request…’ is claimed, is also claimed. It is preferred, but not required that the request identifiers, certificate identifiers and the binding is retained in searchable audit records for the embedded CA, but other mechanisms of establishing a binding are acceptable. The evaluator shall inspect the TSS and verify that the method to associate certificates with requests by the supported function is described. The evaluator shall inspect AGD documentation to verify that instructions are included as necessary to ensure the binding of issued certificates to the request meets the requirements. The evaluator shall perform the following test. [conditional] If the embedded CA provides certificates to external entities in support of TOE functions, and if the binding is searchable, the evaluator shall cause a TOE function to initiate a certificate request for the external entity and observe that a binding associates the certificate with the function’s request. Linking of certificate to certificate request Success: Certificate value Certificate object identifier , Certificate request Link to certificate request object identifier Failure: Reason for failure, Certificate request Link to certificate request object identifier Components in this family define requirements for the usage of certificate revocation lists (CRLs) as a method of recording certificate status information. requires the TSF to include specific information in any certificate revocation lists that it creates. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Failure to generate CRL FCS_COP.1 Cryptographic Operation This requirement should be claimed if 'ITU-T Recommendation X.509v2 CRL' is selected in . The ST author is expected to refine the FCS_COP.1 reference to include an iteration name that is appropriate for the digital signature requirement of the PP or PP-Module that conforms to this package. For example, a name like "FCS_COP.1/SigGen" is typical. It is expected that the supported signatures are limited to 3072-bit RSA or higher, or ECDSA using NIST P-384 or P-521, based on the signature requirements in the PPs and PP-Modules with which this FP is intended for use. The ST author claims the optional refinements to ITU-T Recommendation X.509v2 CRL that are supported. If "issuerAltName" is claimed in the first refinement, then "The version field..." and "The issuerAltName..." entries in the optional refinements selection are claimed. The evaluator shall examine the TSS to ensure it indicates whether the TOE supports CRL generation and, if so, describes the CRL generation function. In addition, the evaluator shall ensure that the TSS identifies which of the values identified in can be included in CRLs. If the TOE supports configuration of the CRL issuing function, the evaluator shall examine the operational guidance to ensure that instructions are available to configure issuance of CRL in accordance with . The evaluator shall perform the following test. In conjunction with , the evaluator shall observe that the CRL issued by the embedded CA meets the criteria of this requirement. Failure to generate CRL N/A Components in this family define requirements for the association of certificate status information with certificates issued by the TOE. requires the TSF to maintain certificate status information for its issued certificates, ensure any certificates it issues are valid for a sufficient period of time, supply a repository with status information, or identify a method to invalidate trust that has been revoked. No specific management functions are identified. There are no auditable events foreseen. Certificates issued by an embedded CA that is only trusted by supported TOE functions may be revoked via notification from a supported function, or via administrative actions. When revoked, certificate status information must become available to all internal TOE functions that may use the impacted certificate when the embedded CA is so notified. The TOE may use general methods such as issuance of CRLs or via an OCSP responder when one of the supported TOE functions expects such methods, or the TOE may provide direct access to a certificate repository managed by the embedded CA that includes status information. Distribution of Certificate status information is not required if certificates expire before notification is required, or if the issued certificates are only trusted by a single TOE function that manages the validity of certificates. If general methods are supported, the ‘generate certificate status information’ option is claimed and is claimed. If certificates are issued for a sufficiently small validity period, which is less than the time that is typically allowed to process revocation requests, revocation information is not required and the ST author assigns the maximum validity period allowed by the certificate profile, as indicated in . If the TSF provides access to a certificate repository, the ST author claims ‘provide access …’ and identifies the repository and methods of access in the assignment. If each supported function manages the validity of the certificates it uses without depending on the embedded CA, the ST author claims ‘depend on…’ and describes the method used by each such function. In this case, the embedded function takes on traditional functionality of a CA. Depending on the PP or PP-Module that this FP is used with, certain requirements of that PP or PP-Module would then apply to the functionality described here as well, such as authorized administration to configure the function. The evaluator shall review the TSS and verify that the description of the decision processes used by the TOE to invalidate certificates issued by the embedded CA is included and any threshold for issuing revocation information is described. The evaluator shall review AGD documentation to verify instructions to configure the ability of the embedded CA to issue certificate status information is described, if required. If the TSS indicates that revocation status information is not provided for certificates having a validity period shorter than a threshold that is less than that indicated in the TSS for , the evaluator shall ensure that the instructions describe how to configure the validity period so that issuance certificate status information is not required. None. Components in this family define requirements for the TOE’s ability to generate certificate status information and to modify the status of issued certificates. requires the TSF to generate certificate status information using a supported method and to define conditions in which this information can be modified. No specific management functions are identified. There are no auditable events foreseen. [FDP_CRL_EXT.1 Certificate Revocation List Generation OR FDP_OCSP_EXT.1 OCSP Basic Response Generation] FMT_SMR.1 Security Roles The ST author indicates the supported Certificate Status information methods. If "ITU-T Recommendation X.509v2 CRL" or "ITU-T Recommendation X.509v2 CRL as refined by RFC 8603" are claimed, FDP_CRL_EXT.1 is also claimed. If "the OCSP standard as defined by RFC 6960" is claimed, FDP_OCSP_EXT.1 is also claimed. The ST author indicates the methods to notify the embedded CA of certificate status change. If inputs from a TOE function supported by the embedded CA trigger revocation, the ST author identifies the method of notification for each such function in the assignment. If "ITU-T Recommendation X.509v2 CRL" or "ITU-T Recommendation X.509v2 CRL as refined by RFC 8603" is selected in FDP_CSI_EXT.1.1, FDP_CRL_EXT.1 must be claimed. If "the OCSP standard as defined by RFC 6960" is selected in FDP_OCSP_EXT.1.1, FDP_OCSP_EXT.1 must be claimed. The ST author claims the supported methods for distributing generated certificate status information to the supported functions that are relying parties for the issued certificates. If CRLs are claimed in , then ‘posting CRLs at… cRLDistributionPoints…’ is claimed in and ‘cRLDistributionPoints’ is claimed in . If the OCSP standard is selected in , then FDP_OCSP_EXT.1 is also claimed and at least one of ‘OCSP mechanism…in the authorityInfoAccess…’ or ‘…OCSP stapling…’ is claimed in the selection for . If ‘OCSP mechanism…in the authorityInfoAccess…’ is claimed in , then ‘authorityInfoAccess’ must be claimed in . If ‘…OCSP stapling’ is claimed, the ST author identifies the functions using OCSP stapling for server-authenticated TLS or DTLS and describes the interface to provide the OCSP response to each of the functions in the assignment. The evaluator shall examine the TSS and verify that the description of the revocation function meets the requirements of the referenced RFI, how revocation status updates are initiated, and how each supported function receives status updates. The evaluator shall examine the AGD documentation and verify that instructions for revoking certificates issued by the embedded CA are included, and that the configuration of revocation status information locations is described. The evaluator shall perform the following test. For each revocation method claimed, the evaluator shall attempt to cause the supported function to revoke an issued certificate. The evaluator shall demonstrate that the function no longer accepts the revoked certificate. [conditional:] If status changes allow reinstatement of suspended certificates, then for each method supporting reinstatement, the evaluator shall suspend a certificate, demonstrate that it is not trusted, then reinstate the certificate and demonstrate that TSF allows subsequent use of the certificate. If the certificate is used for persistent signatures, then the evaluator shall also demonstrate that a signature applied by a suspended certificate prior to reinstatement is not trusted after the certificate is reinstated. (conditional, if information is not provided via CRL or OCSP) Revocation Certificate identifier Reason for revocation Components in this family define requirements for the usage of the Online Certificate Status Protocol (OCSP) as a method of recording certificate status information. requires the TSF to include specific information in any OCSP response that it creates. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Failure to generate certificate status information FCS_COP.1 Cryptographic Operation FPT_STM.1 Reliable Time Stamps This requirement should be claimed if 'the OCSP standard as defined by RFC 6960' is selected in The evaluator shall examine the TSS and verify that the description of the OCSP response function is described and meets the requirements. The evaluator shall review the AGD documentation and verify that instructions for configuring the OCSP function, including specifying the location of the OCSP responder, if claimed, are described. The evaluator shall perform the following test. In conjunction with , the evaluator shall observe that the OCSP response issued by the embedded CA is available at the configured locations and meet the criteria of this requirement. Note: OCSP stapling includes the response signed by the OCSP responder in the TLS handshake data – this ‘location’ is used if OCSP stapling or OCSP multi-stapling is claimed, otherwise, the location is included in the issued certificate or at a configured local OCSP responder. Failure to generate certificate status information N/A Components in this family define requirements for the TOE to generate CMC requests. requires the TSF to generate, export, import, and transport CMC requests that meet client and end-entity compliance requirements. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: CMC certificate or revocation requests CMC responses issued FIA_X509_EXT.3 X.509 Certificate Requests FMT_SMR.1 Security Roles FTP_ITC.1 Inter-TSF Trusted Channel The ST author claims the methods for exchanging CMC messages. If CMC transport over HTTPS is claimed, the HTTPS (with mutual authentication for renewal or re-key requests) is in accordance with FCS_HTTPS_EXT.1. If the certificate being renewed does not support TLS client authentication, the TSF uses a valid certificate suitable for TLS with client authentication having the same issuerName, subjectName, and subjectAltName as the certificate being renewed. If the TSF does not support such a certificate, this option is not claimed. The evaluator shall examine the TSS to ensure that it describes how CMC client support is provided, the supported messages for each profile supported, and each optional feature from the RFI, and verify that the description complies with the requirements. The evaluator shall examine AGD guidance to ensure instructions are provided to configure CMC client functionality as necessary to meet requirements, or when multiple options are supported. In conjunction with , the evaluator shall observe that each CMC message sent by the TSF is compliant with the requirements. [conditional]: If HTTPS transport of CMC is supported, the evaluator will observe that CMC messages are transported over a compliant HTTPS session with the CA. If renewal or re-key is supported, the evaluator shall attempt to renew or re-key a certificate obtained in , and verify that compliant mutually authenticated HTTPS is established with the CA. CMC certificate or revocation requests None CMC responses issued Any signed response Components in this family define requirements for the TOE to accept CMC requests. requires the TSF to accept, process, and send CMC requests that meet CMS server and CA requirements. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: CMC messages received containing certificate or revocation requests CMC responses issued FCS_COP.1 Cryptographic Operation FDP_CER_EXT.2 Certificate Request Matching FPT_STM.1 Reliable Time Stamps FTP_ITC.1 Inter-TSF Trusted Channel The ST author claims supported CMC request processing and the supported CMC profiles as indicated in , with matching selections. A CMC profile describes the cryptographic functions and extensions supported. If profiles other than RFC 8756 are supported, the ST author describes the supported cryptographic functions and extensions used for those profiles. Cryptographic functions used in the CMC profile are limited to those specified in the PP or PP-Module which claims conformance to this FP. The mechanism that implements these functions (e.g., whether it is part of the TSF or invoked from its platform) is specified in . The ST author claims the supported CMC responses meeting each CMC profile claimed in FIA_CMCS_EXT.1.1. RFC 6402 section 4.1 indicates mandatory support for cryptographic functions that are no longer recommended. This PP functional package does not allow such deprecated functions, and instead requires that supported cryptographic functions be specified in a CMC profile. The ST author claims the supported transport of CMC requests from a supported function and responses to the supported function making the request. If CMC file transport is used, the ST author claims the first option and describes the method for transferring the files to and from each entity as authorized by the supported function in the assignment. If the TSF supports CMC transport to external entities via HTTPS, the second option is claimed, and the ST indicates which entities are authorized to request certificates. Cryptographic support is specified in the CMC profile. The ST author specifies the cryptographic functions used for CMC and whether these functions are part of the TSF or invoked by it as part of the TOE platform (e.g., a cryptographic library offered by a general-purpose operating system for third-party applications). It is expected that the cryptographic implementation cited here is consistent with any claims made in the PP or PP-Module which claims conformance to this FP, both with regards to where the implementation resides and for what algorithms are used. The ST author indicates how CMC requests are authorized to meet the needs of supported functions. A supported function requiring certificates to be generated by the embedded CA and using CMC to manage those certificates may approve certificates using an entity possessing an RA certificate, via an interface or via manual configuration. If ‘an RA entity…’ is claimed, additional selections are also claimed to account for the initial RA certificate used by the entity. The second option is claimed if certificates are authorized by an interface to the supported function. This option is claimed if a supported certificate management method other than CMC is used to establish initial certificates, or if the supported function informs the CMC function via an implied or explicit interface. For example, an interface can be implied through the use of HTTPS transport controlled by the TOE function. Administrator control of CMC requests is acceptable, and may be required if an RA certificate associated with the function is initialized using manually imported CMC or if the function associates certificates with local users (e.g., administrator SSH certificates), but is limited to certificate requests required by the supported function. If ‘under the control of an administrator’ is claimed, the ST author describes how administrators are limited to certificate requests associated with supported function. The evaluator shall examine the TSS to ensure that it describes how CMC server support is provided for each supported TOE function managing certificates from the embedded CA using CMC. The evaluator shall examine the TSS to ensure it describes how initial and subsequent certificates requests are authenticated and authorized for use by the supported function. The evaluator shall examine the operational guidance to ensure it contains instructions on how to configure CMC processing to support the TOE’s certificate profile(s) associated to supported functions using CMC. If the TSS indicates that neither AuthenticatedData or Identity Proof Version 2 Control mechanisms using shared secrets are supported, the evaluator shall also examine the operational guidance to ensure that it describes how to authenticate requests for initial subscriber certificates and, if supported, initial certificates for Registration Authority functions, when no other certificates are available. For each supported TOE function using CMC for managing certificates from the embedded CA, the evaluator shall perform the following tests. [conditional]: If the supported function uses an administratively installed RA entity to approve certificates in CMC requests, the evaluator shall follow AGD guidance as necessary to initialize and install an RA certificate associated with the supported function. The evaluator shall observe that the initial RA certificate request is authenticated using CMC proof-of-possession, matches the relevant CMC RA certificate profile, and is authorized using a method described in FIA_CMCS_EXT.1.5. For each authorization method applicable to initial certificate requests used by the supported function, the evaluator shall cause an initial certificate request to be presented to the TSF that is approved using the method. The evaluator shall confirm that the authorization method is used. The evaluator shall cause a valid initial certificate request for an authorized external entity to be sent over HTTPS and observe that the TSF sends the response over the established channel. [conditional]: If the TSF supports certificate renewal or update of external entities via CMC, the evaluator shall cause the certificate in the response to test 3 to authenticate the HTTPS session for a CMC requests for a certificate renewal using a CMC request and observe that the response includes the requested certificate. The evaluator then shall cause a certificate update request to be transported over HTTPS for which the certificate message from the requester is empty. The evaluator shall observe that the TSF does not provide the requested certificate in a CMC response. CMC messages received containing certificate or revocation requests Identifiers for all entities authenticating the request, including the entity providing client authentication for the CMC transport (if any) The request received CMC responses issued Any signed response Components in this family define requirements for the TOE to generate CMP requests. requires the TSF to generate, export, import, and transport CMP requests that meet subject and end-entity compliance requirements. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: CMP certificate or revocation requests FCS_COP.1 Cryptographic Operation FIA_X509_EXT.3 X.509 Certificate Requests FTP_ITC.1 Inter-TSF Trusted Channel The ST author claims the methods for exchanging CMP messages. If CMP request and response files are transported, the ST author claims the first option and indicates how the files are transferred to the CMP server. If the TSF includes an embedded CA that accepts CMP requests under the control or authorization of a supported function, the ST author describes the transport mechanism and any authorization decisions in the assignment. If CMP transport over HTTPS is claimed, the HTTPS (with mutual authentication for renewal or re-key requests) is in accordance with FCS_HTTPS_EXT.1. When HTTPS is claimed, the certificate used to authenticate the session meets the requirements in this FP for a TLS client certificate and has the same subjectName and subjectAltName as the certificate being renewed; if the TSF does not possess such a certificate, this option is not claimed. The evaluator shall examine the TSS to ensure that it describes how CMP client support is provided and complies with the requirements. The evaluator shall examine AGD guidance to ensure instructions are provided to configure CMP client functionality as necessary to meet requirements, or when multiple options are supported. In conjunction with , the evaluator shall observe that the CMP messages are compliant with the requirements. [conditional]: if HTTPS transport of CMP is supported, the evaluator shall observe that CMP messages are transported over a compliant HTTPS session with the CA. If renewal or re-key is supported, the evaluator shall attempt to renew or re-key a certificate obtained in , and verify that compliant mutually authenticated HTTPS is established with the CA. CMP certificate or revocation requests None Components in this family define requirements for the TOE to authenticate CMP requests. requires the TSF to receive, process, and respond to CMP requests from authorized clients and RAs. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: CMC messages received containing certificate or revocation requests CMC responses issued FCS_COP.1 Cryptographic Operation FDP_CER_EXT.2 Certificate Request Matching FPT_STM.1 Reliable Time Stamps FTP_ITC.1 Inter-TSF Trusted Channel This SFR is claimed if the embedded CA supports CMP server functionality, as indicated in , and the claimed versions match the selections. If Registration Authority is supported, the ST author describes entities that are issued RA roles. Authorized entities may be an administrative user, or a functional entity associated with a supported TOE function. If v3 CMC is also supported, certificates associated with such authorized entities have an extendedKeyUsage field that includes the id-kp-cmcRA purpose. Entities with an RA role are used to authenticate initial requests on behalf of authorized clients that might not have existing certificates issued by the embedded CA. Certificate-based authentication refers to signatures used in CMP messages from clients or end entities who possess a certificate used for transferring messages directly from the client or end entity. The ST author claims authentication methods used for initial requests and any alternate authentication methods for CMP messages. If RA entities are claimed in , the ST author claims ‘RA assertion’ if RA authentication is used to authorize subject or end entity requests. The ST author indicates the methods for establishing initial authentication material for each supported function. If out-of-band methods are used to distribute shared secret information to authenticate initial request, the ST author describes the method, including the requirements for authorized users and any TOE-negotiated out-of-band channel used in the assignment. The ST author claims ‘as configured…’ if the initial authentication of clients or end entities is determined by configuration of the TOE. The ST author describes any other method for initializing subjects if applicable. The ST author claims ‘in-line messaging’ if certificates are provided to external entities. The ST author claims ‘in-line messaging’ or ‘CA key generation’ according to the method supported for certificates assigned to internal TOE entities. The evaluator shall examine the TSS and verifies the description of CMP server functionality is described and is compliant with the requirements. The evaluator shall examine AGD documentation and verifies that any configurable features of the CMP server functionality required to meet the requirements are included. The evaluator shall perform the following tests. For each initial authentication method supported, the evaluator shall demonstrate that the TSF is able to authenticate clients using the indicated authentication material. The evaluator shall then attempt to provide invalid authentication material for the method and demonstrate that the TSF does not generate the requested certificate. For each supported authentication method using certificate-based authentication, the evaluator shall demonstrate that the TSF is able to process a request using the method. The evaluator shall then use certificates not trusted by the TSF for CMP message authentication, and observe the TSF does not generate the requested certificate. For each supported proof-of-possession method supported, the evaluator shall demonstrate that the TSF is able to process the certificate requests for certificates using the method. The evaluator shall then present invalid proof-of-possession evidence for the certificate request and observe that the TSF does not generate the requested certificate. For each transport method supported, the evaluator shall demonstrate that the TOE is able to receive and send CMP messages protected by the method. [conditional]: If version 3 CMP messages are supported, the evaluator shall demonstrate that all supported hashAlg values are accepted by the TOE. CMP messages-received containing certificate or revocation requests Identifiers for all entities authenticating the request, including the entity providing client authentication for the CMC transport (if any) The request received CMC response issued None Components in this family define requirements for the TOE’s use of Enrollment over Secure Transport (EST) to obtain certificates from an external CA. defines the ability of the TSF to perform Enrollment over Secure Transport (EST) as a client connecting to an external CA. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: EST certificate or revocation requests FCS_COP.1 Cryptographic Operation FCS_TLSC_EXT.1 TLS Client Protocol FDP_CER_EXT.2 Certificate Request Matching FPT_STM.1 Reliable Time Stamps FTP_ITC.1 Inter-TSF Trusted Channel The ST author claims the supported EST capabilities. The evaluator shall examine the ST and verify that EST functionality is described and meets the requirements. The evaluator shall examine the AGD guidance and verify that instructions for configuring EST functionality are described, including initializing the implicit TA database if claimed. The evaluator shall demonstrate the TOEs ability to configure and update trust stores associated with EST servers. In conjunction with , the evaluator shall observe that requests using EST are compliant with the requirements. EST certificate or revocation requests None Components in this family define requirements for the TOE’s use of Enrollment over Secure Transport (EST) to authenticate certificates from an external CA. defines the ability of the TSF to perform Enrollment over Secure Transport (EST) as a server connecting to an external CA. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: EST messages received containing certificate or revocation requests EST responses issued FCS_COP.1 Cryptographic Operation FCS_TLSC_EXT.1 TLS Client Protocol FDP_CER_EXT.2 Certificate Request Matching FMT_SMR.1 Security Roles FPT_STM.1 Reliable Time Stamps FTP_ITC.1 Inter-TSF Trusted Channel This SFR is claimed if the TOE supports an EST server associated with an embedded CA to process enrollment requests; the embedded CA is referred to as the EST CA in the RFC. Updates to RFC 7030 indicated in RFC 8996 applies to all references to RFC 7030 in this SFR. If Registration Authority (RA) functionality is supported, the ST author describes which authorized entities the EST CA issues RA certificates to. Authorized entities may be an administrative user, or a functional entity associated with a supported TOE function. Certificates associated with such authorized entities have an extendedKeyUsage field that includes the id-kp-cmcRA purpose and are used to make authenticated initial requests on behalf of authorized clients that might not have existing certificates issued by the EST CA. Enrollment over Secure Transport (EST) uses the simple Certificate Request Message as specified in RFC 7030. Requirements associated with mutual authenticated TLS as a server are included in the base PP. HTTP authentication methods are claimed if the method is supported for initial enrollment, when the client does not possess an existing certificate for authentication, or if HTTP authentication are supported as a supplemental authentication method. If HTTP digest authentication is claimed, the associated hash function is required to be claimed in the base cryptographic support functions. Either of the HTTP authentication methods are included in an HTTPS secure connection with an EST client. Requirements associated with server-authenticated HTTPS are included in the base PP. If RA functionality is supported, as indicated in the ‘TLS certificate-based…’ method is claimed for authorized RA entity identified in . If claimed, requirements associated with mutually authenticated TLS as a server are included in the base. The ST author specifies claims supported client authorization methods. The first option is claimed when RA functionality is assigned to authorized entities in accordance with . If HTTP authentication methods are claimed in , the ST author claims the second option and describes how the TOE determines a client is authorized. The evaluator shall examine the TSS to ensure it describes the implementation of this protocol. If the description indicates the use of an RA for initial issuance or authorization of certificates, the evaluator shall examine the TSS to ensure that this role is supported and associated with the specified entities. The evaluator shall examine the operational guidance to ensure it contains instructions on configuring the TOE so that EST conforms to the description in the TSS. The evaluator shall perform the following tests. The evaluator shall use an EST client to request certificate enrollment of an authorized subject to obtain a new certificate from the TOE using the simple enrollment method described in RFC 7030 Section 4.2, authenticating the request using an existing certificate and corresponding private key as described by RFC 7030 Section 3.3.2. The evaluator shall confirm that the TOE issues a certificate and returns it to the client. [conditional]:If HTTP basic authentication or if HTTP digest authentication is selected in FIA_ESTS_EXT.1.3, the evaluator shall use an EST client to request an initial certificate for an authorized entity from the TOE using the simple enrollment method described in RFC 7030 Section 4.2, authenticating the request using a username and password established for the entity in each of the claimed methods, as described by RFC 7030 Section 3.2.3. The evaluator shall confirm that the TOE issues a certificate and returns it to the client. [conditional]: If “the authenticated client certificate is issued by the EST CA and asserts id-kp-cmcRA in its extended key usage extension…” is selected in FIA_ESTS_EXT.1.4, the evaluator shall use an EST client to request certificate enrollment of a subject not known to the TOE to be authorized, to request an initial certificate from the TOE using the simple enrollment method described in RFC 7030 Section 4.2, authenticating the request using an RA’s certificate issued by the TOE’s embedded CA, that asserts id-kp-cmcRA in its extended key usage extension. The evaluator shall confirm that the TOE issues a certificate and returns it to the client. [conditional]: If “the authenticated client certificate is issued by the EST CA and asserts id-kp-cmcRA in its extended key usage extension…” is selected in FIA_ESTS_EXT.1.4, the evaluator shall use an EST client to request certificate enrollment of a subject not known to the TOE to be authorized, to request an initial certificate from the TOE using the simple enrollment method described in RFC 7030 Section 4.2, authenticating the request using a certificate issued by the TOE’s Certification Authority functionality that does not assert id-kp-cmcRA in its extended key usage extension and which is not associated with RA privileges. The evaluator shall confirm that the TOE does not issue a certificate. The evaluator shall modify the EST client or set up a man-in-the-middle tool between the EST client and TOE to perform the following modification to a valid certificate request. Modify at least one byte in the certificationRequestInfo field of the certificate request message and verify that the TOE rejects the request. EST messages received containing certificate or revocation requests Identifiers for all entities authenticating the request, including the entity providing client authentication for the EST transport (if any) The received request EST responses issued Any signed response Components in this family define requirements for the TOE on how to manage trust stores. defines the ability of the TSF to manage trust stores using a specified option to validate certificates. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Any addition, replacement, or removal of trust anchors in the TOE's trust store FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security Roles This element focuses on the management of trust stores used for certificate path processing. Trust stores consist of the context rules and one or more self-signed root CA certificates containing a trusted public key or ‘raw’ trusted public keys. Trust store elements are single trusted public keys using the context of the trust store for certificate path validation. OCSP certificates trusted by the TOE may also be considered trust store elements, and must be included in a trust store when revocation information is not provided directly by the issuing CA. Revocation status of local (associated with a locally configured OCSP responder) or ‘no-check’ (contains the extension id-pkix-ocsp-nocheck) OCSP certificates are not verified in accordance with the options in RFC 6960 section 4.2.2.2.1. The ST author designates which trust stores or trust store elements are managed in the assignment (a subset of those indicated in FIA_X509_EXT.1.6) and specifies one or more options for the management of trust stores used for validating certificates in the second selection. The ‘Using an update function’ option is claimed if the TOE includes trust store updates as part of the TOE's update function. The ‘Use of inputs provided by the supported function’ option is claimed if reference identifiers or other specific context information provided by the function initialize certificate path processing rules. The ‘Allowing the administrator to manage the trusted…’ option is claimed if the TOE supports administrator management of the public key associated to a trust store. The ST author specifies which trusted public keys are loaded. Local or 'no-check' OCSP certificates are claimed if OCSP certificates are loaded. The ‘Allowing the administrator to manage context rules of a trust store‘ option is claimed if the TOE supports administrator management of the context rules associated with a trust store. The ‘Methods in accordance with RFC 5934’ option is claimed if the Trust Anchor Management Protocol is supported. The ST author indicates support for validating intermediate CA, OCSP certificates with revocation information provided by the issuing CA, or leaf certificates as trust store elements in the second selection and specifies when full validation of the certificate path for these certificates is performed. The first option ‘Validating…’ is claimed if trust stores may include certificates other than root and OCSP (local or ‘no-check') certificates. For example, such trust store elements may include intermediate certificates to enhance performance or to refine the context for certification paths including these CA certificates. It is also common to designate leaf certificates associated with privileged users as trust store elements. If this option is claimed, the ST author also indicates when the revocation checks are performed. The first option ‘when installed…’ is claimed if either of the ‘Allowing the administrator to manage…’ selections are claimed. The ‘on-use’ option is claimed if such certificates are included in a trust store via other options (if ‘Using an update function’ or ‘Using … RFC 5934’ is claimed). The ‘on use’ option may also be claimed for installed certificates. In addition, the ST author indicates other times (if any) that the revocation status of such certificates is checked. The second option, ‘Prohibit…’ is claimed otherwise – that is, if the managed trust stores do not contain certificates whose revocation status can change after the trust store is initialized. The evaluator shall review the TSS and verify that the description of each trust store includes a description of the management methods that meet the requirements, to include management methods of both pre-loaded and installed trust store elements if the methods differ. The evaluator shall also ensure the ST states the method used to invalidate a trust store element. [conditional]: If the TSF supports inclusion of certificates that are neither self-signed root CA certificates nor OCSP certificates without revocation status, the evaluator shall review the TSS and verify that the description indicates when such certificates are checked for revocation status and that the description meets the requirements. The evaluator shall review the operational guidance to verify that instructions for all configurable features, if any, of the TSF are included. The evaluator shall examine the operational guidance to verify it contains instructions on how to use each supported method to invalidate a trust store element. [conditional] If administrative management of trust stores (public keys or context) is supported, the evaluator shall review the operational guidance and verify that instructions for managing all trust store elements in all administrator-managed trust stores is included. The evaluator shall perform one or more of the following tests: For each supported method for managing a trust store element, the evaluator shall exercise the method to invalidate a trust store element and demonstrate that a certification path terminating in the invalidated element results in the function failing. Note: This repeats part of . It is not necessary to repeat the method used to invalidate the trust anchor element that was previously tested. [conditional]: If the TSF supports installation of certificates that are neither self-signed root CA certificates nor OCSP certificates without revocation status, the evaluator shall demonstrate that the TSF prevents the installation of each such supported certificate type if the certificate is revoked prior to installation. Note: Such certificate types can include leaf certificates associated with context specific to the leaf, or intermediate CA certificates. Checking during installation is not claimed for certificates in which the required connection is not available during loading, or if other exemptions for revocation checking apply; such certificates are checked on use. [conditional]: If the TSF supports the inclusion of certificates that are neither self-signed root CA certificates nor OCSP certificates without revocation status and claims revocation status checks other than “when installed…” the evaluator shall demonstrate for each such certificate type, and for each event that checks revocation status, that a certificate of the indicated type that is revoked prior to the indicated event is not considered valid. Any addition, replacement, or removal of trust anchors in the TOE's trust store Identification of trust store element and modification made (add, remove, change) Components in this family define the behavior and use of X.509 certificates for functions to be performed by the TSF. Components in this family require validation of certificates according to a specified set of rules, use of certificates for authentication for protocols and integrity verification, generation of certificate requests, certificate enrollment, and revocation checking behavior. requires the TSF to check and validate certificates in accordance with the RFCs and rules specified in the component. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Unsuccessful attempt to validate a certificate FCS_COP.1 Cryptographic Operation FIA_XCU_EXT.1 X.509 Certificate Utilization ST authors may claim the assignment of a positive integer indicating a limited capability of the TSF to handle long certificate paths in the certification path validation selection; to indicate certificate paths exceeding its capabilities are considered invalid. The option “unlimited path length” is claimed if there are no such limitations. Trust anchors can be root CA certificates or public keys, together with context rules determining the appropriate use of a certificate path beyond those required in RFC 5280. Context rules may include initial name constraints, policy constraints, required certificate key usage and extended key usage values, and lists of applications associated with the trust anchor, among other rules that restrict the use of certificate paths terminating at the root CA certificate or public key. A specific formatting of trust anchors is not required, but see RFC 5914 for further discussion. This SFR element refines RFC 5280. All requirements indicated with a “MUST” in RFC 5280 are implied. In addition, this element requires support for the authorityKeyIdentifier, subjectKeyIdentifier, and keyUsage extensions even though RFC 5280 describes them as optional. The selections in this SFR may imply that additional optional requirements from RFC 5280 are required. For example, basicConstraints, including both the CA and CA values, is required when the TSF supports path lengths greater than 2; cRLDistributionPoints is required if CRLs are supported; and AIA is required if OCSP is supported. Other selections may imply additional extensions must be processed. A restriction on uniqueSubjectID and uniqueIssuerID also refines RFC 5280, which only requires the extensions be ignored. For the selection on certificate signing rules, the ST author claims one of the certificate signature algorithm limitations. The second option is claimed if any of the signature and hash algorithms described in the FCS_COP family of SFRs from the base PP are supported. For these signature limitations, use of P-521 or SHA-512 is indicated by including the supported algorithms in the assignment, even though its use is not explicitly indicated in RFC 8603. ST authors similarly claim signature algorithm limitations in the final selection for each supported revocation status (CRL or OCSP) method claimed in FIA_X509_EXT.1.3. If CRL or OCSP methods are not claimed in FIA_X509_EXT.1.3, ‘no other signature algorithm constraints’ is claimed. This SFR refines RFC 5280 to require applications to process the authorityKeyIdentifier and subjectKeyIdentifier fields and use them to support certificate chaining within the certificate path. The ST author claims all supported certificate extensions. If other extensions are supported, the ST author describes the extension, values, and any processing to determine whether paths with certificates asserting those extensions are valid. If a certificate has an empty subject name, the subject alternate name will be present and marked critical. If the TSF supports certificates with empty subject fields, the subjectAltName extension and a non-empty list of supported name types is claimed. The extendedKeyUsage is expected for many functions. It is claimed if required by the supported functions. In accordance with RFC 5280, any certificate containing non-supported extensions marked as critical are considered invalid, but otherwise non-supported extensions that are not marked as critical are ignored. The ST author claims the type of revocation status information supported. It is preferred that OCSP and CRL are supported when certificate validation supports multiple functions as indicated in FIA_X509_EXT.2. However, some functions require alternative approaches to revocation status validation and CAs supporting these functions may not provide OCSP or CRL sources. Certificates supporting these functions use alternative revocation status validation methods. The option ‘Based on validity period…’ is claimed if certificates supporting a function are only valid for less than 24 hours and issued under a certificate policy that allows 24 hours or longer to process revocation requests. The time allowance in this option is specified in the assignment; if this is configurable, the assignment indicates so and specifies the limits of the assignment. The option ‘Administrative notification…’ is claimed if the certificates are used by a function for which out-of-band notification of compromise is practiced and is expected to be claimed when certificates that do not include revocation status information sources are processed. Typically used for OCSP certificates without revocation status source information, certificates which validate software or firmware components or maintain data integrity when the TOE is in a state prohibiting revocation status retrieval or processing. This option assumes public notification or direct notification to administrators by the issuer of the certificate, or for embedded certification authority functionality under the control of the administrator. The assignments in this option are used to describe required administrative actions and methods used to invalidate the function using such certificates. The option ‘Direct association with Certification Authority…’ is claimed if the certificates are used for TOE-specific functions and where TOE has direct and reliable communication path with the issuing CA. The CA in this case could be an embedded CA, or a CA dedicated to the TSF. If claimed, the ST author identifies the issuing CA and the method of automated notification in the assignment. Certificates that do not have revocation status location indicated in either the CRL DP or AIA are not expected to use CRL or OCSP for revocation status validation. In this case, one of the last three selections is claimed and the basis for invalidating certificates is explained in the assignment. In many of these cases, revocation status for the issuing CA certificates is depended on to indicate the status of leaf certificates, so it is preferred that CRL or OCSP is claimed even if leaf certificates exclusively use alternative methods. It is acceptable to include such intermediate certificates in trust stores to avoid the requirement to check revocation status when connections to obtain certificate status information are not available. The ST author claims the supported options the TSF uses to ensure that supported functions obtain revocation status information. These options must be consistent with the rules for revocation status checking claimed in FIA_X509_EXT.1.1. It is preferred, but not required, that multiple methods are claimed to ensure valid revocation is available when a supported function requires it. If the option to not obtain revocation status information due to the TSF determining that supported functions perform revocation checking is claimed, the ST author specifies the specific functions from FIA_X509_EXT.2 that perform revocation status checking and the methods used by the function, including the relevant SFR references). It is required that at least one option is supported for each supported function indicated in FIA_X509_EXT.2. 'Network connection...' is claimed if the TOE supports retrieving revocation status information from external sources, to include direct information from a CA, even when the information might not be in the form of a CRL or OCSP. The selection indicates the types of sources for which external revocation status is supported. This method must be claimed if certificates are obtained from external CAs. 'Local revocation status information...' is only claimed if the TOE maintains revocation status information available to all supported functions using the certificates. The type of status information maintained locally is claimed in the selection for this option. If ‘embedded CA repository’ is claimed, FDP_CER_EXT.1/OLTleaf and FDP_CSIR_EXT.1 are also claimed. When a default status value is configured for when all other sources are not available, the ST author claims local revocation status information and administrator configuration. OCSP stapling or OCSP multi-stapling are claimed for TLS server certificates supporting the appropriate extensions when OCSP is supported, as described in the referenced RFC and may be claimed if FIA_X509_EXT.2 indicates support TLS or DTLS. The ST author claims whether the TSF processes trust store rules or passes context to the supported function. If the TSF processes trust store context rules, the ST author describes the application context for each supported trust store, if any. Such rules include the interpretation of extensions in a root CA certificate used as a trust store element, the interpretation of required extensions in intermediate CA certificates, and required extensions in the leaf certificate, with interpretations (referenced RFC and/or refined use) on how such extensions and their values limit the applicability of a certification path, any initial name constraints (including reference IDs processed as part of path validation), expected certificate policies, etc. The ST author claims "extendedKeyUsage field..." if context depends on the value of the EKU in leaf certificates. This selection is required if the TSF supports the listed functions (Code integrity, OCSP, TLS, DTLS, SMIME), as claimed in FIA_X509_EXT.2.1 or as required in other SFRs in this package. For example, RA purpose is required if FDP_CER_EXT.1/OLTleaf is claimed and a supported certificate request protocol (EST, CMC, or v3 CMP) uses the RA EKU purpose to determine RA privileges associated with a supported function. It is preferred, but not required that each function using certificates indicated in FIA_X509_EXT.2.1 include context information that distinguishes certificates intended for use by the function. While RFC 5280 generally allows the use of ‘anyPurpose’ it indicates that applications may require explicit values. This element clarifies the requirement that certificates without an EKU field or with the ‘anyPurpose’ OID in lieu of the required explicit value are considered invalid if used for applications for which an explicit EKU value is required. The ST author claims ‘pass context information to the supported function’ and the final option in the last selection to describe certification path context information passed to the supported function. Context information can be the entire certification path used, or specific context (name constraints, policy constraints etc.) made available to the function for its own suitability decision. Any context information derived from certification path processing by the TSF that is passed to the supported function, to include the certification path processing and the resulting context, is described in the assignment. The option to pass information is not to be claimed in lieu of processing the required extendedKeyUsage fields for supported functions unless the ST of the function supported includes the required context processing. The ST author claims ‘manage trust stores’ if the TSF provides a management capability for trust stores that terminate the certification paths used by TOE functions, regardless of whether or not the TSF uses platform functionality to perform the management. FIA_TSM_EXT.1 is included in this case. If all management of trust stores is performed by the platform, the ST author claims ‘use platform-managed trust stores.’ The evaluator shall review the TSS and verify that the description of certificate path validation and context verification meets the requirements. The evaluator shall review the TSS and verify that all trust stores used for certification path verification are described, to include context associated with the trust store, and any pre-loaded trust store elements, and that the management capabilities associated with each trust store is described. The evaluator shall ensure that instructions for any configurable features of the validation process are included. If the ST includes provisions for exception processing of certificate revocation status information, the evaluator shall ensure the operational guidance contains instructions on how the indicated options are configured. If the TOE supports any extension that requires configuration to validate, the evaluator shall verify that the operational guidance includes instructions for configuring the processing of that extension. The evaluator shall perform the following tests. The tests for the extendedKeyUsage rules, name constraints and policy constraints, if supported, are performed in conjunction with the uses that require those rules. The evaluator shall demonstrate that validating a certificate without a valid certification path results in the function failing by performing the following: [conditional] If the TSF imposes limits on certification path lengths, the evaluator shall demonstrate that the TSF rejects valid certificates whose certification path exceeds the supported length. [conditional] If the TSF supports a path length greater than one when the trust store element is a root CA certificate, or greater than two when the trust store element is a raw public key, then the evaluator shall perform the following: The evaluator shall establish a certification path in which one of the issuing certificates is not a CA certificate by omitting the basicConstraints field in one of the issuing certificates and demonstrate that the TSF rejects the certificate. The evaluator shall set the basicConstraints field in an issuing certificate to have CA=False and demonstrate that the TSF rejects the certificate. The evaluator shall omit the CA signing bit of the key usage field in an issuing certificate and demonstrate that the TSF rejects the certificate. The evaluator shall set the path length field of a valid CA field to a value strictly less than the certification path and demonstrate that the TSF rejects the certificate. The evaluator shall establish a valid certification path consisting of a leaf certificate and one or more valid CA certificates up to the limit of the certification path length supported (if finite), and terminating in a trust store element, and demonstrate that the TSF accepts the certification path as valid. The evaluator shall then modify a byte in the public key of an intermediate certificate in the certificate path that is not a trust store element and demonstrate that the TSF rejects the leaf certificate and its modified certification path. The evaluator shall establish a certification path terminating at an untrusted public key, but which is otherwise valid, and demonstrate that the TSF rejects the certificate. The evaluator then reinstate trust in the trust store element, but modify a byte in the public key of an intermediate certificate in the certificate path that is not a trust store element and show that the function fails. [conditional]: If the TSF does not support unlimited path length, the evaluator shall demonstrate that validating a valid certificate path of greater length than the TSF supports results in the function failing. The evaluator shall demonstrate that a valid certificate path using cryptographic algorithms not allowed for certification path signature functions results in the function failing. Note: If the TSF supports signature and hash algorithms for TOE functions, but disallows their use in certification path validation, the evaluator uses one of these signatures or hashes in the construction of the valid certificate path (e.g., SHA-1 might be so restricted). If there are no such signature or hash functions, the evaluator uses an unsupported signature or hash function (e.g., DSA and MD-5 are not supported). The evaluator shall demonstrate that validating a certificate after its validity period's "notAfter" time results in the function failing. The evaluator shall demonstrate that validating a certificate prior to its validity period's "notBefore" time results in the function failing. [conditional]: If the TSF supports certificate policies, the evaluator configures the TSF to require a specific policy OID, and demonstrates that a valid certificate path asserting the policy OID results in the function succeeding, and a valid certification path not asserting that policy (or a policy that maps to it) results in the function failing. Note: The policy OID used in the test need not be associated with specific practices of any CA - only the processing and matching of the OIDs is required. [conditional]: If the TSF supports certificate policies and policy mapping, the evaluator configures the TSF to require a specific policy OID that is mapped to an expected policy. The evaluator demonstrates that a valid certification path that asserts the policy OID and includes the mapping to the expected policy results in the function succeeding, and that a certification path that asserts the policy OID, but not the proper mapping results in the function failing. Note: The policy OID used in the test need not be associated with specific practices of any CA - only the processing and matching of the OIDs is required. [conditional]: If the TSF supports other extensions, for each supported extension, the evaluator establishes a certification path which asserts the extension and value expected by the function, and demonstrates that the function succeeds. The evaluator then establishes, in turn as applicable, a certification path without the extension, and a certification path with the extension but with an invalid value, and demonstrates that the function requiring such extension and values fails. The evaluator demonstrates that a certification path with a critical extension that is not supported by the TSF results in the function failing. Note: The extension used in this test need not be registered in IANA TLS Security extensions (Transport Layer Security (TLS) Extensions (iana.org)) The evaluator shall test that the TOE can properly handle supported methods for revoked certificates. The evaluator demonstrates that when all supported methods indicate that each certificate in the certification path is valid, the function succeeds. Then, for each supported method, the evaluator demonstrates that when the method indicates a certificate in the certification path is revoked, the function fails. The evaluator shall repeat this test on intermediate, non-trust store elements. [conditional]: If the TSF supports OCSP or CRL, the evaluator shall demonstrate that the TSF does not consider invalid revocation information in determining the status of a certification path. The evaluator shall test for invalid signature, and unauthorized signer of the status information for each of the supported OCSP or CRL methods, where the invalid status information indicates valid and other status information indicates invalid; and where the invalid status information indicates invalid and other status information indicates valid. Other status information can be the most recent cached information, or that from another supported method – when both OCSP and CRL are supported one can provide invalid status information and the other provide valid status information. Note: an invalid signature can be obtained by modifying a byte of a valid signature; unauthorized signers use valid signatures by an entity not authorized (not delegated by the issuing CA, and if local OCSP responders are supported, not locally trusted) to sign revocation status information. [conditional]: If the TSF supports validity status determination based on expiration within a short time and at least one other method, the evaluator will demonstrate that expiration time is not considered when another method is available and provides valid status information – the evaluator demonstrates that certification path including a soon-to-expire certificate that has been revoked results in the function failing. [conditional]: If the TSF supports multiple revocation status information sources, then for each supported source of revocation status information, the evaluator demonstrates certificate status information resilience by making all but the one source of supported revocation status information unavailable to the TSF. The evaluator demonstrates that the TSF is able to use the available status information. [conditional: If a function in FIA_X509_EXT.2 requires TSF processing of context information for path validation] For each supported function requiring TSF processing context information, and for each supported certificate context and usage constraint claimed, the evaluator shall demonstrate that a certification path that does not meet the context constraints required by the function causes the function to fail. Note: This test is not performed if ‘pass context information to the supported function’ is the only method of certification path context processing claimed. The evaluator shall establish a certificate with an empty subject field and not containing a subjectAltName extension, but which is otherwise valid and trusted by the TSF. The evaluator shall demonstrate that the TSF rejects the certificate. [conditional]: If certificates with non-empty subject fields are validated and if either name constraints processing is supported or one or more reference ID checking rules are included in trust store context rules, then for each RDN supported, the evaluator shall configure the TOE to enforce a rule on the RDN value, establish a value for the RDN that matches the rule, and perform the following steps: The evaluator shall present a valid certificate containing a valid DN with the matching RDN value to the supported function and verify that the certificate is accepted. The evaluator shall then present a second certificate where the RDN component does not match the rule, but which is otherwise valid and matches the first certificate. The evaluator shall observe that the certificate is rejected. The evaluator shall present a third certificate, where the DN includes the RDN with a non-matching value as in the second certificate, but which also includes a non-supported (or undefined) RDN term populated with the matching value for the original RDN, and which is otherwise valid and matches the first certificate and demonstrate that the modified certificate is rejected. The evaluator shall present a fourth certificate, where the DN does not include the RDN, but which includes an unsupported (or undefined) RDN with the matching value for the original RDN as in the third certificate, but which is otherwise valid and demonstrate that the modified certificate is rejected. The evaluator shall present a fifth certificate where the DN includes the RDN with a value containing the matching value as a substring of a longer, non-matching value, but which is otherwise valid and demonstrate that the modified certificate is rejected. The evaluator shall present a sixth certificate where the DN includes the RDN as a multi-element RDN, where both elements contain matching values, but which is otherwise valid and observe that the certificate is rejected. [conditional]: If the subject_Alt_Name extension is supported and if the TSF either supports name constraints or reference ID matching as part of trust store context rules, then for each name type supported, the evaluator shall configure the TSF to enforce a rule to constrain the values of the name type, and generate a matching value that meets the constraints, as well as a non-matching value that does not meet the constraints. The evaluator shall then perform the following: The evaluator shall establish a valid certificate that includes the SAN name of the given type and matching value. The evaluator shall present the certificate to a supported function and demonstrate that the certificate is accepted. The evaluator shall establish a second certificate that includes the SAN name of the given type and non-matching value. The evaluator shall present the certificate to a supported function and demonstrate that the certificate is rejected. [conditional]: If the TSF also supports a CN in the subject field, the evaluator shall configure the TSF as necessary to prefer SAN entries over the CN and establish a valid certificate which contains both a subject field including the non-matching value as a CN entry, and the matching value as the SAN entry. The evaluator shall present the certificate to the supported function and demonstrate that the certificate is accepted. The evaluator shall then establish a certificate with the matching name in the CN, and the non-matching name in the SAN entry, but which is otherwise valid. The evaluator shall present the certificate to a supported function and demonstrate that the certificate is rejected. Unsuccessful attempt to validate a certificate Reason for failure of certificate validation requires the TSF to use certificates to authenticate peers in protocols that support certificates, as well as for integrity verification and potentially other functions that require certificates. No specific management functions are identified. FIA_X509_EXT.1 X.509 Certificate Validation FIA_XCU_EXT.1 X.509 Certificate Utilization The ST author lists all supported functions that depend on identities associated with certificates in the assignment. For each such function, the ST author claims the protocols and services used by the supported functions that require certificates. When multiple methods of revocation status information are available, it is expected that the aggregate reliability of supported methods will limit the use of exception processing. However, it is required that the TOE have a specified behavior in case all status information options are either invalid or not available. This behavior may be specific to certain trust stores or supported functions. It is strongly encouraged that ‘certificate is accepted’ not be claimed for client authentication and more generally when reliable revocation status checks are available. For supported functions where external certificate revocation status information is not expected to be available such as firmware updates or initial network connections for the TSF that cannot establish a network connection, best practice is to use certificates that do not advertise CRL or OCSP locations, and instead support alternate revocation status verification methods. The option ‘supported function determines acceptance...’ is claimed when the supported function determines revocation status exceptions, for example, by presenting an option to the authorized user of the function, or when the function validates the status of intermediate CA or leaf certificates included in a trust store at times other than when used. In such cases, the ST author describes the methods used in the assignment. The treatment of invalid revocation status information should not impact the validity of a certificate if other revocation status information is available. It is expected that processing invalid revocation status information is logged. The evaluator shall review the TSS to validate that all functions using certificates are described and that function-specific exception processing rules for handling unavailable valid certificate status information is included. [conditional]: If “administrator is allowed to configure certificate acceptance” is claimed, the evaluator shall inspect the guidance documentation to ensure instructions for configuring application-specific behavior for certificate validation is included. [conditional]: If application-specific default responses for inaccessible certificate status information are supported, then for each function supporting such defaults, the evaluator shall configure a default behavior as necessary for each such response, clear or disable all sources of revocation information available to the function, and establish a certification path that requires an external source for certificate status information. The evaluator shall demonstrate that the TSF exhibits the default behavior when presented with the certification path. Note: This test is only required if the default mechanism is not included as a local revocation status information method in requires the TSF to be able to generate Certificate Request Messages and validate responses. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Certificate requested Valid certificate received Invalid certificate received FCS_CKM.1 Cryptographic Key Generation FIA_X509_EXT.1 X.509 Certificate Validation FIA_X509_EXT.2 X.509 Certificate Support for Functions FIA_XCU_EXT.1 X.509 Certificate Utilization The supported certificate request mechanisms are claimed in the first selection. PKCS-10 is claimed whether a manual request process is used or if the PKCS-10 request is posted to the certification authority (for embedded CAs or as in ACME implementations). Other options embed the certificate request in a formalized certificate management protocol. If EST is claimed, FIA_ESTC_EXT.1 is also claimed; if CMC or CNSA CMC are claimed, FIA_CMCC_EXT.1 is also claimed; if v2 or v3 CMP is claimed, FIA_CMPC_EXT.1 is also claimed. The certificate path returned should include the CA from which the certificate was requested as the issuing CA and may include intermediate CAs, terminating at a trust store element. The context of the certificate path includes context specified by the trust store and refined by name constraint extensions, policy-related extensions, and other extensions present in the intermediate CA certificates, as well as the extensions in the requested certificate. Since the extensions in the Intermediate CA certificates are not specified in the request, the TSF should perform checks to ensure they do not modify or prohibit the intended use. Also, some extensions present in the requested certificate may be populated by the issuing CA that were different than those requested (due to error, or by policy). The TSF can identify those differences automatically, or present any questionable values for review by an authorized user before installing the certificate. The evaluator shall review the TSS to confirm that it describes the options to obtain certificates representing a TOE function. Note: All certificates obtained from external CAs or from an embedded CA that supports formal requests are included. It is not necessary that certificates obtained from an embedded CA that are only locally trusted by the TOE to represent TOE functionality within the TOE are requested using standard techniques. The evaluator shall examine the operational guidance documentation and confirm that it contains instructions for obtaining a certificate for TOE functions using the supported options, for configuring the subject name type included in a request, for configuring the name representing the TOE function and any other extensions to be included in the certificate. The evaluator shall inspect the AGD documentation to ensure instructions for configuring application-specific behavior for certificate validation is included. For each certificate required to represent a TOE function, for each name type supported, and for each request option supported for that function, the evaluator shall configure the TOE function name of the selected type and any extensions required by the function and request a certificate using the request method. The evaluator shall observe that the certificate received by the TOE is validated and represents the TOE function. Certificate requested Certificate to be signed Valid certificate received None Invalid certificate received Reason for failure Components in this family define how the TSF handles X.509 certificates for specific functions for specific protocols. defines how the TSF verifies or uses X.509 certificates. No specific management functions are identified. There are no auditable events foreseen. The ST author claims "verify" when the TOE associates identities included in X.509 certificates with users, external entities or inter-TOE entities authorized to exercise TOE functionality. The ST author claims "assert" when the TOE represents itself or its functions to internal or external entities. If "verify" is selected, then FIA_X509_EXT.1 and FIA_X509_EXT.2 must be included. If "assert" is selected, FIA_XCU_EXT.2 must be included. The evaluator shall review the TSS and verify that the "verify" and "assert" claims are consistent with those selected in the SFR. There are no guidance EAs for this component. There are no test EAs for this component. defines how the TSF requests or obtains certificates to represent specific functions for specific protocols. No specific management functions are identified. There are no auditable events foreseen. FIA_X509_EXT.1 X.509 Certificate Validation FIA_XCU_EXT.1 X.509 Certificate Utilization The ST author claims the method for obtaining certificates and the source of certificates, and describes the functions represented and how the functions use certificates. The ST author claims ‘request certificates…’ if certificates are requested using standard request formats or protocols, and FIA_X509_EXT.3 is also claimed. If ‘embedded CA’ is claimed in the sub-selection, then FDP_CER_EXT.1/OLTleaf and FDP_CER_EXT.2 are also claimed. If ‘obtain certificates from an embedded certification authority’ is claimed, FDP_CER_EXT.1/OLTleaf is claimed. The use of embedded CAs is constrained to only locally trusted functions. That is, the relying party for a certificate issued by the embedded CA is limited to TOE functions. In practice, this limitation typically precludes privileged users from using certificates issued by an embedded CA, especially in environments where administrative access to systems (including both TOE functions and non-TOE functions) is governed by an identity management policy. So, while not mandatory, it is strongly recommended that ‘external’ CA is claimed, and that all functions that provide person-entity authentication to privileged TOE functions support certificate requests to an external CA. The evaluator shall review the ST and confirm that the methods for obtaining certificates for representing its supported functions are described. There are no guidance EAs for this component. There are no test EAs for this component. RFC 2986 PKCS #10: Certification Request Syntax Specification Version 1.7 RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile RFC 6066 Transport Layer Security (TLS) Extensions: Extension Definitions RFC 6960 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP RFC 6961 The Transport Layer Security (TLS) Multiple Certificate Status Request Extension RFC 7030 Enrollment over Secure Transport RFC 8603 Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile