Version | Date | Comment |
---|---|---|
1.0 | 2024-07-26 | Initial draft. |
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.
Assurance | Grounds for confidence that a TOE meets the SFRs [CC]. |
Base Protection Profile (Base-PP) | Protection Profile used as a basis to build a PP-Configuration. |
Collaborative Protection Profile (cPP) | A Protection Profile developed by international technical communities and approved by multiple schemes. |
Common Criteria (CC) | Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408). |
Common Criteria Testing Laboratory | Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations. |
Common Evaluation Methodology (CEM) | Common Evaluation Methodology for Information Technology Security Evaluation. |
Distributed TOE | A TOE composed of multiple components operating as a logical whole. |
Functional Package (FP) | A document that collects SFRs for a particular protocol, technology, or functionality. |
Operational Environment (OE) | Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy. |
Protection Profile (PP) | An implementation-independent set of security requirements for a category of products. |
Protection Profile Configuration (PP-Configuration) | A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module. |
Protection Profile Module (PP-Module) | An implementation-independent statement of security needs for a TOE type complementary to one or more Base-PPs. |
Security Assurance Requirement (SAR) | A requirement to assure the security of the TOE. |
Security Functional Requirement (SFR) | A requirement for security enforcement by the TOE. |
Security Target (ST) | A set of implementation-dependent security requirements for a specific product. |
Target of Evaluation (TOE) | The product under evaluation. |
TOE Security Functionality (TSF) | The security functionality of the product under evaluation. |
TOE Summary Specification (TSS) | A description of how a TOE satisfies the SFRs in an ST. |
Authority Key Identifier | A certificate extension that provides a means of identifying the public key corresponding to the private key used to sign a certificate or CRL. |
Certificate Revocation List (CRL) | 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. |
Certificate Signing Request (CSR) | A message that a subject sends to a certification authority to apply for a digital certificate. |
Certification Authority (CA) | An entity that is responsible for the issuance and maintenance of digital certificates. |
Distinguished Name (DN) | A unique identifier for a subject. |
Enrollment over Secure Transport (EST) | A method of certificate management that uses HTTPS to transmit certificate requests and responses. |
OCSP Multi-Stapling | 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. |
OCSP Stapling | An expedited version of OCSP where the CA includes an assertion of a leaf certificate's validity as part of a connection handshake. |
Object Identifier (OID) | A numeric string that uniquely represents object types in certificates. |
Online Certificate Status Protocol (OCSP) | 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. |
Public Key Infrastructure (PKI) | 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. |
Registration Authority (RA) | An optional component of public key infrastructure to which a CA can delegate certain management functions. |
Subject Alternative Name (SAN) | A certificate extension that allows identities to be bound to the subject of a digital certificate. |
Subject Key Identifier | A certificate extension that provides a means of identifying certificates that contain a particular public key. |
basicConstraints | 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. |
extendedKeyUsage (EKU) | 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. |
pathLen | An attribute of CA certificates that specifies the maximum length of a certificate chain that terminates with that certificate. |
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:
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:
This FP describes the extended security functionality of X.509 in terms of [CC].
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.
Component | Explanation |
---|---|
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. |
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.
|
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.
|
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 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.
Requirement | Auditable Events | Additional Audit Record Contents |
---|---|---|
FIA_XCU_EXT.1 | ||
No events specified | N/A |
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 “subjectAlternateName” 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.
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 FDP_CER_EXT.1.2/OLTleaf), 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).
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 FDP_CER_EXT.2 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 FDP_CSIR_EXT.1.1. The method of validating a request is specific to the request method. If ‘An EST request…’ is claimed, FIA_ESTS_EXT.1 is also claimed; If ‘A CMC request…’ is claimed, FIA_CMCS_EXT.1 is also claimed. If ‘A CMP request…’ is claimed, FIA_CMPS_EXT.1 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.
This requirement should be claimed if 'ITU-T Recommendation X.509v2 CRL' is selected in FDP_CSI_EXT.1.1.
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 2048-bit RSA or higher, or ECDSA using NIST P-256, 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.
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 FDP_CSI_EXT.1.1, then ‘posting CRLs at… cRLDistributionPoints…’ is claimed in FDP_CSI_EXT.1.3 and ‘cRLDistributionPoints’ is claimed in FDP_CER_EXT.1.2/OLTleaf.
If the OCSP standard is selected in FDP_CSI_EXT.1.1, 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 FDP_CSI_EXT.1.3.
If ‘OCSP mechanism…in the authorityInfoAccess…’ is claimed in FDP_CSI_EXT.1.3, then ‘authorityInfoAccess’ must be claimed in FDP_CER_EXT.1.1/OLTleaf.
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 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 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 subjectAlternateName as the certificate being renewed; if the TSF does not possess such a certificate, this option is not claimed.
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 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.
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.
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 is associated with an EKU. 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.
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 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 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.
Functional Class | Functional Components |
---|---|
Identification and Authentication (FIA) | Trust Store Management FIA_CMCC_EXT CMC Client Certificate Enrollment FIA_CMCS_EXT Certificate Management over CMS (CMC) Server FIA_CMPC_EXT CMP Certificate Enrollment FIA_CMPS_EXT Certificate Management Protocol (CMP) Server FIA_ESTC_EXT EST Certificate Enrollment FIA_ESTS_EXT Enrollment over Secure Transport (EST) Server FIA_X509_EXT X.509 Certificate Handling FIA_XCU_EXT Certificate Usage |
User Data Protection (FDP) | FDP_CER_EXT Certificate Generation and Issuance FDP_CRL_EXT Certificate Revocation List Generation FDP_CSIR_EXT Certificate Status Information Required FDP_CSI_EXT Certificate Status Information Generation FDP_OCSP_EXT OCSP Basic Response Generation |
FIA_CMCC_EXT.1, CMC Client Certificate Enrollment, 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:
Hierarchical to: | No other components. |
Dependencies to: |
FIA_X509_EXT.3 X.509 Certificate Requests FMT_SMR.1 Security Roles FTP_PRO.1 Trusted Channel Protocol FTP_PRO.2 Trusted Channel Establishment FTP_PRO.3 Trusted Channel Data Protection FTP_ITC.1 Inter-TSF Trusted Channel |
FIA_CMCS_EXT.1, Certificate Management over CMS (CMC) Server, 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:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FDP_CER_EXT.2 Certificate Request Matching FPT_STM.1 Reliable Time Stamps FTP_PRO.1 Trusted Channel Protocol FTP_PRO.2 Trusted Channel Establishment FTP_PRO.3 Trusted Channel Data Protection FTP_ITC.1 Inter-TSF Trusted Channel |
FIA_CMPC_EXT.1, CMP Certificate Enrollment, 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:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FIA_X509_EXT.3 X.509 Certificate Requests FTP_PRO.1 Trusted Channel Protocol FTP_PRO.2 Trusted Channel Establishment FTP_PRO.3 Trusted Channel Data Protection FTP_ITC.1 Inter-TSF Trusted Channel |
FIA_CMPS_EXT.1, Certificate Management Protocol (CMP) Server, 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:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FDP_CER_EXT.2 Certificate Request Matching FPT_STM.1 Reliable Time Stamps FTP_PRO.1 Trusted Channel Protocol FTP_PRO.2 Trusted Channel Establishment FTP_PRO.3 Trusted Channel Data Protection FTP_ITC.1 Inter-TSF Trusted Channel |
FIA_ESTC_EXT.1, EST Client Certificate Enrollment, 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:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FDP_CER_EXT.2 Certificate Request Matching FPT_STM.1 Reliable Time Stamps FTP_PRO.1 Trusted Channel Protocol FTP_PRO.2 Trusted Channel Establishment FTP_PRO.3 Trusted Channel Data Protection FTP_ITC.1 Inter-TSF Trusted Channel |
FIA_ESTS_EXT.1, Enrollment over Secure Transport (EST) Server, 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:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FDP_CER_EXT.2 Certificate Request Matching FMT_SMR.1 Security Roles FPT_STM.1 Reliable Time Stamps FTP_PRO.1 Trusted Channel Protocol FTP_PRO.2 Trusted Channel Establishment FTP_PRO.3 Trusted Channel Data Protection FTP_ITC.1 Inter-TSF Trusted Channel |
FDP_CER_EXT.1, Leaf Certificate Profiles, requires the TSF to implement a TOE-trusted certificate profile function that conforms to profiles when acting as a CA.
FDP_CER_EXT.2, Certificate Request Matching, 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
FDP_CRL_EXT.1, Certificate Revocation List Generation, requires the TSF to include specific information in any certificate revocation lists that it creates.
FDP_CSIR_EXT.1, Certificate Status Information Required, 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.
FDP_CSI_EXT.1, Certificate Status Information Generation, requires the TSF to generate certificate status information using a supported method and to define conditions in which this information can be modified.
FDP_OCSP_EXT.1, OCSP Basic Response Generation, requires the TSF to include specific information in any OCSP response that it creates.
FIA_CMCC_EXT.1, CMC Client Certificate Enrollment, requires the TSF to generate, export, import, and transport CMC requests that meet client and end-entity compliance requirements.
FIA_CMCS_EXT.1, Certificate Management over CMS (CMC) Server, requires the TSF to accept, process, and send CMC requests that meet CMS server and CA requirements.
FIA_CMPC_EXT.1, CMP Certificate Enrollment, requires the TSF to generate, export, import, and transport CMP requests that meet subject and end-entity compliance requirements.
FIA_CMPS_EXT.1, Certificate Management Protocol (CMP) Server, requires the TSF to receive, process, and respond to CMP requests from authorized clients and RAs.
FIA_ESTC_EXT.1, EST Client Certificate Enrollment, defines the ability of the TSF to perform Enrollment over Secure Transport (EST) as a client connecting to an external CA.
FIA_ESTS_EXT.1, Enrollment over Secure Transport (EST) Server, defines the ability of the TSF to perform Enrollment over Secure Transport (EST) as a server connecting to an external CA.
FIA_TSM_EXT.1, Trust Store Management, defines the ability of the TSF to manage trust stores using a specified option to validate certificates.
FIA_X509_EXT.1, X.509 Certificate Validation, requires the TSF to check and validate certificates in accordance with the RFCs and rules specified in the component.
FIA_X509_EXT.2, X.509 Certificate Support for Functions, 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.
FIA_X509_EXT.3, X.509 Certificate Requests, requires the TSF to be able to generate Certificate Request Messages and validate responses.
FIA_XCU_EXT.1, Implementation of X.509 Functions, defines how the TSF verifies or uses X.509 certificates.
FIA_XCU_EXT.2, X.509 Certificate Acquisition, defines how the TSF requests or obtains certificates to represent specific functions for specific protocols.
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:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_CKM.1 Cryptographic Key Generation FCS_COP.1 Cryptographic Operation FMT_SMR.1 Security Roles |
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:
Hierarchical to: | No other components. |
Dependencies to: |
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] |
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:
Hierarchical to: | No other components. |
Dependencies to: | FCS_COP.1 Cryptographic Operation |
No specific management functions are identified.
There are no auditable events foreseen.
Hierarchical to: | No other components. |
Dependencies to: |
No specific management functions are identified.
There are no auditable events foreseen.
Hierarchical to: | No other components. |
Dependencies to: |
[FDP_CRL_EXT.1 Certificate Revocation List Generation OR FDP_OCSP_EXT.1 OCSP Basic Response Generation] FMT_SMR.1 Security Roles |
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:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FPT_STM.1 Reliable Time Stamps |
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:
Hierarchical to: | No other components. |
Dependencies to: |
FIA_X509_EXT.3 X.509 Certificate Requests FMT_SMR.1 Security Roles FTP_PRO.1 Trusted Channel Protocol FTP_PRO.2 Trusted Channel Establishment FTP_PRO.3 Trusted Channel Data Protection FTP_ITC.1 Inter-TSF Trusted Channel |
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:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FDP_CER_EXT.2 Certificate Request Matching FPT_STM.1 Reliable Time Stamps FTP_PRO.1 Trusted Channel Protocol FTP_PRO.2 Trusted Channel Establishment FTP_PRO.3 Trusted Channel Data Protection FTP_ITC.1 Inter-TSF Trusted Channel |
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:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FIA_X509_EXT.3 X.509 Certificate Requests FTP_PRO.1 Trusted Channel Protocol FTP_PRO.2 Trusted Channel Establishment FTP_PRO.3 Trusted Channel Data Protection FTP_ITC.1 Inter-TSF Trusted Channel |
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:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FDP_CER_EXT.2 Certificate Request Matching FPT_STM.1 Reliable Time Stamps FTP_PRO.1 Trusted Channel Protocol FTP_PRO.2 Trusted Channel Establishment FTP_PRO.3 Trusted Channel Data Protection FTP_ITC.1 Inter-TSF Trusted Channel |
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:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FDP_CER_EXT.2 Certificate Request Matching FPT_STM.1 Reliable Time Stamps FTP_PRO.1 Trusted Channel Protocol FTP_PRO.2 Trusted Channel Establishment FTP_PRO.3 Trusted Channel Data Protection FTP_ITC.1 Inter-TSF Trusted Channel |
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:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FDP_CER_EXT.2 Certificate Request Matching FMT_SMR.1 Security Roles FPT_STM.1 Reliable Time Stamps FTP_PRO.1 Trusted Channel Protocol FTP_PRO.2 Trusted Channel Establishment FTP_PRO.3 Trusted Channel Data Protection FTP_ITC.1 Inter-TSF Trusted Channel |
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:
Hierarchical to: | No other components. |
Dependencies to: |
FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security Roles |
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:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FIA_XCU_EXT.1 X.509 Certificate Utilization |
No specific management functions are identified.
There are no audit events foreseen.
Hierarchical to: | No other components. |
Dependencies to: |
FIA_X509_EXT.1 X.509 Certificate Validation FIA_XCU_EXT.1 X.509 Certificate Utilization |
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:
Hierarchical to: | No other components. |
Dependencies to: |
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 |
No specific management functions are identified.
There are no auditable events foreseen.
Hierarchical to: | No other components. |
Dependencies to: |
No specific management functions are identified.
There are no auditable events foreseen.
Hierarchical to: | No other components. |
Dependencies to: |
FIA_X509_EXT.1 X.509 Certificate Validation FIA_XCU_EXT.1 X.509 Certificate Utilization |
FIA_X509_EXT.1, X.509 Certificate Validation, requires the TSF to check and validate certificates in accordance with the RFCs and rules specified in the component.
FIA_X509_EXT.2, X.509 Certificate Support for Functions, 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.
FIA_X509_EXT.3, X.509 Certificate Requests, 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:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FIA_XCU_EXT.1 X.509 Certificate Utilization |
No specific management functions are identified.
There are no audit events foreseen.
Hierarchical to: | No other components. |
Dependencies to: |
FIA_X509_EXT.1 X.509 Certificate Validation FIA_XCU_EXT.1 X.509 Certificate Utilization |
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:
Hierarchical to: | No other components. |
Dependencies to: |
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 |
FIA_XCU_EXT.1, Implementation of X.509 Functions, defines how the TSF verifies or uses X.509 certificates.
FIA_XCU_EXT.2, X.509 Certificate Acquisition, 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.
Hierarchical to: | No other components. |
Dependencies to: |
No specific management functions are identified.
There are no auditable events foreseen.
Hierarchical to: | No other components. |
Dependencies to: |
FIA_X509_EXT.1 X.509 Certificate Validation FIA_XCU_EXT.1 X.509 Certificate Utilization |
FDP_CER_EXT.1, Leaf Certificate Profiles, requires the TSF to implement a TOE-trusted certificate profile function that conforms to profiles when acting as a CA.
FDP_CER_EXT.2, Certificate Request Matching, 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:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_CKM.1 Cryptographic Key Generation FCS_COP.1 Cryptographic Operation FMT_SMR.1 Security Roles |
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:
Hierarchical to: | No other components. |
Dependencies to: |
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] |
FDP_CRL_EXT.1, Certificate Revocation List Generation, 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:
Hierarchical to: | No other components. |
Dependencies to: | FCS_COP.1 Cryptographic Operation |
FDP_CSIR_EXT.1, Certificate Status Information Required, 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.
Hierarchical to: | No other components. |
Dependencies to: |
FDP_CSI_EXT.1, Certificate Status Information Generation, 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.
Hierarchical to: | No other components. |
Dependencies to: |
[FDP_CRL_EXT.1 Certificate Revocation List Generation OR FDP_OCSP_EXT.1 OCSP Basic Response Generation] FMT_SMR.1 Security Roles |
FDP_OCSP_EXT.1, OCSP Basic Response Generation, 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:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FPT_STM.1 Reliable Time Stamps |
Acronym | Meaning |
---|---|
Base-PP | Base Protection Profile |
CA | Certification Authority |
CC | Common Criteria |
CEM | Common Evaluation Methodology |
CMC | Certificate Management over CMS |
CMS | Cryptographic Message Syntax |
cPP | Collaborative Protection Profile |
CRL | Certificate Revocation List |
CSR | Certificate Signing Request |
DN | Distinguished Name |
EA | Evaluation Activity |
EC | Elliptic Curve |
EKU | extendedKeyUsage |
EST | Enrollment over Secure Transport |
FP | Functional Package |
HTTP | Hypertext Transfer Protocol |
HTTPS | Hypertext Transfer Protocol Secure |
ITU-T | International Telecommunication Union Telecommunication Standardization Sector |
OCSP | Online Certificate Status Protocol |
OE | Operational Environment |
OID | Object Identifier |
OS | Operating System |
PKI | Public Key Infrastructure |
PP | Protection Profile |
PP-Configuration | Protection Profile Configuration |
PP-Module | Protection Profile Module |
RA | Registration Authority |
RBG | Random Bit Generator |
RFC | Request for Comment |
SAN | Subject Alternative Name |
SAR | Security Assurance Requirement |
SFR | Security Functional Requirement |
ST | Security Target |
TLS | Transport Layer Security |
TOE | Target of Evaluation |
TSF | TOE Security Functionality |
TSFI | TSF Interface |
TSS | TOE Summary Specification |