Protection Profile for Certification Authorities

Version: 3.0
2025-06-13
National Information Assurance Partnership

Revision History

Version	Date	Comment
1.0	2014-05-16	Initial draft
1.1	2016-07-07	Formatting updates and changes based on TC feedback
1.2	2016-10-26	Updates based on additional TC feedback and internal review
2.0	2016-10-28	Second draft
2.1	2017-12-01	Updates based on first use in evaluation
2.1x	2020-07-10	Converted to XML
3.0	2025-06-13	Conversion to CC:2022, Incorporation of NIAP TDs

1Introduction 1.1Overview 1.2Terms 1.2.1Common Criteria Terms 1.2.2Technical Terms 1.3Compliant Targets of Evaluation 1.3.1TOE Boundary 1.4Use Cases 1.5Product Features Mapped to Implementation-Dependent Requirements 1.5.1TOE Responsible for Protecting Subscriber Information 1.5.2TOE supports Audit Review 1.5.3TSF Supports Audit Pre-Select 1.5.4TSF Supports Storage of Audit Records 2Conformance Claims 3Security Problem Definition 3.1Threats 3.2Assumptions 3.3Organizational Security Policies 4Security Objectives 4.1Security Objectives for the Operational Environment 4.2Security Objectives Rationale 5Security Requirements 5.1Security Functional Requirements 5.1.1Auditable Events for Mandatory SFRs 5.1.2Class: Security Audit (FAU)5.1.3Class: Communications (FCO)5.1.4Class: Cryptographic Support (FCS)5.1.5Class: User Data Protection (FDP)5.1.6Class: Identification and Authentication (FIA)5.1.7Class: Security Management (FMT)5.1.8Class: Protection of the TSF (FPT)5.1.9Class: TOE Access (FTA)5.1.10Class: Trusted Path/Channels (FTP)5.1.11TOE Security Functional Requirements Rationale 5.2Security Assurance Requirements 5.2.1Class ADV: Development 5.2.2Class AGD: Guidance Documentation 5.2.3Class ALC: Life-cycle Support 5.2.4Class ASE: Security Target Evaluation 5.2.5Class ATE: Tests 5.2.6Class AVA: Vulnerability Assessment Appendix A - Optional Requirements A.1Strictly Optional Requirements A.1.1 Auditable Events for Strictly Optional Requirements A.1.2Class: Cryptographic Support (FCS)A.1.3Class: User Data Protection (FDP)A.1.4Class: Protection of the TSF (FPT)A.1.5Class: TOE Access (FTA)A.2Objective Requirements A.2.1 Auditable Events for Objective Requirements A.2.2Class: Cryptographic Support (FCS)A.2.3Class: Identification and Authentication (FIA)A.3Implementation-dependent Requirements A.3.1 Auditable Events for Implementation-dependent Requirements A.3.2Class: Security Audit (FAU)A.3.3Class: Cryptographic Support (FCS)Appendix B - Selection-based Requirements B.1 Auditable Events for Selection-based Requirements B.2Class: Security Audit (FAU)B.3Class: Communications (FCO)B.4Class: Cryptographic Support (FCS)B.5Class: User Data Protection (FDP)B.6Class: Identification and Authentication (FIA)B.7Class: Protection of the TSF (FPT)B.8Class: Trusted Path/Channels (FTP)Appendix C - Extended Component Definitions C.1Extended Components Table C.2Extended Component Definitions C.2.1Class: Communications (FCO)C.2.1.1FCO_NRO_EXT Certificate-Based Proof of Origin C.2.1.2FCO_NRR_EXT Certificate-Based Proof of Receipt C.2.2Class: Cryptographic Support (FCS)C.2.2.1FCS_CDP_EXT Cryptographic Dependencies C.2.2.2FCS_CKM_EXT Cryptographic Key Management C.2.2.3FCS_HTTPS_EXT HTTPS Protocol C.2.2.4FCS_IPSEC_EXT IPsec Protocol C.2.2.5FCS_KSH_EXT Key Sharing C.2.2.6FCS_STG_EXT Cryptographic Key Storage C.2.3Class: Identification and Authentication (FIA)C.2.3.1FIA_CMCC_EXT Certificate Management over CMS Client C.2.3.2FIA_CMCS_EXT Certificate Management over CMS Server C.2.3.3FIA_ENR_EXT Certificate Enrollment C.2.3.4FIA_ESTC_EXT Enrollment over Secure Transport Client C.2.3.5FIA_ESTS_EXT Enrollment over Secure Transport Server C.2.3.6FIA_PMG_EXT Password Management C.2.3.7FIA_PSK_EXT Pre-Shared Key Composition C.2.3.8FIA_UAU_EXT Authentication Mechanism C.2.3.9FIA_UIA_EXT User Identification and Authentication C.2.4Class: Protection of the TSF (FPT)C.2.4.1FPT_APW_EXT Protection of User Password C.2.4.2FPT_KST_EXT No Plaintext Key Export C.2.4.3FPT_NPE_EXT NPE Constraints C.2.4.4FPT_SKP_EXT Protection of Keys C.2.4.5FPT_SKY_EXT Split Knowledge Procedures C.2.4.6FPT_TST_EXT TOE Testing C.2.4.7FPT_TUD_EXT Trusted Update C.2.5Class: Security Audit (FAU)C.2.5.1FAU_ADP_EXT Audit Dependencies C.2.5.2FAU_GCR_EXT Generation of Certificate Repository C.2.5.3FAU_SCR_EXT Certificate Repository Review C.2.6Class: TOE Access (FTA)C.2.6.1FTA_SSL_EXT TSF-Initiated Session Locking C.2.7Class: User Data Protection (FDP)C.2.7.1FDP_CER_EXT Certificate Generation C.2.7.2FDP_CRL_EXT Certificate Revocation Lists C.2.7.3FDP_CSI_EXT Certificate Status Information C.2.7.4FDP_OCSPG_EXT OCSP Response Generation C.2.7.5FDP_SDP_EXT Sensitive Data Protection C.2.7.6FDP_STG_EXT Sensitive Data Storage Appendix D - Entropy Documentation and Assessment Appendix E - Acronyms Appendix F - Bibliography

1 Introduction

1.1 Overview

Certification Authorities (CAs), and the infrastructure they support, form the basis for one of the primary mechanisms for providing strong assurance of identity in online transactions. The widely placed trust in CAs is at the heart of security mechanisms used to protect business and financial transactions online. Notably, protocols using Transport Layer Security (TLS) rely on certificates issued by CAs to identify and authenticate servers and clients in web transactions. Governments around the world rely on CAs to identify parties involved in transactions with them.

However, historical high-profile security breaches at major CAs trusted by widely used operating systems and browsers have highlighted both the critical role CAs play in securing electronic transactions, as well as the need to strongly protect them from malicious attacks. Analyses have revealed that these security breaches were often the result of insufficient security controls being in place on the computer systems and networks at these CAs, and were sometimes exacerbated by weak record keeping. Third-party auditing programs, whose role it was to verify that proper security controls were in place, were not sufficient to identify these lapses in security.

This Protection Profile (PP) describing security requirements for a Certification Authority is intended to provide a minimal, baseline set of requirements that are targeted at mitigating well defined and described threats. These requirements support CA operations performed in accordance with the National Institute of Standards and Technologies (NIST) Interagency or Internal Report (IR) 7924 (Second Draft), Reference Certificate Policy, May 2014, referred to as the “NIST IR.”

The following sections provide both Common Criteria and technology terms used in this PP.

1.2 Terms

The following sections list Common Criteria and technology terms used in this document.

1.2.1 Common Criteria Terms

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.
Direct Rationale	A type of Protection Profile, PP-Module, or Security Target in which the security problem definition (SPD) elements are mapped directly to the SFRs and possibly to the security objectives for the operational environment. There are no security objectives for the TOE.
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.

1.2.2 Technical Terms

Administrator	The Administrator is responsible for management activities, including configuration of the CA and its security functions.
Authorized Organizational Representative (AOR)	An optional privileged user role which is delegated authority by the Certification Authority Staff or RA Staff to manage a restricted set of certificates associated to devices belonging to a particular organization
Certificate Management over CMS (CMC)	Certificate Management over CMS. A standard certificate enrollment protocol.
Certificate Profile	A set of configuration parameters that defines everything associated with a type of certificate, in particular the contents (fields and extensions) of the generated certificate.
Certification Authority (CA)	The set of hardware, software, firmware, or some combination thereof, that issues, revokes, and manages public key certificates and certificate status information.
Compromise	The unauthorized disclosure, modification, substitution or use of sensitive data (including plaintext cryptographic keys and other CSPs).
Confidentiality	The property that sensitive information is not disclosed to unauthorized individuals, entities or processes.
Critical Security Parameter (CSP)	Security-related information (e.g., secret and private cryptographic keys, authentication data such as passwords and PINs) appearing in plaintext or otherwise unprotected form and whose disclosure or modification can compromise the security of a CA or the security of the information protected by the CA.
Cryptographic key	A parameter used in conjunction with a cryptographic algorithm that determines: the transformation of plaintext data into ciphertext data, the transformation of ciphertext data into plaintext data, a digital signature computed from data, a keyed hash computed from data, the verification of a digital signature computed from data, an authentication code computed from data, or an exchange agreement of a shared secret.
Data Encryption Key (DEK)	A key used to encrypt data-at-rest.
Digital Signature	A non-forgeable transformation of data that allows proof of the source (with nonrepudiation) and verification of the integrity of that data.
Encrypted key	A cryptographic key that has been encrypted with a key encrypting key, a PIN or a password in order to disguise the value of the underlying plaintext key.
Error detection code (EDC)	A code computed from data and comprised of redundant bits of information designed to detect, but not correct, unintentional changes in the data.
Integrity	The property that sensitive data has not been modified or deleted in an unauthorized and undetected manner.
Key Encryption Key (KEK)	A key used to encrypt other keys, such as DEKs, or storage that contains keys.
Key sharing	A multi-party computation (MPC) mechanism that allows two or more parties, each with key components, to jointly produce a plaintext key without revealing any of the key components.
Private key	A cryptographic key used with a public key cryptographic algorithm, uniquely associated with an entity, and not made public.
Privileged user	An individual with access and login privileges on the CA.
Public key	A cryptographic key used with a public key cryptographic algorithm, uniquely associated with an entity, and which may be made public. (Public keys are not considered CSPs.)
Public key (asymmetric) cryptographic algorithm	A cryptographic algorithm that uses two related keys, a public key and a private key. The two keys have the property that, given the public key, it is computationally infeasible to derive the private key.
Public key certificate	A set of data that unambiguously identifies an entity, contains the entity's public key, is digitally signed by a trusted party, and binds the public key to the entity.
Registration Authority (RA)	The set of hardware, software, firmware, or some combination thereof that is used to validate the identity of a subscriber before instructing the CA to manipulate a certificate on the subscriber’s behalf.
Root Encryption Key (REK)	A key tied to hardware that is used to encrypt other keys such as KEKs.
Secret key	A cryptographic key used with a secret key cryptographic algorithm, uniquely associated with one or more entities, and which shall not be made public. The use of the term "secret" in this context does not imply a classification level rather the term implies the need to protect the key from disclosure or substitution.
Secret key (symmetric) cryptographic algorithm	A cryptographic algorithm that uses a single, secret key for both encryption and decryption.
Shared secret	A token used by the CMC protocol to help provide identity proofing.
Subscriber	A human or machine entity that is bound to one or more certificates maintained by the CA.
Trust Anchor Database	A list of trusted root Certification Authority certificates.

1.3 Compliant Targets of Evaluation

A CA system is an entity that issues and manages public-key certificates. The CA is the primary component of a public key infrastructure (PKI), which consists of programs, data formats, procedures, communication protocols, security policies, and public key cryptographic mechanisms working together to enable people in various locations to establish trust through secure communications. To achieve this goal, a PKI may provide some or all of the following security management services:

Key generation/storage
Certificate generation, modification, re-key, renewal, and distribution
Certificate revocation list (CRL) generation and distribution
Key escrow and recovery
Directory management of certificate related items
Certificate token initialization/programming/management
System management functions (e.g., security audit, configuration management, archive)

A CA performs a number of certificate management functions besides certificate issuance:

Re-issuance:A CA handles re-issuance of certificates when they expire, since certificates have a finite validity period. Reissuance may be renewal of the current public key; rekey with a new public key; or modification to other data in the public key certificate.
Revocation: The CA is also responsible for indicating, when notified via a subscriber or privileged user, that a certificate should no longer be used or relied upon; this is referred to as revocation. For example, a certificate needs to be revoked if an individuals’ private key is compromised or if the CA issued the certificate to the wrong person. Identifiers of revoked certificates are stored on an electronic list called a certificate revocation list (CRL). The CRL is digitally signed by the CA and published to a repository accessible by the relying parties. The CRL is used to compare against certificates to ensure a certificate is not invalid when used. Alternatively, a CA can provide a Certificate Status Service (CSS) that provides revocation status responses to subscribers and relying parties. The CSS’ revocation status information may be based on certificate history information from the CA, a CRL from the CA, or a CRL retrieved from a repository. A CA must be able to provide revocation status, but either approach is acceptable.
Distribution:The CA handles the publishing of certificates and CRLs that it issues to a repository. The repository enables subscribers and relying parties to obtain subscriber certificates and CRLs to perform functions such as encrypting emails and data to recipients or verifying signatures on transactions. Typically, CRL location is advertised in the certificate itself as an HTTP pointer to allow the relying parties to obtain the CRL.
Storage: The CA keeps a history of a subscriber’s previously issued and revoked certificates.

There are a number of optional functions that a CA may perform. For example, a CA may issue CRLs or may provide a CSS that responds to certificate status requests from subscribers and relying parties. A CA may generate public/private key pairs for subscribers, usually for encryption; this function may be delegated to a different PKI component. In some cases, a CA will escrow private keys for encryption certificates, a function typically delegated to a key escrow PKI component. If a CA handles subscriber key generation and escrow, it should also keep a history of subscriber keys to support cases where an old encryption key may be required to decrypt data. A CA may also be responsible for verifying subscriber identities who request to interact with the CA. If the CA does not provide this functionality directly, it is expected to interface with a registration authority (RA) that does.

The CA can be internal to an organization or it can be managed by an outside organization dedicated to this type of service. If the CA is internal, the organization controls the CA server, configures how the subscriber identity proofing takes place during registration, maintains the certificates, and revokes certificates when necessary. If the CA is a third party organization specifically designed to serve as a CA, then other individuals and companies pay them to supply this service. Depending on the nature of agreement and service, the organization may be fully or to some extent involved in subscriber registration, certificate management, and revocation.

1.3.1 TOE Boundary

Figure 1 below illustrates an example PKI architecture; this architecture is for illustration only and is not meant to represent requirements for an actual deployment. Within a PKI, the CA is responsible for issuing and managing public-key certificates for subjects to prove their identities; these subjects are typically called subscribers and can be people, devices, applications, or servers. A public-key certificate is a credential that contains the public key for that subscriber bound with other identifying information using a CA’s digital signature. To obtain a certificate, subscribers register with the PKI. Depending on how the PKI is designed, this is done either directly through the CA itself or optionally through a third-party RA which verifies the requester’s identity before the request is handled by the CA. Part of the registration process is the generation of a private/public key pair that occurs either at the CA, at the RA or (typically) on the subscriber’s system. If not generated by the CA, the public key is transmitted to the CA during the registration process. The CA signs the certificate with a digital signature (using its own private key) that binds the public key and other identifying information to the subscriber. In this capacity, the CA acts as a trusted third party by asserting the authenticity of the subscriber, the public key, and the binding of the subscriber to the public key. This allows relying parties (e.g., individuals or applications) to verify and trust signatures or assertions made by the subscriber using the private key that corresponds to the public key contained in the certificate. This also allows the relying parties to use the public key in the certificate to carry out encrypted communication with the subscriber.

Figure 1: TOE Boundary in Example PKI Architecture

This PP defines requirements only for CA system component(s) that issue and manage public key certificates and certificate status information, to include interfaces to components not under the control of the ST author that may be required to meet these requirements as shown in Figure 1 (above).

While the functionality that the TOE is obligated to implement (in response to the described threat environment) is discussed in detail in later sections, it is useful to give a brief description here. Compliant TOEs will provide security functionality that addresses threats to the TOE and implements policies that are imposed by law or regulation. Compliant TOEs must authenticate and validate certificate requests and control the use of its private signature key(s) so that only valid, properly authorized certificates are issued; it must validate and authenticate all revocation requests and provide accurate and up-to-date revocation status information; and it must validate any requests for optional services (key generation, key escrow or recovery), authenticate and determine authorization for such services according to applicable security policies and ensure that only authorized services are performed. The TOE must protect itself from common network attacks, limit the damage that could occur by privileged user error, and be able to recover from damage that can occur via either network attacks or human error, to include reconstitution of functionality necessary to maintain any and all certificates issued for the duration of their validity periods in the case of TOE failure. The TOE must also offer auditing of a set of events that are associated with security-relevant activity on the TOE, and these events must be retained for long-term storage even in the event of a failure of the TOE. Audit storage should be reliable and extensible, although this could be on a device that is distinct from the TOE. The TOE must offer some protection for common network denial of service attacks and must also provide the ability to verify the source of updates to components of the TOE.

A CA system which is the Target of Evaluation (TOE) of this PP may be a software package installed on a general computing platform, a set of software packages installed on distributed general computing platforms, or an integrated device including hardware and software. This PP makes no distinction in these cases and imposes requirements on the TOE and/or Operational Environment to ensure that the requirements can be met in any of these cases. Whenever the TOE depends on external components to meet the requirements of this PP, those components are included in the Operational Environment and the AGD_OPE and AGD_PRE sections of this PP describe requirements on the TOE to document these dependencies. For example, the TOE provides cryptographic operations involved in the signing of certificates, which may depend on an external cryptographic module such as a trusted computing module (TPM) on the general computing platform or an external hardware security module (HSM).

The CA manages certificates by providing validity information, either via the issuance of Certificate Revocation Lists (CRLs) or via a Certificate Status Service (CSS) that provides real-time responses to validity queries. Because a CA acts as a trusted third party, and because recommended operations require independent monitoring of its operations, the CA must maintain an audit record that can be reviewed. This audit record may be maintained on the TOE, or on an external audit server.

The threats and security objectives apply generally to a CA system. In order to provide consistent requirements for all TOEs, the requirements in Section 5 include selections to indicate where external components may be used. The TOE platform, external cryptographic modules, external audit servers, and external CSS that are not under the control of the security target (ST) author may be used to meet the respective TOE requirements. In these cases, the ST author must provide evidence that the requirement is met by the selected component. When external components are selected, this evidence is typically via validation against an appropriate PP.

It is intended that the set of requirements in this PP is limited in scope in order to promote quicker, less costly evaluations that provide some value to end users.

1.4 Use Cases

Requirements in this PP are designed to address the security problem for CA systems. The fundamental usage of a CA system will not differ drastically based on the functionality it provides. Different TOEs may vary because of the inclusion or exclusion of the various optional, objective, and selection-based requirements defined in the annexes of this PP but they are all expected to be used in the same general manner for the same general purposes.

1.5 Product Features Mapped to Implementation-Dependent Requirements

The feature(s) enumerated below, if implemented by the TOE, require that additional SFRs be claimed in the ST.

1.5.1 TOE Responsible for Protecting Subscriber Information

If the TOE does not rely on an RA, or if the CA provides a centralized repository for subscriber information, the following SFRs must be claimed in order for the TOE to provide assurance that subscriber data is protected.

If this feature is implemented by the TOE, the following requirements must be claimed in the ST:

FCS_CKM_EXT.1/DEK

1.5.2 TOE supports Audit Review

If the TOE supports review of audit records, then the following SFRs must be included:

If this feature is implemented by the TOE, the following requirements must be claimed in the ST:

FAU_SAR.1
FAU_SAR.3

1.5.3 TSF Supports Audit Pre-Select

If any audit pre-selection is performed by an auditor through an interface provided by the TSF, then the following SFRs must be included:

If this feature is implemented by the TOE, the following requirements must be claimed in the ST:

FAU_SEL.1

1.5.4 TSF Supports Storage of Audit Records

If any storage of audit records is performed by the TOE, then the following SFRs must be included:

If this feature is implemented by the TOE, the following requirements must be claimed in the ST:

FAU_STG.2/EXT
FAU_STG.2/STA

2 Conformance Claims

Conformance Statement

An ST must claim exact conformance to this PP.

The evaluation methods used for evaluating the TOE are a combination of the workunits defined in [CEM] as well as the Evaluation Activities for ensuring that individual SFRs and SARs have a sufficient level of supporting evidence in the Security Target and guidance documentation and have been sufficiently tested by the laboratory as part of completing ATE_IND.1. Any functional packages this PP claims similarly contain their own Evaluation Activities that are used in this same manner.

CC Conformance Claims

This PP is conformant to Part 2 (extended) and Part 3 (conformant) of Common Criteria CC:2022, Revision 1.

PP Claim

This PP does not claim conformance to any Protection Profile.

There are no PPs or PP-Modules that are allowed in a PP-Configuration with this PP.

Package Claim

This PP is Functional Package for TLS, version 2.0 conformant.
This PP is Functional Package for Secure Shell, version 2.0 conformant.
This PP is Functional package for X.509, version 1.0 conformant.
This PP is Assurance Package for Flaw Remediation, version 1.0 conformant.

The functional packages to which the PP conforms may include SFRs that are not mandatory to claim for the sake of conformance. An ST that claims one or more of these functional packages may include any non-mandatory SFRs that are appropriate to claim based on the capabilities of the TSF and on any triggers for their inclusion based inherently on the SFR selections made.

3 Security Problem Definition

The security problem is described in terms of the threats that the OS is expected to address, assumptions about the operational environment, and any organizational security policies that the OS is expected to enforce.

3.1 Threats

T.PRIVILEGED_USER_ERROR: A privileged user or non-person entity (NPE) improperly exercises or adversely affects the TOE, resulting in unauthorized services, ineffective security mechanisms, or unintended circumvention of security mechanisms.
T.TSF_FAILURE: Security mechanisms of the TOE may fail, leading to a compromise of the TSF.
T.UNAUTHENTICATED_TRANSACTIONS: Relying parties within an information system depend on the TOE to accurately bind subjects to their credentials for use in authenticating and providing privacy for transactions. Without the proper binding provided by the TOE, relying parties cannot ensure adequate access controls on sensitive information, ensure transactional integrity, ensure proper accountability, and/or enforce nonrepudiation.
T.UNAUTHORIZED_ACCESS: A malicious user, process, or external IT entity intentionally circumvents TOE security mechanisms.
T.UNAUTHORIZED_UPDATE: A malicious party attempts to supply the end user with an update to the product that may compromise the security features of the TOE.
T.UNDETECTED_ACTIONS: Remote users or external IT entities may take actions that adversely affect the security of the TOE.
T.USER_DATA_REUSE: A malicious user, process, or external IT entity may gain access to user data that is not cleared when resources are reallocated.
T.WEAK_CRYPTO: A weak hash or signature scheme may be compromised by an attacker and used to apply integrity checks to malicious content so that it appears legitimate.

3.2 Assumptions

A.NO_GENERAL_PURPOSE: It is assumed that there are no general-purpose computing capabilities (e.g., compilers or user applications) available on the TOE, other than those services necessary for the operation, administration and support of the TOE.
A.PHYSICAL: Physical security, commensurate with the value of the TOE and the data it contains, is assumed to be provided by the environment.
A.TRUSTED_ADMIN: TOE Administrators are assumed to follow and apply all administrator guidance in a trusted manner.

3.3 Organizational Security Policies

P.ACCESS_BANNER: The TOE shall display an initial banner describing restrictions of use, legal agreements, or any other appropriate information to which users consent by accessing the TOE.

4 Security Objectives

4.1 Security Objectives for the Operational Environment

Note that PP allows the ST author in some cases to select if the TSF or Operational Environment is invoked to perform some function. There are several Objectives for the Operational Environment that correspond to those SFRs, covering the case where the ST author selects the item pertaining to the Operational Environment being invoked to perform the function. If the TOE performs all such functions (that is, the Operational Environment-related selection is not chosen), then the corresponding Objective for the Operational Environment will need to be removed by the ST author.

OE.PLATFORM: The OS relies on being installed on trusted hardware.
OE.CERT_REPOSITORY: This OE objective is marked as conditional in the previous version of this PP depending on whether the TSF implements its own functions for this or relies on the OE to do it. We currently lack the syntax capability to handle such a conditional OE objective and in that light, should this objective remain? The Operational Environment provides a certificate repository for storage of certificates (and optionally CRLs) issued by the TSF.
OE.CERT_REPOSITORY_SEARCH: This OE objective is marked as conditional in the previous version of this PP depending on whether the TSF implements its own functions for this or relies on the OE to do it. We currently lack the syntax capability to handle such a conditional OE objective and in that light, should this objective remain? The Operational Environment provides the ability to search a certificate repository for specific certificate fields in certificates issued by the TSF and return the certificate and an identifier for the certificate that can be used to search the audit trail for events related to that certificate.
OE.AUDIT_GENERATION: This OE objective is marked as conditional in the previous version of this PP depending on whether the TSF implements its own functions for this or relies on the OE to do it. We currently lack the syntax capability to handle such a conditional OE objective and in that light, should this objective remain? The Operational Environment provides a mechanism for the generation of portions of the audit data.
OE.AUDIT_RETENTION: This OE objective is marked as conditional in the previous version of this PP depending on whether the TSF implements its own functions for this or relies on the OE to do it. We currently lack the syntax capability to handle such a conditional OE objective and in that light, should this objective remain? The Operational Environment provides mechanisms for retention of audit records for both normal and extended retention periods.
OE.AUDIT_REVIEW: This OE objective is marked as conditional in the previous version of this PP depending on whether the TSF implements its own functions for this or relies on the OE to do it. We currently lack the syntax capability to handle such a conditional OE objective and in that light, should this objective remain? The Operational Environment provides a mechanism for the review of specified audit data.
OE.AUDIT_STORAGE: This OE objective is marked as conditional in the previous version of this PP depending on whether the TSF implements its own functions for this or relies on the OE to do it. We currently lack the syntax capability to handle such a conditional OE objective and in that light, should this objective remain? The Operational Environment provides a mechanism for the storage of specified audit data.
OE.CRYPTOGRAPHY: This OE objective is marked as conditional in the previous version of this PP depending on whether the TSF implements its own functions for this or relies on the OE to do it. We currently lack the syntax capability to handle such a conditional OE objective and in that light, should this objective remain? The Operational Environment provides cryptographic services that can be invoked by the TSF in order to perform security functionality.
OE.KEY_ARCHIVAL: This OE objective is marked as conditional in the previous version of this PP depending on whether the TSF implements its own functions for this or relies on the OE to do it. We currently lack the syntax capability to handle such a conditional OE objective and in that light, should this objective remain? The Operational Environment provides the ability to use split knowledge procedures to enforce two-party control to export keys necessary to resume CA functionality if the TSF should fail.
OE.NO_GENERAL_PURPOSE: There are no general-purpose computing capabilities (e.g., compilers or user applications) available on the TOE, other than those services necessary for the operation, administration and support of the TOE.
OE.PHYSICAL: Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment.
OE.PUBLIC_KEY_PROTECTION: This OE objective is marked as conditional in the previous version of this PP depending on whether the TSF implements its own functions for this or relies on the OE to do it. We currently lack the syntax capability to handle such a conditional OE objective and in that light, should this objective remain? The Operational Environment provides protection for specified public keys associated with CA functions.
OE.SESSION_PROTECTION_LOCAL: This OE objective is marked as conditional in the previous version of this PP depending on whether the TSF implements its own functions for this or relies on the OE to do it. We currently lack the syntax capability to handle such a conditional OE objective and in that light, should this objective remain? The Operational Environment provides the ability to lock or terminate local administrative sessions.
OE.SESSION_PROTECTION_REMOTE: This OE objective is marked as conditional in the previous version of this PP depending on whether the TSF implements its own functions for this or relies on the OE to do it. We currently lack the syntax capability to handle such a conditional OE objective and in that light, should this objective remain? The Operational Environment provides the ability to lock or terminate remote administrative sessions.
OE.TOE_ADMINISTRATION: This OE objective is marked as conditional in the previous version of this PP depending on whether the TSF implements its own functions for this or relies on the OE to do it. We currently lack the syntax capability to handle such a conditional OE objective and in that light, should this objective remain? The Operational Environment provides specified management capabilities required for the overall operation of a Certificate Authority, and the ability to restrict access to a subset of the capabilities as specified in the ST.
OE.TRUSTED_ADMIN: The administrator of the TOE is not careless, willfully negligent or hostile, and administers the software within compliance of the applied enterprise security policy.
OE.TRUSTED_PLATFORM: This OE objective is marked as conditional in the previous version of this PP depending on whether the TSF implements its own functions for this or relies on the OE to do it. We currently lack the syntax capability to handle such a conditional OE objective and in that light, should this objective remain? The operating system on which the TOE has been installed is securely configured, regularly patched, and not subject to unauthorized access.

4.2 Security Objectives Rationale

This section describes how the assumptions and organizational security policies map to operational environment security objectives.

Table 1: Security Objectives Rationale
Assumption or OSP	Security Objectives	Rationale
A.NO_GENERAL_PURPOSE	OE.NO_GENERAL_PURPOSE	There are no general-purpose computing capabilities (e.g., compilers or user applications) available on the TOE, other than those services necessary for the operation, administration and support of the TOE.
A.PHYSICAL	OE.PHYSICAL	Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment.
A.TRUSTED_ADMIN	OE.TRUSTED_ADMIN	The administrator of the TOE is not careless, willfully negligent or hostile, and administers the software within compliance of the applied enterprise security policy.
P.ACCESS_BANNER	O.DISPLAY_BANNER	The TOE will display an advisory warning regarding use of the TOE.

5 Security Requirements

This chapter describes the security requirements which have to be fulfilled by the product under evaluation. Those requirements comprise functional components from Part 2 and assurance components from Part 3 of [CC]. The following conventions are used for the completion of operations:

Refinement operation (denoted by bold text or ~~strikethrough text~~): Is used to add details to a requirement or to remove part of the requirement that is made irrelevant through the completion of another operation, and thus further restricts a requirement.
Selection (denoted by italicized text): Is used to select one or more options provided by the [CC] in stating a requirement.
Assignment operation (denoted by italicized text): Is used to assign a specific value to an unspecified parameter, such as the length of a password. Showing the value in square brackets indicates assignment.
Iteration operation: Is indicated by appending the SFR name with a slash and unique identifier suggesting the purpose of the operation, e.g. "/EXAMPLE1."

5.1 Security Functional Requirements

The following table lists the SFRs that are defined in this section as well as any auditable events associated with their enforcement. The following table presents the baseline (mandatory) requirements for compliant TOEs. If the TOE relies on the Operational Environment to provide some of the TOE’s auditing functionality, the ST author is expected to identify whether each of the auditable events for the claimed SFRs are implemented by the TSF or by the Operational Environment, along with the specific environmental component that provides the auditing functionality if applicable.

5.1.1 Auditable Events for Mandatory SFRs

Table 2: Auditable Events for Mandatory Requirements
Requirement	Auditable Events	Additional Audit Record Contents
FAU_ADP_EXT.1
FAU_ADP_EXT.1
No events specified	N/A
FAU_GCR_EXT.1
FAU_GCR_EXT.1
No events specified	N/A
FAU_GEN.1
FAU_GEN.1
No events specified	N/A
FAU_GEN.2
FAU_GEN.2
No events specified	N/A
FAU_STG.1
FAU_STG.1
No events specified	N/A
FAU_STG.5
FAU_STG.5
No events specified	N/A
FCO_NRO_EXT.2
FCO_NRO_EXT.2
No events specified	N/A
FCS_CDP_EXT.1
FCS_CDP_EXT.1
No events specified	N/A
FCS_STG_EXT.1
FCS_STG_EXT.1
No events specified	N/A
FDP_CER_EXT.1
FDP_CER_EXT.1
Certificate generation: Success. (Retention: Extended)	Certificate value or object identifier.
FDP_CER_EXT.2

	Linking of certificate to certificate request: Success (Retention: Extended)	Certificate value or object identifier Certificate request or link to certificate request object identifier
Linking of certificate to certificate request: Failure (Retention: Extended)	Reason for failure Certificate request or link to certificate request object identifier
FDP_CER_EXT.3
FDP_CER_EXT.3
Failed certificate approvals (Retention: Normal)	Reason for failure Certificate request or link to certificate request object identifier
FDP_CSI_EXT.1
FDP_CSI_EXT.1
No events specified	N/A
FDP_RIP.1
FDP_RIP.1
No events specified	N/A
FIA_UAU_EXT.1
FIA_UAU_EXT.1
All uses of the authentication mechanism used for access to TOE related functions (Retention: Normal)	Origin of the attempt (e.g., IP address)
FIA_UIA_EXT.1
FIA_UIA_EXT.1
All use of the identification and authentication mechanism used for TOE-related roles (Retention: Normal)	Provided user identity. Origin of the attempt (e.g., IP address)
FIA_X509_EXT.1
FIA_X509_EXT.1
Failed certificate validations (Retention: Normal)	No additional information
FIA_X509_EXT.2
FIA_X509_EXT.2
Failed authentications (Retention: Normal)	No additional information
FMT_MOF.1/Admin
FMT_MOF.1/Admin
No events specified	N/A
FMT_MOF.1/Auditor
FMT_MOF.1/Auditor
No events specified	N/A
FMT_MOF.1/CA
FMT_MOF.1/CA
No events specified	N/A
FMT_MOF.1/CO
FMT_MOF.1/CO
No events specified	N/A
FMT_MOF.1/RA
FMT_MOF.1/RA
No events specified	N/A
FMT_MTD.1
FMT_MTD.1
No events specified	N/A
FMT_SMF.1
FMT_SMF.1
No events specified	N/A
FMT_SMR.2
FMT_SMR.2
Modifications to the group of users that are part of a role (Retention: Extended)	Modifications to the group of users that are part of the role
FPT_FLS.1
FPT_FLS.1
Invocation of failures under the requirement (Retention: Normal)	Indication that the TSF has failed with the type of failure that occurred
FPT_KST_EXT.1
FPT_KST_EXT.1
No events specified	N/A
FPT_KST_EXT.2
FPT_KST_EXT.2
All unauthorized attempts to use the TOE secret and private keys. (Retention: Normal)	Identifier of user or process that attempted access.
FPT_RCV.1

	The fact that a failure of service discontinuity occurred. (Retention: Extended)	The type of failure or service discontinuity.
Resumption of the regular operation. (Retention: Extended)	The type of failure or service discontinuity.
FPT_SKP_EXT.1
FPT_SKP_EXT.1
No events specified	N/A
FPT_STM.1
FPT_STM.1
Changes to the time (Retention: Normal)	The new and old values for the time.
FPT_TUD_EXT.1
FPT_TUD_EXT.1
Initiation of update. (Retention: Extended)	Version number
FTA_SSL.4
FTA_SSL.4
The termination of an interactive section. (Retention: Normal)	No additional information
FTA_TAB.1
FTA_TAB.1
No events specified	N/A
FTP_TRP.1

	Initiation of the trusted channel. (Retention: Normal)	Identification of the claimed user identity
	Termination of the trusted channel. (Retention: Normal)	Identification of the claimed user identity
Failures of the trusted path functions. (Retention: Normal)	Identification of the claimed user identity

5.1.2 Class: Security Audit (FAU)

FAU_ADP_EXT.1 Audit Dependencies

FAU_ADP_EXT.1.1

The TSF shall implement audit functionality and [selection: interface with auditing function(s) in the Operational Environment, no additional audit functionality] in order to perform audit operations on the following audit data: [assignment: Auditable events in Table 4 through Table 6 that require persistent storage].

Application Note: If any audit functions (e.g. storage, review) are accomplished by the TOE communicating over a network connection with a physically external audit server, then the ST author must include FTP_ITC.1 with "audit server" selected. If the TOE relies on the Operational Environment to provide some of the TOE’s auditing functionality, the ST author is expected to identify whether each of the auditable events for the claimed SFRs are implemented by the TOE or by the Operational Environment, along with the specific environmental component that provides the auditing functionality if applicable. The ST author should refer to the right-most column of Table 4 through Table 6 and complete these fields accordingly

If any audit review is performed by an auditor through an interface provided by the TSF, then FAU_SAR.1 and FAU_SAR.3 in Annex B.2 will be included in the ST by the ST author.

If any audit pre-selection is performed by an auditor through an interface provided by the TSF, then FAU_SEL.1 in Annex B.2 will be included in the ST by the ST author.

Audit records stored within the TOE boundary that are generated due to audit events marked “extended” in tables 4, 5, and 6 that are included in the ST, then FAU_STG.2/EXT will be included in the ST by the ST author.

If the TSF initiates the storage of the audit data (that is, it generates audit data that will be stored either by the TOE or the OE), then FAU_STG_EXT.1 will be included in the ST by the ST Author.

Audit records for the TSF are divided into two sets of events, whose retention periods might be significantly different operationally. Generally, information necessary to maintain an issued certificate or to determine the circumstances of a certificate issuance is required to be available at least as long as the validity of an issued certificate, and perhaps longer according the statutes, laws, or policies applicable to the issuance and intended use of a particular certificate. Other audit data is typically retained only to support normal operations. The ‘Retention’ column in Table 4 (as well as Tables 5 and 6 for the optional and selection-based SFRs) indicates whether the audit record is intended to be used for ‘normal’ (shorter-term) or ‘extended’ (longer-term) purposes.

For the FDP_CER_EXT.2 audit event, the intent is that auditing is performed only once incoming data are recognized by the TOE as a “request”. Cases where incoming data are rejected before they are processed as “requests” by the TOE (and thus the action “fails”) do not need to be audited by the FDP_CER_EXT.2 audit event.

FAU_GCR_EXT.1 Generation of Certificate Repository

FAU_GCR_EXT.1.1

The TSF shall [selection: store, invoke the Operational Environment to store] certificates and [selection: CRLs, no other information] issued by the TSF.

Application Note: While there is a requirement that a certificate repository exists and the TOE stores all certificates (and CRLs, if selected in FCO_NRO_EXT.2.2) it generates in that repository, the repository can physically be within the TOE or within (and provided by storage in) the OE. If the repository is provided by the TOE (that is, it is within the TOE boundary), then the first item in the first selection is chosen. If the storage is provided by the OE, then the second item in the first selection is chosen. It should be noted that the physical implementation of the certificate repository is left to the vendor; for instance, it can be a standalone store, or incorporated within the audit trail.

If “CRLs (RFC 5280)” is chosen for FCO_NRO_EXT.2.2, then “CRLs” is selected in the second selection; otherwise, “no other information is selected”.

FAU_GEN.1 Audit Data Generation

FAU_GEN.1.1

The TSF shall generate audit data of the following auditable events:

Start-up and shutdown of the audit functions
All auditable events for the [not specified] level of audit;
[

All administrative actions invoked through the TSF interface;

Specifically defined auditable events listed in Table 2

Specifically defined auditable events listed in Table 5

Specifically defined auditable events listed in Table 8

Specifically defined auditable events listed in Table t-audit-impl-dep

].

Application Note: The ST author will include a consolidated table of auditable events for all mandatory, optional, and selected components in the ST per FAU_ADP_EXT.1 that will indicate the component that is responsible for producing the audit event. There are three cases for the generational of audit events. The audit event is generated by the TSF; the audit event is generated on initiation by the TOE, but the OE is involved in some or all of the actual generation of the audit event; and the audit event is generated entirely by the OE without prompting from the TOE.

The first two cases are covered by this requirement. Additionally, the start-up of the TOE functions and all administrative actions that performed either by or through the TOE are required to be auditable. If all of the audit records are generated by the TOE, or if the audit records are either generated entirely by the TOE and entirely by the OE (that is, none of the audit records are generated by invoking the OE), then “no other actions” is chosen in the selection. The meaning of “specifically defined auditable events…” in item d refers to events in the table produced by FAU_ADP_EXT.1 that indicate they are generated in whole or part of the TSF.

FAU_GEN.1.2

The TSF shall within the audit data at least the following information:

Date and time of the auditable event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event;
For each audit event type, based on the auditable event definitions of the functional components included in the PP, PP-Module, functional package or ST, [information specified in column three of the Auditable Events table in which the auditable event was defined.

Application Note: As with the previous component, the ST author should update Table 4 above with any additional information generated. "Subject identity" in the context of this requirement could either be the administrator's user ID or the affected network interface, for example.

The ST author chooses whether the information is put into the audit record by the TSF or the OE via the selection; it is permissible to be a combination of both. It may be the case that when the TSF generates an audit record, some or all of the information listed in the SFR are actually put into the audit record by the OE. In these cases, “invoke the Operational Environment to record” should be selected. OE.AUDIT_GENERATION will be included in the ST if the OE is selected in any of the FAU_GEN elements.

Evaluation Activities

FAU_GEN.1

TSS

The evaluator shall ensure that the TSS describes every audit event type mandated by the PP and that the description of the fields contains the information required in FAU_GEN.1.2, and the additional information specified in Tables 4 through 6, depending on the characterization of the SFR associated with the particular event as mandatory, optional, or selection-based. For each applicable audit event, the evaluator shall additionally ensure that the TSS describes whether the TSF or the OE is responsible for storing records of the event. If multiple OE components are used for audit storage, the specific ones used in each case shall be identified.

The evaluator shall also ensure that the TSS describes all cases where the generation of ephemeral key pairs is not audited for FCS_CKM.1.

Guidance

The evaluator shall examine the operational guidance to ensure that it describes the audit mechanism, lists all of the auditable events and provides a format for audit records. Each audit record format type must be covered, along with a brief description of each field.

The evaluator shall also make a determination of the administrative actions that are relevant in the context of this PP. The evaluator shall examine the operational guidance and make a determination of which administrative commands, including subcommands, scripts, and configuration files, are related to the configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements specified in the PP. The evaluator shall document the methodology or approach taken while determining which actions in the operational guidance are security relevant with respect to this PP. The evaluator may perform this activity as part of the activities associated with ensuring the operational guidance satisfies the requirements in accordance with AGD_OPE.

The evaluator shall check that audit review tools are described in the operational guidance and conform to the requirements of FAU_SAR.1.

When the Operational Environment is selected in FAU_GEN.1.1 or FAU_GEN.1.2, the evaluator shall examine the operational guidance to ensure the configuration of the Operational Environment necessary to generate the required elements, and instructions on how to examine the various audit records is provided.

Tests

The evaluator shall test the TOE’s ability to correctly generate audit records by having the TOE generate audit records for the events listed in Table 4, any events in Table 5 and Table 6 that correspond with the optional and selection-based SFRs claimed in the Security Target, startup of the audit functions (or startup of the TOE if audit functionality is not enabled or disabled independently of the TOE), and administrative actions. This should include all instances of an event. The evaluator shall test that audit records are generated for the establishment and termination of a channel for each of the cryptographic protocols contained in the ST. For administrative actions, the evaluator shall test that each action determined by the evaluator above to be security relevant in the context of this PP is auditable.

When verifying the test results, the evaluator shall use audit review tools in conformance of FAU_SAR.1 and the operational guidance. The evaluator shall ensure the audit records generated during testing match the format specified in the operational guidance, and that the fields in each audit record have the proper entries and that the audit records are provided in a manner suitable for interpretation. The evaluator shall also ensure the ability to apply searches of audit data based on the type of event, the user responsible for causing the event, and identity of the applicable certificate. When the Operational Environment is selected in FAU_GEN.1.1 or FAU_GEN.1.2, the evaluator shall follow the operational guidance to configure the Operational Environment as specified in the TSS and identify the audit records used and audit information assigned to each audit record. The evaluator shall then inspect the indicated audit records for audit information assigned to each audit record indicated.

Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly. For example, testing performed to ensure that the operational guidance provided is correct verifies that AGD_OPE.1 is satisfied and should address the invocation of the administrative actions that are needed to verify the audit records are generated as expected.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE's ST. Justification must be provided for those platforms that were excluded from testing.

FAU_GEN.2 User Identity Association

FAU_GEN.2.1

For audit events resulting from actions of identified users, the TSF shall be able to each auditable event with the identity of the user that caused the event.

Application Note: As with FAU_GEN.1.2, if the TSF initiates the generation of the audit event, but the OE is responsible for associating the user ID with that event (if appropriate for that event), then the ST author selects “invoke the Operational Environment to associate” for this SFR.

FAU_STG.1 Audit Data Storage Location

FAU_STG.1.1

The TSF shall be able to store generated audit data on the [selection: TOE itself, transmit the generated audit data to an external IT entity using a trusted channel according to FTP_ITC, locally on the TOE platform].

Application Note: There are 3 cases for the storage of audit data: Locally on the TOE (within the TOE boundary without going over a network connection); locally on the TOE platform (outside the TOE boundary, but without going over a network connection); and external to the TOE platform (meaning over a network connection to a physically distinct IT entity). The TOE may rely on a non-TOE audit server for storage of these audit records and the ability to allow the administrator to review these audit records is provided by the operational environment. In the selection, the ST author chooses the method used by the TOE to store audit data.

This requirement is included in the ST if the TSF initiates the storage of the audit data. The last item in the selection (external audit server) should only be selected (and this SFR included in the ST) if the TOE is responsible for connecting to the external audit server to store the data.

If the last item in the selection is chosen, the ST author must include FTP_ITC.1 with “audit server” selection, and ensures that the supporting protocol requirement matches the selection is included in the ST.

The TOE platform and external IT entity are considered part of the Operational Environment.

Evaluation Activities

FAU_STG.1

TSS

The evaluator shall examine the TSS to ensure it describes the audit storage mechanism from the perspective of the TOE. The TSS must also describe the means by which the audit data are stored locally, or transferred to the external IT entity (and how the trusted channel is provided).

Guidance

The evaluator shall examine the operational guidance to ensure it describes the configuration of any local audit storage mechanism (first two items in the selection in the SFR), including its location and size.

The evaluator shall examine the operational guidance to determine that it describes the relationship between the local audit data (stored inside the TOE boundary and, if applicable, on the TOE platform) and the audit data that are sent to the external IT entity (if applicable). For example, when an audit event is generated, whether it is simultaneously sent to the external IT entity and the local store, or is the local store used as a buffer and “cleared” periodically by sending the data to the external IT entity.

If an external audit server is used, the evaluator shall also examine the operational guidance to ensure it describes how to establish the trusted channel to the audit server, as well as describe any requirements on the audit server (particular audit server protocol, version of the protocol required, etc.), as well as configuration of the TOE needed to communicate with the audit server.

Tests

Testing of the trusted channel mechanism (if the last item is selected in the SFR) will be performed as specified in the associated assurance activities for the particular trusted channel mechanism.

The evaluator shall perform the following tests if the last selection in the SFR is made:

Test FAU_STG.1:1: [conditional] The evaluator shall establish a connection between the TOE and the audit server according to the configuration guidance provided. The evaluator shall then examine the traffic that passes between the audit server and the TOE during several activities of the evaluator’s choice designed to generate audit data to be transferred to the audit server. The evaluator shall verify that the connection has been successfully established, and that they are successfully received by the audit server. The evaluator shall record the particular software (name, version) used on the audit server during testing.
Test FAU_STG.1:2: [conditional] The evaluator shall examine the audit data transferred to the external audit server in Test 1 and compare it to the locally stored audit data. The evaluator shall verify that the audit records match. If there and any differences, the evaluator shall examine the operational guidance to verify that it explains any discrepancies between locally stored and transmitted audit data.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE's ST. Justification must be provided for those platforms that were excluded from testing.

FAU_STG.5 Prevention of Audit Data Loss

FAU_STG.5.1

The TSF shall [prevent audited events, except those taken by the Auditor], [assignment: other actions to be taken in case of audit storage failure and conditions for the actions] if the audit data storage cannot be written to.

Application Note: This requirement applies to the TOE regardless of whether the audit trail is stored within the TOE boundary or on an external system in the Operational Environment. If the audit trail (in whole or in part) is stored locally (either within the TOE boundary or on the TOE platform), then the requirement applies when the audit trail cannot be written to when it is full. If the audit trail (in whole or in part) is stored on a system external to the TOE platform, then the requirement applies when the connection between the TOE platform and the external audit server becomes disconnected and the audit trail cannot be written to. In the case where the audit trail is external to the TOE and cannot be written to because it is full (and the TOE has some way of detecting that), then the requirement applies in that case as well. In all cases, the ST author is expected to describe (in the TSS) how the TSF is made aware of any such failures and how it behaves in response.

Evaluation Activities

FAU_STG.5

TSS

The evaluator shall examine the TSS to ensure it describes the behavior of the TSF when the audit trail cannot be written to. The evaluator shall ensure the TSS describes where the audit trail is stored (locally, remotely, or both); how the TSF detects audit full conditions if the audit trail is stored locally; whether and how the TSF detects audit full conditions for remote audit repositories; and how the TSF detects loss of communication with external audit repositories (if using an external audit server). The evaluator shall also ensure the TSS describes what actions can be performed by the Auditor, if any, in each case where the audit trail cannot be written.

Guidance

The evaluator shall examine the operational guidance to ensure it describes what conditions result in the audit trail not being able to be written to, and how an Auditor recognizes that such a condition has occurred. The evaluator shall also examine the operational guidance to ensure it includes remedial steps for correcting such issues.

Tests

The evaluator shall perform the following tests. The tests are conditional on where the audit data are being stored. Test 1 demonstrates the capability of the TOE to react to an indication that the repository is full; this is always applicable if the audit data are stored locally (either within the TOE boundary or on the TOE platform). If the TOE has a means to detect that a remote audit repository is full, then this test will be run for those types of TOEs as well. Test 2 is only executed in cases where an external repository is supported, and tests the ability of the TOE to detect when the connection to the repository becomes unavailable.

Test FAU_STG.5:1: (conditional) The evaluator shall cause the audit trail to become full, verify that the TSF behaves as documented in the TSS, and verify that a privileged user can perform the documented remedial steps.
Test FAU_STG.5:2: (conditional) If the TOE uses a remote repository in the Operational Environment to store audit data, the evaluator shall cause the audit trail to become unavailable, verify that the TSF behaves as documented in the TSS, and verify that a privileged user can perform the documented remedial steps.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE's ST. Justification must be provided for those platforms that were excluded from testing.

5.1.3 Class: Communications (FCO)

FCO_NRO_EXT.2 Certificate-Based Proof of Origin

FCO_NRO_EXT.2.1

The TSF shall provide proof of origin for certificates it issues in accordance with the digital signature requirements using a mechanism in accordance with RFC 5280 and FCS_COP.1/Sig.

FCO_NRO_EXT.2.2

The TSF shall provide proof of origin for certificate status information it issues in accordance with the digital signature requirements in [selection: CRLs (RFC 5280), OCSP (RFC 6960), [assignment: other OCSP standards]] and FCS_COP.1/Sig.

FCO_NRO_EXT.2.3

The TSF shall require and verify proof of origin for certificate requests it receives [selection: CMC using mechanisms in accordance with FIA_CMCS_EXT.1, EST using mechanisms in accordance with FIA_ESTS_EXT.1].

FCO_NRO_EXT.2.4

The TSF shall require and verify proof of origin for public keys contained in certificate requests it receives via [selection: proof-of-possession mechanisms in CMC using mechanisms in accordance with FIA_CMCS_EXT.1, proof-of-possession mechanisms in EST in accordance with FIA_ESTS_EXT.1].

FCO_NRO_EXT.2.5

The TSF shall [selection:

require and verify proof of origin for revocation requests it receives via [selection: CMC using mechanisms in accordance with FIA_CMCS_EXT.1, EST using optional “full CMC” functionality in accordance with FIA_ESTS_EXT.1]
[assignment: support manual processes for revocation requests and responses]

Application Note: The TOE is responsible for providing proof of origin for information it issues and verifying proof of origin for information it receives. Based on what is chosen in the selection for FCO_NRO_EXT.2.2, the applicable requirements from Annex B (i.e., FDP_CRL_EXT.1, FDP_OCSPG_EXT.1) must be included. Based on what is chosen in the selections for FCO_NRO_EXT.2.3-FCO_NRO_EXT.2.5, the applicable requirements from Annex B (i.e., FIA_CMCS_EXT.1, FIA_ESTS_EXT.1) must be included.

A TOE that supports both EST and CMC and can obtain revocation requests via one of the protocols would be in compliance with FCO_NRO_EXT.2.5. Manual process to support revocation requests and responses are claimed and described if EST does not support full CMC requests and CMC is not claimed.

This SFR references FCS_COP.1/Sig which, according to FCS_CDP_EXT.1, may be implemented by the TOE or the OE. If FCS_CDP_EXT.1 indicates that FCS_COP.1/Sig is implemented by the OE, then FCO_NRO_EXT.2.1 and FCO_NRO_EXT.2.2 are in accordance with FCS_COP.1/Sig if they interface with the OE to invoke the signature algorithms indicated in FCS_COP.1/Sig.

Evaluation Activities

FCO_NRO_EXT.2

TSS

The evaluator shall examine the TSS to ensure it describes the mechanisms used for generating proof of origin and the security-relevant information to which the mechanism applies. The TSS shall describe how the TSF relates the identity and other specified attributes of the originator of the information to the security relevant portions of the information to which the evidence applies. The TSS shall also describe how verification of the proof of origin of information for all security-relevant information is performed and shall also specify the cases in which verification of proof of origin is performed.

For TOEs that only support EST, and do not support revocation requests under either CMC or EST, the TSS must describe the mechanism used to determine whether to revoke certificates.

For TOEs that select “support manual processes for revocation requests and responses,” the evaluator shall ensure the TSS describes those processes.

Guidance

If configurable, evaluator shall examine the operational guidance to ensure it defines how to configure the applicable algorithms used for providing and verifying proof of origin as defined in FCS_COP.1/Sig.

For TOEs that only support EST, and do not support revocation requests under either CMC or EST, the evaluator shall examine the guidance to ensure it describes support for privileged user functionality as part of this mechanism.

For TOEs that select “support manual processes for revocation requests and responses,” the evaluator shall ensure the operational guidance provides a description of the processes the administrators are to follow. The evaluator shall ensure these are consistent with the descriptions of these processes in the TSS.

Tests

The evaluator shall perform the following tests for each request format selected and for each request supported:

TOE is online (requires establishment of a client capable of generating certificate requests and has a valid HTTPS connection to the TOE):

Test FCO_NRO_EXT.2:1: For each supported request, the evaluator shall generate and submit a properly authenticated request to the TOE and verify the responses are signed.
Test FCO_NRO_EXT.2:2: For each supported request, the evaluator shall generate requests that are unsigned, submit to the TOE, and verify that the TOE rejects the request.
Test FCO_NRO_EXT.2:3: For each supported request, the evaluator shall generate requests that have an invalid signature based on the RFC, submit to the TOE, and verify that the TOE rejects the request.
Test FCO_NRO_EXT.2:4: For each supported request, the evaluator shall generate requests that are not signed by authorized entities, submit to the TOE, and verify that the TOE rejects the request.
Test FCO_NRO_EXT.2:5: For each supported request using password based authentication, the evaluator shall use invalid passwords and verify that the TSF rejects the requests.
Test FCO_NRO_EXT.2:6: For each proof of possession mode supported, the evaluator shall generate an otherwise valid request but modify the proof of possession value. The evaluator shall submit the modified request and verify that the TSF rejects the request.
Test FCO_NRO_EXT.2:7: (Transport Test) For each supported request message, the evaluator shall send an otherwise valid request using HTTP rather than HTTPS and shall verify the TSF rejects the request.
Test FCO_NRO_EXT.2:8: (Offline Test): With the TOE in offline mode, the evaluator shall log into the TOE locally as the CA Operations Staff role and perform tests 1-4 above.

Equivalency Testing of the TOE may be performed on a subset of the platforms listed in the TOE's ST. Justification must be provided for those platforms that were excluded from testing.

5.1.4 Class: Cryptographic Support (FCS)

FCS_CDP_EXT.1 Cryptographic Dependencies

FCS_CDP_EXT.1.1

The TSF shall [selection: implement cryptographic functionality, invoke interfaces provided by the Operational Environment] in order to perform [selection: FCS_CKM.1, FCS_CKM.2, FCS_CKM_EXT.1/DEK, FCS_CKM_EXT.1/KEK, FCS_CKM_EXT.1/KEKT, FCS_CKM_EXT.1/SHARE, FCS_CKM.6, FCS_CKM_EXT.5, FCS_CKM_EXT.6, FCS_CKM_EXT.7, FCS_CKM_EXT.8, FCS_COP.1/SKC, FCS_COP.1/Sig, FCS_COP.1/Hash, FCS_COP.1/KeyedHash, FCS_RBG_EXT.1, FCS_KSH_EXT.1] cryptographic operations.

Application Note: Cryptographic functionality can be provided entirely by the TOE, entirely by the Operational Environment, or by both. The SFRs that detail the cryptographic functionality are contained in Annexes A, B, and C; these SFRs are included in the ST depending on selections in other SFRs that describe the mandated and optional functionality that requires cryptographic functions (for instance, the inclusion of TLS). The appropriate selection for whether the cryptographic functionality is implemented by the TOE or by the OE is made for each of the SFRs in the Annex when instantiated in the ST. If both the TSF and OE work together to provide the required cryptography for the TOE, iterate this SFR once for the TSF and once of the OE, and list the specific SFRs implemented by each. In aggregate, all cryptographic SFRs required by the TOE should be listed.

The only exception to this case is where the cryptographic function is implemented in the OE and there is no direct TSF invocation for that function. For instance, if the DRBG is implemented by an HSM that is in the OE, that the TOE only invokes the HSM for higher-level cryptographic functions (such as “create key”, “sign certificate”, etc.), then (in that case) FCS_RBG_EXT.1 would not appear in any iteration of the FCS_CDP_EXT.

If the functionality is provided by communicating over a network connection with a physically external cryptographic device, then the ST author must include FTP_ITC.1 with “external cryptographic module” selected.

The individual cryptographic SFRs may have Assurance Activities in addition to those specified below; the intent is that the Assurance Activities below augment those that are provided for the individual cryptographic SFRs.

FCS_STG_EXT.1 Cryptographic Key Storage

FCS_STG_EXT.1.1

Persistent private and secret keys shall be stored within the [selection: TSF, Operational environment] [selection:

encrypted within a hardware rooted key hierarchy established in accordance with [selection: FCS_CKM_EXT.1/KEK, FCS_CKM_EXT.1/KEKT], FCS_CKM_EXT.7, and FCS_CKM_EXT.8
in a hardware cryptographic module

Application Note: This requirement ensures that persistent secret keys and private keys are stored securely when not in use. If some secrets/keys are manipulated by the TOE and others are manipulated by the environment, then both of the selections can be specified by the ST author and the ST author must identify in the TSS those keys which are manipulated by the TOE and those by the environment.

If the TOE is an application, and not a dedicated server, then it should store its private keys in the environment-provided key storage.

The ST author is responsible for selecting the manner in which the keys are stored and where they are stored in the selections above.

This SFR applies only to keys that are relevant to the requirements in the PP/ST; it does not apply to keys that have no bearing on CA PP functionality.

5.1.5 Class: User Data Protection (FDP)

FDP_CER_EXT.1 Certificate Profiles

FDP_CER_EXT.1.1

This SFR is defined in the X.509 FP. A review of these two versions of the SFRs is needed to determine the appropriate assignments/selections such that the configuration is comparable to its old definitions. The TSF shall implement a certificate profile function and shall ensure that issued certificates are consistent with configured profiles.

FDP_CER_EXT.1.2

The TSF shall generate certificates using profiles that comply with requirements for certificates as specified in IETF RFC 5280, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, while ensuring that the following conditions are met:

The version field shall contain the integer 2.
The issuerUniqueID or subjectUniqueID fields are not populated.
The serialNumber shall be unique with respect to the issuing Certification Authority
The validity field shall specify a notBefore value that does not precede the current time and a notAfter value that does not precede the value specified in notBefore.
The issuer field is not empty.
The signature field and the algorithm in the subjectPublicKeyInfo field shall contain the OID for a signature algorithm specified in FCS_COP.1/Sig.
The following extensions are supported:
1. subjectKeyIdentifier
2. authorityKeyIdentifier
3. basicConstraints
4. keyUsage
5. extendedKeyUsage
6. certificatePolicy
A subject field containing a null Name (e.g., a sequence of zero relative distinguished names) is accompanied by a populated critical subjectAltName extension.
The subjectKeyIdentifier extension is populated with a value unique for each public key contained in a certificate issued by the TSF.
The authorityKeyIdentifier extension in any certificate issued by the TOE must be populated and must be the same as the subjectKeyIdentifier extension contained in the issuer’s signing certificate.
Populated keyUsage and extendedKeyUsage fields in the same certificate contain consistent values.

Application Note: FDP_CER_EXT.1.2 is intended to clarify the standard interpretation that subject key identifiers MUST be unique to a public key in a certificate issued by a CA (not that the public keys are unique). The intended meaning is that it is acceptable to issue a certificate with a public key contained in a request that happens to match another certificate issued by the CA when the other certificate also contains the requested public key; it is not acceptable that requests for certificates containing different public keys result in the same subject key identifier - as this would contradict the definition of the subject key identifier included in the RFC: "The subject key identifier extension provides a means of identifying certificates that contain a particular public key." This is not possible if the value is not unique to the public keys it issues.

The SFR refines RFC 5280 by requiring all certificate profiles used by the TOE be configurable to include the subject key identifier; the RFC only requires it for CA certificates. The RFC indicates a CA SHOULD provide subject key identifiers for end entity certificates.

When a single instance of the TOE represents multiple CAs, it is acceptable that a subject key identifier issued by one CA match the subject key identifier of another CA, whether implemented within the TOE or as a separate instance.

FDP_CER_EXT.1.3

The TSF shall be able to generate at least 20 bits of random for use in issued certificates to be included in [selection: serialNumber, notBefore, notAfter] fields, where the random values are generated in accordance with FCS_RBG_EXT.1.

Application Note: The requirement applies only to the issuance of X.509 v3 certificates. An optional requirement in Annex A allows for the issuance of X.509 certificates other than V3.

Consistency is defined in RFC5280 for FDP_CER_EXT.1.2, item i; specifically, for each extendedKeyUsage purpose specified, there must be a consistent keyUsage purpose set.

RFC updates to RFC 5280 are included in this requirement.

The random input to issued certificates in FDP_CER_EXT.1.3 can be spread across multiple of the selectable fields so that the total number of inserted bits is at least 20. Select all that apply.

Evaluation Activities

FDP_CER_EXT.1

TSS

The evaluator shall examine the TSS to ensure it describes the certificate profile function in accordance with FDP_CER_EXT.1.1 The TSS shall describe how certificate profiles are configured and then selected to issue certificates in accordance with FDP_CER_EXT.1.2. The evaluator shall also ensure that the TSS describes how the TSF ensures that a certificate-requesting subject possesses the applicable private key. Finally, the evaluator shall ensure that the TSS describes how 20 bits of random are generated in accordance with FDP_CER_EXT.1.3 and which certificate fields are involved.

Guidance

The evaluator shall examine the operational guidance to ensure that instructions are available to configure certificate profiles used for certificate generation in accordance with this requirement. The operational guidance shall also specify how to configure proof of possession and, if applicable, how to configure unique serial number generation.

Tests

The evaluator shall perform the following tests for each supported certificate format:

Test FDP_CER_EXT.1:1: The evaluator shall configure a certificate profile using the available guidance, request a certificate using the profile, and then examine the certificate contents to ensure it matches the configured certificate profile.
Test FDP_CER_EXT.1:2: The evaluator shall specifically examine the certificate generated in Test 1 to ensure that it satisfies all field constraints in FDP_CER_EXT.1.2.
Test FDP_CER_EXT.1:3: The evaluator shall test the fields “d”, “e”, “f”, and “i” in FDP_CER_EXT.1.2 as follows:

Field “d”: The evaluator shall send a request with a subjectPublicKeyInfo that is allowed by the profile, and observe the request succeeds. The evaluator shall then send a request with a subjectPublicKeyInfo that is not allowed by the profile, and observe that the request is rejected (or the value that is put into the certificate is what was in the profile).

Field “e”: The evaluator shall send a request with a KeyUsage that is allowed by the profile, and observe the request succeeds. The evaluator shall then send a request with a KeyUsage that is not allowed by the profile, and observe that the request is rejected (or the value that is put into the certificate is what was in the profile).

Field “f”: The evaluator shall send requests to show that the CA accepts requests that provide an identifier in either one or both of the subject and subjectAltName fields, but rejects requests that do not provide an identifier for either one of those fields.

Field “i”: For each EKU listed in section 4.2.1.12 of RFC 5280, the evaluator performs the following tests. The evaluator shall send a request with a KeyUsage that is consistent (as documented in section 4.2.1.12 of RFC 5280) with the profile EKU, and observe the request succeeds. The evaluator shall then send a request with a KeyUsage that is not consistent (as documented in section 4.2.1.12 of RFC 5280) with the profile EKU, and observe that the request is rejected. The evaluator shall send the EKU to a profile with a consistent KeyUsage (but no specified EKU) and observe the request succeeds. The evaluator shall send the EKU to a profile with an inconsistent KeyUsage (but no specified EKU) and observe the request is rejected.
Test FDP_CER_EXT.1:4: For each extendedKeyUsage value defined in section 4.2.1.12 of RFC 5280, the evaluator shall attempt to configure a certificate profile with each inconsistent keyUsage for that extendedKeyUsage field. If the CA rejects the attempt to create such a profile, then the test succeeds. If the creation of such a profile is allowed, the evaluator shall submit a certificate request using the profile, and show that the TSF does not issue the certificate.
Test FDP_CER_EXT.1:5: The evaluator shall configure a certificate profile and create a certificate request that violates the validity period setting in the configured profile (e.g., notBefore precedes the current time, the combination of notBefore and notAfter is beyond the validity period setting). The evaluator shall submit the certificate request using the profile and verify that the TSF rejects the request.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FDP_CER_EXT.2 Certificate Request Matching

FDP_CER_EXT.2.1

This SFR is defined in the X.509 FP. A review of these two versions of the SFRs is needed to determine the appropriate assignments/selections such that the configuration is comparable to its old definitions. Note that the X.509 FP version of this SFR goes into substantially more detail than this version. The TSF shall establish a linkage from certificate requests to issued certificates.

FDP_CER_EXT.3 Certificate Issuance Approval

FDP_CER_EXT.3.1

The TSF shall support the approval of certificates by [selection: RA, AOR, CA, Operations Staff, rules] issued according to a configured certificate profile.

Evaluation Activities

FDP_CER_EXT.3

TSS

The evaluator shall examine the TSS to ensure it describes the certificate issuance approval function, including the available interfaces that must be used.

The evaluator shall examine the operational guidance to ensure that it contains instructions for any configuration aspects of the certificate issuance approval function and the steps needed to perform an approval.

Guidance

There are no additional Guidance evaluation activities for this component.

Tests

The evaluator shall perform the following test:

Test FDP_CER_EXT.3:1: The evaluator shall configure the certificate issuance approval function in accordance with the operational guidance. The evaluator shall create a certificate request and submit it to the TOE. The evaluator shall access the TOE using the defined interface and verify that the submitted request is in the appropriate queue. The evaluator shall then assume either the CA Operations Staff role or the RA Staff role and approve the certificate request and issue the certificate. The evaluator shall verify that a certificate was issued.

FDP_CER_EXT.3.1

Test FDP_CER_EXT.3:2: The evaluator shall construct one or more certificate requests that meet the rules for automatic approval, and shall verify that each requested certificate was issued.
Test FDP_CER_EXT.3:3: The evaluator shall attempt to construct one or more certificate requests that violate the rules for automatic approval, and shall verify that the requested certificates are not issued.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FDP_CSI_EXT.1 Certificate Status Information

FDP_CSI_EXT.1.1

This SFR is defined in the X.509 FP. A review of these two versions of the SFRs is needed to determine the appropriate assignments/selections such that the configuration is comparable to its old definitions. Note that the X.509 FP version of this SFR contains an additional element compared to this version. The TSF shall provide certificate status information whose format complies with [selection:

ITU-T Recommendation X.509v1 CRL
ITU-T Recommendation X.509v2 CRL
the OCSP standard as defined by [selection: RFC 6960, other OCSP standard]

FDP_CSI_EXT.1.2

The TSF shall support the approval of changes to the status of a certificate by [selection: RA, CA operations staff, rules].

Application Note: Based on the selection, the ST author must choose the appropriate requirements from Annex B.

The ST should specify the format used to supply certificate status information. If other OCSP standard is selected, only current standards shall be selected, the RFC shall be referenced, and any optional features within the RFC shall be specified.

The various iterations of FMT_MOF.1 defines the role or roles authorized to approve changes to a certificate’s status.

The “changes” referenced in FDP_CSI_EXT.1.2 are the revocation requests received by the TOE.

Evaluation Activities

FDP_CSI_EXT.1

TSS

The evaluator shall examine the TSS to ensure it describes the certificate status function and applicable formats, in accordance with this requirement, that can be used to issue certificate status. The TSS must reflect the selection made by the ST author as well as the selection-based requirements from Annex B.

For TOEs that support OCSP, the TOE’s ST shall specify the OCSP standard and the ST author shall ensure that a description of the format is available.

The evaluator shall also ensure that the TSS describes the process for approving changes to the status of a certificate, including the interfaces that must be used.

If the TOE supports the configuration of certificate status information, the evaluator shall examine the operational guidance to ensure that instructions are available to configure the certificate status function to utilize the formats identified in FDP_CSI_EXT.1.1.

Guidance

The evaluator shall examine the operational guidance to ensure that it contains instructions for any configuration aspects of the certificate status change approval function and the steps needed to perform an approval.

Tests

Based on the selection, the evaluator shall perform the applicable tests associated with the requirements in Annex C:

Test FDP_CSI_EXT.1:1: For certificate status information, the evaluator shall configure the TSF to provide certificate status information according to each format identified in FDP_CSI_EXT.1.1 in turn and request certificate status for each format. Each certificate status response shall be examined to ensure that it conforms to the format as described in the TSS.
Test FDP_CSI_EXT.1:2: For each selected certificate status format, the evaluator shall issue a valid certificate from the TOE. The evaluator shall then cause the TOE to issue certificate status information. The evaluator shall check the certificate status information to verify that it reflects that the certificate is valid.
Test FDP_CSI_EXT.1:3: For each selected certificate status format, the evaluator shall revoke a valid certificate from the TOE. The evaluator shall then cause the TOE to issue certificate status information. The evaluator shall check the certificate status information to verify that it reflects that the certificate is revoked.
Test FDP_CSI_EXT.1:4: The evaluator shall configure the certificate status change approval function in accordance with the operational guidance. The evaluator shall create a certificate status change request and submit it to the TOE. The evaluator shall access the TOE using the defined interface and verify that the submitted request is in the appropriate queue. The evaluator shall approve the certificate status change request. The evaluator shall then cause the TOE to issue certificate status information. The evaluator shall check the certificate status information to verify that it reflects the state of the certificate.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FDP_RIP.1 Subset Residual Information Protection

FDP_RIP.1.1

The TSF shall ensure that any previous information content of a resource is made unavailable upon the [selection: allocation of the resource to, deallocation of the resource from] the following objects: [assignment: list of objects].

Application Note: “Resources” in the context of this requirement are any data buffers used to implement certificate authority functions, including network communications with the Certificate Authority. The concern is that a buffer or memory area might be reused in subsequent function or communication channel resulting in inappropriate disclosure of sensitive data. Note that this requirement applies only to resources that the TSF controls. “Objects” refers to any sensitive data objects that are under control of the TSF, such as subscribers’ personally identifiable information.

The first selection should include ‘Operational Environment’ if the TSF depends on a component of the OE to store and protect TSF data. The ST should specify the component and any interface used to meet this requirement.

5.1.6 Class: Identification and Authentication (FIA)

FIA_UAU_EXT.1 Authentication Mechanism

FIA_UAU_EXT.1.1

The TSF shall [selection: provide, interface with the OE to provide] a [selection: password-based authentication mechanism, [assignment: other authentication mechanism(s)]] to perform privileged user authentication.

Application Note: Examples of “other authentication mechanisms” for the selection include onetime password mechanisms such as RSA SecurID, certificates, and biometrics.

FIA_UIA_EXT.1 User Identification and Authentication

FIA_UIA_EXT.1.1

The TSF shall allow the following actions prior to requiring a non-TOE entity to initiate the identification and authentication process:

Display the warning banner in accordance with FTA_TAB.1;
Obtain certificate status information;
[selection: download certificate from repository, no other actions, [assignment: list of services or actions performed by the TSF in response to non-TOE entity request]]

Application Note: A “non-TOE entity” refers to users (privileged user, subscribers, and relying parties) of services available from the TOE directly. If the TOE is able to download certificates from the certificate repository prior to initiating the I&A process, the ST author includes that item in the ST. While it should be the case that few or no services are available to external entities prior to identification and authentication, if there are some available to non-TOE entities, these should be listed in the assignment statement; otherwise “no other actions” should be selected.

FIA_UIA_EXT.1.2

The TSF shall require each user to be successfully identified and authenticated before allowing any other TSF-mediated actions on behalf of that user, including subscriber certificate renewal, subscriber revocation requests, privileged user access, [selection: no other actions, [assignment: other TSF-mediated actions]].

FIA_UIA_EXT.1.3

For subscriber actions, the TSF shall verify that the DN of the certificate presented by the subscriber for authentication matches that of the certificate being affected by the subscriber’s actions.

Application Note: Authentication can be password-based through the local console or through a protocol that supports passwords (such as SSH), or certificates (such as TLS).

Certificate renewal and certificate revocation requests can be performed by subscribers with valid certificates and are limited to actions on those certificates; subscribers cannot renew or revoke other users’ certificates. Privileged user access requires further authentication. If there are other actions available to authenticated users, these should be listed in the assignment; otherwise, “no other actions” should be selected.

Evaluation Activities

FIA_UIA_EXT.1

TSS

The evaluator shall examine the TSS to ensure it describes the logon process for each logon method (local, remote (HTTPS, SSH, etc.)) supported for the TOE. This description shall contain information pertaining to the credentials allowed/used, any protocol transactions that take place, and what constitutes a “successful logon”.

The evaluator shall examine the TSS to determine that it describes all actions that can be performed prior to I&A as well as all actions that require successful I&A, and by whom these actions can be performed. Any constraints on these services shall be documented in the TSS.

Guidance

The evaluator shall examine the operational guidance to determine that any necessary preparatory steps (e.g., establishing credential material such as preshared keys, tunnels, certificates, etc.) to logging in are described. For each supported login method, the evaluator shall ensure the operational guidance provides clear instructions for successfully logging on. If configuration is necessary to ensure the services provided before login are limited, the evaluator shall determine that the operational guidance provides sufficient instruction on limiting all allowed services. The evaluator shall examine the operational guidance to verify that it describes how to configure the constraints on each type of subscriber self-service request.

Tests

The evaluator shall perform the following tests for each method by which privileged users access the TOE (local and remote), as well as for each type of credential supported by the access method in accordance with the authentication mechanisms listed in FIA_UAU_EXT.1:

Test FIA_UIA_EXT.1:1: The evaluator shall use the operational guidance to configure the appropriate credential supported for the access method. For that credential/access method, the evaluator shall show that providing correct I&A information results in the ability to access the system, while providing incorrect information results in denial of access.
Test FIA_UIA_EXT.1:2: The evaluator shall configure the non-authenticated services allowed according to the operational guidance, and then determine the services available to an external remote entity (including subscribers and relying parties). The evaluator shall determine that the list of services available is limited to those specified in the requirement. The evaluator shall also verify that non-authenticated remote entities cannot access the services listed in FIA_UIA_EXT.1.2 that require I&A.
Test FIA_UIA_EXT.1:3: For local access, the evaluator shall exercise the services in accordance with FIA_UIA_EXT.1.1 available to a local privileged user prior to I&A, and make sure this list is consistent with the requirement.
Test FIA_UIA_EXT.1:4: The evaluator shall configure the constraints on subscriber self-service requests. The evaluator shall assume a CA Operations Staff or RA Staff role and issue a certificate to at least one unique subscriber. For each configured service, the evaluator shall request authorized activities using the issued certificates and verify that they can be performed.
Test FIA_UIA_EXT.1:5: The evaluator shall configure the constraints on subscriber self-service requests. The evaluator shall assume a CA Operations Staff or RA Staff role and issue a certificate to at least two unique subscribers. For each configured service, the evaluator shall request authorized activities using one issued certificate for the other subscriber’s information and shall verify that the request is denied. The evaluator shall request unauthorized activities using one issued certificate and shall verify that the request is denied.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FIA_X509_EXT.1 Certificate Validation

FIA_X509_EXT.1.1

This SFR is defined in the X.509 FP. A review of these two versions of the SFRs is needed to determine the appropriate assignments/selections such that the configuration is comparable to its old definitions. Note that the X.509 version of this SFR has been refactored significantly and is substantially more open-ended than this SFR. The TSF shall [selection: validate, interface with the Operational Environment to validate] certificates in accordance with the following rules:

IETF RFC 5280 certificate validation and certificate path validation.
The certificate path must terminate with a certificate in the Trust Anchor Database.
The TSF shall validate a certificate path by ensuring the presence of the basicConstraints extension and that the cA flag is set to TRUE for all CA certificates.
The TSF shall validate the revocation status of the certificate using [selection: the Online Certificate Status Protocol (OCSP) as specified in FDP_CSI_EXT.1, a Certificate Revocation List (CRL) as specified in FDP_CSI_EXT.1].
The TSF shall validate the extendedKeyUsage field according to the following rules:
- Certificates used for trusted updates and executable code integrity verification shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3),
- Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field,
- Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.

Application Note: The TSF may rely on the Operational Environment to perform certificate handling functionality in cases where the TOE relies on an environmental component to provide trusted remote communications.

FIA_X509_EXT.1 lists the rules for validating certificates. The ST author shall select whether revocation status is verified using OCSP or CRLs. Depending on this selection, the appropriate CRL or OCSP requirements from Annex B must be included.

Certificates may optionally be used for trusted updates of TSF Software (FPT_TUD_EXT.1) and for data/software integrity verification (FPT_TST_EXT.2) and, if implemented, must be validated to contain the Code Signing purpose extendedKeyUsage.

Whenever TLS or HTTPS is used by the TSF to protect communications originating from external IT entities, certificates used to perform authentication must be validated to contain the Client Authentication purpose extendedKeyUsage.

Whenever the TOE originates messaging to external IT services using TLS or HTTPS, certificates must be used to perform the authentication and must be validated to contain the Server Authentication purpose extendedKeyUsage.

It should be noted that in all cases, the validation is expected to end in a trusted root certificate.

FIA_X509_EXT.1.2

The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE.

Application Note: This requirement applies to certificates that are used and processed by the TSF and restricts the certificates that may be added to the Trust Anchor Database.

Evaluation Activities

FIA_X509_EXT.1

TSS

The evaluator shall examine the TSS to ensure it describes where the check of validity of the certificates takes place. The evaluator shall ensure the TSS also provides a description of the certificate path validation algorithm for each certificate format supported by the TOE.

Guidance

There are no AGD assurance activities for this requirement beyond what is necessary to satisfy the requirements in [CEM].

Tests

The evaluator shall perform the following tests in conjunction with the other Certificate Services assurance activities, including the use cases in FIA_X509_EXT.2.1. The tests for the extendedKeyUsage rules are performed in conjunction with the uses that require those rules.

Test FIA_X509_EXT.1:1: The evaluator shall demonstrate that validating a certificate without a valid certification path results in the function (application validation, trusted channel setup, or trusted software update) failing. The evaluator shall then load a certificate or certificates needed to validate the certificate to be used in the function, and demonstrate that the function succeeds. The evaluator then shall delete one of the certificates, and show that the function fails.
Test FIA_X509_EXT.1:2: The evaluator shall demonstrate that validating an expired certificate anywhere in a certificate path results in the function failing.
Test FIA_X509_EXT.1:3: The evaluator shall test that the TOE can properly handle revoked certificates –conditional on whether CRL or OCSP is selected; if both are selected, and then a test is performed for each method. The evaluator has to only test one up in the trust chain (future revisions may require to ensure the validation is done up the entire chain). The evaluator shall ensure that a valid certificate is used, and that the validation function succeeds. The evaluator shall then attempt the test with a certificate that will be revoked (for each method chosen in the selection) and verify that the validation function fails.
Test FIA_X509_EXT.1:4: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the CA’s certificate does not contain the basicConstraints extension. The validation of the certificate path fails.
Test FIA_X509_EXT.1:5: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the CA’s certificate has the cA flag in the basicConstraints extension not set. The validation of the certificate path fails.
Test FIA_X509_EXT.1:6: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the CA’s certificate has the cA flag in the basicConstraints extension set to TRUE. The validation of the certificate path succeeds.
Test FIA_X509_EXT.1:7: The evaluator shall modify a single byte in the certificate and verify that the certificate fails to validate.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FIA_X509_EXT.2 Certificate-based Authentication

FIA_X509_EXT.2.1

This SFR is defined in the X.509 FP. A review of these two versions of the SFRs is needed to determine the appropriate assignments/selections such that the configuration is comparable to its old definitions. Note that the X.509 version of this SFR is more open-ended and it lacks an explicit element to deny invalid peer certificates akin to FIA_X509_EXT.2.3. The TSF shall [selection: use, interface with the Operational Environment to use] X.509v3 certificates as defined by RFC 5280 to support authentication for code signing for TOE updates, [selection: IPsec, TLS, HTTPS, SSH], and [selection: integrity verification for TSF protected data, integrity verification for TSF software and firmware, [assignment: other uses], no additional uses].

Application Note: The ST author‘s selection of trusted communication channel is expected to match the selections in FTP_TRP.1.1 and FTP_ITC.1.1 (if FTP_ITC.1 is included in the ST). Certificates may optionally be used for integrity verification (FPT_TST_EXT.2) and other uses.

FIA_X509_EXT.2.2

When the TSF cannot determine the current revocation status of a certificate, the TSF shall [selection: allow the administrator to choose whether to accept the certificate, accept the certificate, not accept the certificate].

Application Note: The TSF may rely on the Operational Environment to perform certificate handling functionality in cases where the TOE relies on an environmental component to provide trusted remote communications. If the ST author selects SSH, the TSF shall be validated against the Functional Package for Secure Shell (SSH), version 2.0.

Often a connection must be established to perform a verification of the revocation status of a certificate - either to download a CRL or to perform OCSP. The selection is used to describe the behavior in the event that such a connection cannot be established (for example, due to a network error). If the TOE has determined the certificate valid according to all other rules in FIA_X509_EXT.1, the behavior indicated in the second selection shall determine the validity. The TOE must not accept the certificate if it fails any of the other validation rules in FIA_X509_EXT.1. If the administrator-configured option is selected by the ST author, the ST author must also select function 22 in FMT_SMF.1.

FIA_X509_EXT.2.3

The TSF shall not establish a trusted communication channel if the peer certificate is deemed invalid.

Evaluation Activities

FIA_X509_EXT.2

TSS

The evaluator shall examine the TSS to ensure it describes the certificate(s) used by the TOE, the different uses for each certificate, and how the TSF chooses which certificates to use. The evaluator shall examine the TSS to confirm that it describes the behavior of the TOE when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel.

Guidance

The evaluator shall examine the operational guidance to ensure clear instructions for configuring the operating environment so that the TOE can use the certificates which are provided. If the requirement is that the administrator is able to specify the default action if the peer certificate is deemed invalid, then the evaluator shall ensure that the operational guidance contains instructions on how this configuration action is performed.

Tests

The evaluator shall perform the following tests:

Test FIA_X509_EXT.2:1: For each function listed in FIA_X509_EXT.2.1 that requires the use of certificates the evaluator shall demonstrate that using a certificate without a valid certification path results in the function failing. Using the operational guidance, the evaluator shall then load a certificate or certificates needed to validate the certificate to be used in the function, and demonstrate that the function succeeds. The evaluator then shall delete one of the certificates, and show that the function fails.
Test FIA_X509_EXT.2:2: The evaluator shall demonstrate that using a valid certificate that requires certificate validation checking to be performed in at least some part by communicating with a non-TOE entity. The evaluator shall then manipulate the environment so that the TOE is unable to verify the validity of the certificate, and observe that the action selected in FIA_X509_EXT.2.2 is performed. If the selected action is administrator-configurable, then the evaluator shall follow the operational guidance to determine that all supported administrator-configurable options behave in their documented manner.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

5.1.7 Class: Security Management (FMT)

Application Note: FMT_MOF.1 has been broken up into several iterations to define the specific management functions that are available to each of the roles defined by FMT_SMR.2. The FMT_MOF.1 iterations restrict some functions to a particular role, and allow the ST author to choose the role to which other functions may be restricted through selections in a particular iteration. The ST author should select those security management functions that belong to the roles supported by the TOE. All TSF management functions need to be specified as being able to be performed by at least one of the defined roles.

FMT_MOF.1/Admin Management of Security Functions Behavior (Administrator Functions)

FMT_MOF.1.1/Admin

The shall restrict the ability to [

manage the TOE locally and remotely;

configure the audit mechanism;

configure and manage certificate profiles;

modify revocation configuration;

perform updates to the TOE;

perform on-demand integrity tests;

import and remove X.509v3 certificates into/from the Trust Anchor Database;

[selection:
Import [assignment: secret and private keys other than the CA’s signing keys]
configure certificate revocation list function;
configure OCSP function;
disable deprecated algorithms;
accept certificates whose validity cannot be determined;
export PKCS#10 certificate request;
import CA certificate;
[assignment: other security management functions]
]

] to [Administrators].

Application Note: It is likely that some combination of the TOE and its Operational Environment are collectively responsible for implementing these management functions. In such cases, the ST author should specify, for each function, the component that enforces it.

If items 13 & 14 are selected for FMT_MOF.1.1/Admin, items 5 & 6 cannot be selected in FMT_MOF.1.1/CA. If items 5 & 6 are selected for FMT_MOF.1.1/CA, items 13 & 14 cannot be selected in FMT_MOF.1.1/Admin.

FMT_MOF.1/Auditor Management of Security Functions Behavior (Auditor Functions)

FMT_MOF.1.1/Auditor

The shall restrict the ability to [
Delete entries from the audit trail

[selection: Search the audit trail, Set or change the retention period parameter for audit records requiring extended retention]
] to [auditors].

FMT_MOF.1/CA Management of Security Functions Behavior (CA Operations Functions)

FMT_MOF.1.1/CA

The shall restrict the ability to [

approve certificate revocation;

[selection:
perform archival and recovery;
import a key share to support recovery of a CA signing key;
approve rulesets that govern the authorizations of RAs to manage particular certificates on behalf of an organization;
export PKCS#10 certificate request;
import CA certificate;
no other function
]

] to [CA Operations Staff].

Application Note: If items 5 & 6 are selected for FMT_MOF.1.1/CA, items 13 & 14 cannot be selected in FMT_MOF.1.1/Admin. If items 13 & 14 are selected for FMT_MOF.1.1/Admin, items 5 & 6 cannot be selected in FMT_MOF.1.1/CA.

FMT_MOF.1/CO Management of Security Functions Behavior (Admin/Officer Functions)

FMT_MOF.1.1/CO

The shall restrict the ability to [
perform destruction of sensitive data when no longer needed;

[selection:
participate as a second party for archival and recovery;
import a key share to support recovery of a CA signing key;
perform encrypted export of private or secret key or critical data
no other function
]

] to [selection: Administrators, Auditor, CA Operations Staff].

Application Note: It is acceptable to have the auditor participate in archive and recovery of the key as one of the parties in a 'two party' procedure; in the current key archive requirements, any participant (including the auditor) only gains access to key shares (but cannot access the key).

FMT_MOF.1/RA Management of Security Functions Behavior (CA/RA Functions)

FMT_MOF.1.1/RA

The shall restrict the ability to

[

approve and execute the issuance of certificates;

configure subscriber self-service request constraints;

[selection:
configure automated certificate approval management;
approve rulesets that govern the authorizations of AORs to manage particular certificates on behalf of an organization;
accept, process and export CMC messages;
no other function
]
] to [selection: CA Operations Staff, RA Staff].

FMT_MTD.1 Management of TSF Data

FMT_MTD.1.1

The TSF shall restrict the ability to manage the TSF data to [privileged users].

Application Note: The word “manage” includes but is not limited to create, initialize, view, change default, modify, delete, clear, and append. This requirement is intended to be the “default” requirement for management of TSF data; other iterations of FMT_MTD should place different restrictions or operations available on the specifically identified TSF data. TSF data includes cryptographic information as well; managing these data would include the association of a cryptographic protocol with an interface, for instance. The specifics of management of data associated with defined operations are contained in the FMT_MOF iterations.

FMT_SMF.1 Specification of Management Functions

FMT_SMF.1.1

The shall be capable of performing the following management functions: [

Ability to manage the TOE locally and remotely;
Ability to perform updates to the TOE;
Ability to perform archival and recovery;
Ability to manage the audit mechanism;
Ability to configure and manage certificate profiles;
Ability to approve and execute the issuance of certificates;
Ability to approve certificate revocation;
Ability to modify revocation configuration;
Ability to configure subscriber self-service request constraints;
Ability to perform on-demand integrity tests;
Ability to destroy sensitive user data when no longer needed;
Ability to import and remove X.509v3 certificates into/from the Trust Anchor Database;
[selection:
- Ability to configure the NPE ruleset;
- Ability to configure automated process used to approve the revocation of a certificate or information about the revocation of a certificate;
- Ability to approve rulesets that govern the authorizations of RAs or AORs to manage particular certificates on behalf of an organization;
- [selection: Ability to modify the CRL configuration, Ability to modify the OCSP configuration]
- Ability to configure the list of TOE-provided services available before an entity is identified and authenticated, as specified in FIA_UIA_EXT.1;
- Ability to configure the cryptographic functionality;
- Ability to import private keys;
- Ability to export TOE private keys (not for archival);
- Ability to disable deprecated algorithms;
- Ability to accept certificates whose revocation status cannot be determined;
- Ability to accept, process and export CMC messages;
- No other capabilities.
]

Application Note: Some TOE functions require the use of the Operational Environment. The ST author simply must make clear in the ST what management functions are performed by the TOE itself or which are performed by the TOE in conjunction with its environment.

Except as indicated below, the security management functions for FMT_SMF.1 are distributed throughout the PP and are included as part of the requirements in FMT_MOF.1 and any cryptographic management functions specified in the reference standards. Compliance to these requirements satisfies compliance with FMT_SMF.1.

FMT_SMR.2 Restrictions on Security Roles

FMT_SMR.2.1

The TSF shall maintain the roles: [

Administrator
Auditor
CA Operations Staff
[selection: RA Staff, Authorized Organizational Representative, no other roles]

FMT_SMR.2.2

The TSF shall be able to associate users with roles.

FMT_SMR.2.3

The TSF shall ensure that the conditions [

No identity is authorized to assume both an Auditor role and any of the other roles in FMT_SMR.2.1; and

No identity is authorized to assume both a CA Operations Staff role and any of the other roles in FMT_SMR.2.1

are satisfied.

Application Note: This document specifies five roles: Administrator, Auditor, CA Operations Staff, Registration Authority, and Authorized Organizational Representative. However, the TOE is not required to maintain all six roles.

5.1.8 Class: Protection of the TSF (FPT)

FPT_FLS.1 Failure with Preservation of Secure State

FPT_FLS.1.1

The TSF shall preserve a secure state when the following types of failures occur: [selection: TSF RBG failure, signature verification failure, integrity test failure, integrity failure on audit, integrity failure on Trust Anchor database, [assignment: other potential TSF failures], [assignment: other potential Operational Environment failures]].

Application Note: The intent of this requirement is to prevent the use of failed randomization and other events that can compromise the operation of the CA. This means that the TOE must be able to attain a secure/safe state when any of the identified failures occurs. If the TOE should encounter a failure in the middle of a critical operation, the TOE should not just quit operating, leaving key material and user data unprotected.

The failure of an Operational Environment component can be just as detrimental to security as a failure of the TSF itself. Therefore, in addition to describing the potential TSF failures and how the TOE preserves a secure state in response, the ST author is also expected to use this SFR to express how the TOE is made aware of any environmental failures and how it responds to these.

FPT_KST_EXT.1 No Plaintext Key Export

FPT_KST_EXT.1.1

The TSF and [selection: Operational Environment, no other component] shall prevent the plaintext export of [assignment: list of all keys used by the TSF].

Application Note: Keys include all TOE secret and private keys, as well as any user secret and private keys. The intent of this optional requirement is to prevent the keys from being exported during an archive event authorized by the TOE user or administrator.

If TSF keys are stored in the OE, the TSF requires support of the OE to meet this requirement. The Operational Environment shall be selected and the specific components used shall be described in the TSS.

FPT_KST_EXT.2 Key Protection

FPT_KST_EXT.2.1

The TSF and [selection: Operational Environment, no other components] shall prevent unauthorized use of all TSF private and secret keys.

Application Note: The intent of this requirement is to protect TSF private and secret keys from both unauthorized users and unprivileged processes. Users should not be able to access the keys through “normal” interfaces.

FPT_RCV.1 Manual Trusted Recovery

FPT_RCV.1.1

After [assignment: list of failures/service discontinuities] the TSF shall enter a maintenance mode where the ability to return to a secure state is provided.

Application Note: This requirement ensures that the TSF can determine that the TOE is started up without protection compromise and can recover without protection compromise after discontinuity of operations. Anticipated failures include actions that result in a system crash, media failures, or discontinuity of operations caused by erroneous administrative action or lack of erroneous administrative action. The data that needs to be restored includes the TSF keys needed for signature, the Trust Anchor Database, keys needed for management of certificates, all signed certificates, and any certificate status information.

FPT_SKP_EXT.1 Protection of Keys

FPT_SKP_EXT.1.1

The TSF shall [selection: implement, interface with the Operational Environment to implement] the ability to prevent reading of all pre-shared keys, private, and secret keys (e.g., KEKs, DEKs, session keys).

Application Note: The intent of the requirement is that an administrator is unable to read or view the identified keys through “normal” interfaces. While it is understood that the administrator could directly read memory to view these keys, to do so is not a trivial task and may require substantial work on the part of an administrator. Since the administrator is considered a trusted agent, it is assumed they would not endeavor in such an activity.

FPT_STM.1 Reliable Time Stamps

FPT_STM.1.1

The TSF shall be able to reliable time stamps.

Application Note: The TSF is expected to use time data for accuracy in signing and verification activities. Depending on the functionality provided by the TOE, it may also use time data for accurate generation of audit logs and secure communications that have a time component.

FPT_TUD_EXT.1 Trusted Update

FPT_TUD_EXT.1.1

The TSF shall [selection: implement, interface with the Operational Environment to implement] the ability to check for updates and patches to the TOE.

FPT_TUD_EXT.1.2

The TSF shall [selection: implement, interface with the Operational Environment to implement] the ability to provide Administrators the ability to initiate updates to TOE firmware/software.

FPT_TUD_EXT.1.3

The TSF shall [selection: implement, interface with the Operational Environment to implement] the ability to verify firmware/software updates to the TOE using a digital signature prior to installing those updates.

FPT_TUD_EXT.1.4

The TSF shall [selection: implement, interface with the Operational Environment to implement] the ability to verify the digital signature whenever the software or firmware is externally loaded into the TOE and if verification fails, the TSF shall [assignment: action to be taken if the verification fails].

Application Note: The digital signature mechanism referenced in the third element is the one specified in FCS_COP.1/Sig.

Evaluation Activities

FPT_TUD_EXT.1

TSS

The evaluator shall verify that the TSS section of the ST describes all TSF software update mechanisms for updating the system software. The evaluator shall verify that the description includes a digital signature verification of the software before installation and that installation fails if the verification fails. The evaluator shall verify that all software and firmware involved in updating the TSF is described and, if multiple stages and software are indicated, that the software/firmware responsible for each stage is indicated and that the stage(s) which perform signature verification of the update are identified.

The evaluator shall verify that the TSS describes the method by which the digital signature is verified.

The evaluator shall verify that the TSS describes that the public key used to verify the signature is either hardware-protected or is validated to chain to a public key in the Trust Anchor Database. If hardware-protection is selected, the evaluator shall verify that the method of hardware-protection is described and that the ST author has justified why the public key may not be modified by unauthorized parties.

[conditional] If the ST author indicates that the public key for software update digital signature verification, the evaluator shall verify that the update mechanism includes a certificate validation according to FIA_X509_EXT.1 and a check for the Code Signing purpose in the extendedKeyUsage.

Guidance

The evaluator shall examine the operational user to ensure it contains the required information regarding TOE version verification and TOE updates as specified in AGD_OPE.1.

Tests

The evaluator shall perform the following tests:

Test FPT_TUD_EXT.1:1: The evaluator shall perform the version verification activity to determine the current version of the product. The evaluator shall obtain a legitimate update using procedures described in the operational guidance and verifies that it is successfully installed on the TOE. Then, the evaluator shall perform a subset of other assurance activity tests to demonstrate that the update functions as expected. After the update, the evaluator shall perform the version verification activity again to verify the version correctly corresponds to that of the update.
Test FPT_TUD_EXT.1:2: The evaluator shall obtain or produce an illegitimate update, and shall attempt to install it on the TOE. The evaluator shall verify that the TOE rejects the update.
Test FPT_TUD_EXT.1:3: The evaluator shall obtain or produce an update with an invalid signature, and shall attempt to install it on the TOE. The evaluator shall verify that the TOE rejects the update and performs any other actions specified in the TSS.
Test FPT_TUD_EXT.1:4: [conditional] If the TOE supports use of X509 certificates for code signing, the evaluator shall digitally sign the update with a certificate that does not have the Code Signing purpose and verify that application installation fails. The evaluator shall repeat the test using a valid certificate and a certificate that contains the Code Signing purpose and verify that the application installation succeeds.
Test FPT_TUD_EXT.1:5: The tester shall attempt to install an update without the digital signature and shall verify that installation fails. The tester shall attempt to install an update with altered digital signature, and verify that installation fails.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

5.1.9 Class: TOE Access (FTA)

FTA_SSL.4 User-Initiated Termination

FTA_SSL.4.1

The TSF shall allow user-initiated termination of the user’s own interactive session.

FTA_TAB.1 Default TOE Access Banners

FTA_TAB.1.1

Before establishing a user session the [selection: TSF, TOE platform] shall display an [Administrator-configured advisory notice and consent warning regarding unauthorized use of the TOE] message.

Application Note: This requirement is intended to apply to interactive sessions between a human user and a TOE. IT entities establishing connections or programmatic connections (e.g., remote procedure calls over a network) are not required to be covered by this requirement.

5.1.10 Class: Trusted Path/Channels (FTP)

FTP_TRP.1 Trusted Path

FTP_TRP.1.1

The TSF shall provide a communication path between itself and [remote subscribers and privileged] users that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from [modification, disclosure].

FTP_TRP.1.2

The TSF shall permit [remote subscribers and privileged users] to initiate communication via the trusted path.

FTP_TRP.1.3

The TSF shall require the use of the trusted path for [[initial subscriber and privileged user authentication and all remote administration actions]].

Application Note: This requirement ensures that remote subscribers and privileged users initiate all communication with the TOE via a trusted path, and that all communications with the TOE by remote subscribers and privileged users is performed over this path. The data passed in this trusted communication channel are encrypted as defined the protocol chosen in the first selection. The ST author chooses the mechanism(s) supported by the TOE and ensures the detailed requirements in Annex B corresponding to their selection are copied to the ST if not already present.

5.1.11 TOE Security Functional Requirements Rationale

The following rationale provides justification for each SFR for the TOE, showing that the SFRs are suitable to address the specified threats:

Table 3: SFR Rationale
Threat	Addressed by	Rationale
T.PRIVILEGED_USER_ERROR	FAU_ADP_EXT.1	Requires the TSF to implement or support audit functionality.
	FAU_STG.5	Prevents audited events if the audit trail cannot be written to.
	FIA_UAU_EXT.1	Requires that he TSF provide a mechanism for authenticating privileged users.
	FIA_UIA_EXT.1	Defines the actions permitted prior to authentication of a user.
	FMT_MOF.1/Admin	Defines management functions to be performed exclusively by Administrators.
	FMT_MOF.1/Auditor	Defines management functions to be performed by auditors.
	FMT_MOF.1/CA	Defines management functions to be performed by CA Staff.
	FMT_MOF.1/CO	Defines management functions to be performed by Administrators, Auditor, or CA Staff.
	FMT_MOF.1/RA	Defines management functions to be performed by CA or RA Staff.
	FMT_MTD.1	Requires that only privileged users manage TSF data.
	FMT_SMF.1	Defines management functions implemented or supported by the TOE.
	FMT_SMR.2	Defines user roles maintained or supported by the TSF.
	FTA_SSL.4	Requires that the TSF support user-initiated termination of their own SSL sessions.
	FTA_SSL_EXT.1 (optional)	(Optional) Requires an inactivity timeout on local user sessions.
	FTA_SSL.3 (optional)	(Optional) Requires an inactivity timeout on remote user sessions.
	FTA_SSL_EXT.1 (optional)	(Optional) Requires an inactivity timeout on local user sessions.
	FAU_STG.2/EXT (selection-based)	Requires the TSF protect audit records from unauthorized deletion.
	FAU_STG.2/STA (selection-based)	Requires that audit records with retention requirements be retained for the appropriate period.
	FAU_STG_EXT.1 (selection-based)	Specifies rules for the retention of audit data.
	FIA_AFL.1 (selection-based)	Requires that the TSF detect excessive unsuccessful login attempts from a remote user.
	FIA_PMG_EXT.1 (selection-based)	Specifies password composition rules.
	FIA_UAU.7 (selection-based)	Defines feedback permitted to the user during authentication.
	FPT_APW_EXT.1 (selection-based)	Defines protections for plaintext passwords.
T.TSF_FAILURE	FPT_FLS.1	Requires that the TSF enters a secure state if failures in the TSF occur.
	FPT_RCV.1	Requires that the TSF provide a maintenance mode where the ability to return to secure state is provided.
	FPT_TST_EXT.1 (optional)	(Optional) Requires the TSF ensure the integrity of TOE software and firmware.
	FPT_TST_EXT.2 (optional)	(Optional) Requires the TSF ensure the integrity of certain data relevant to TOE security.
	FPT_TST.1 (selection-based)	Requires that the TSF test the health of the DRBG.
T.UNAUTHENTICATED_TRANSACTIONS	FCO_NRO_EXT.2	Requires that the TSF provide proof of origin for certificates it issues.
	FCS_CDP_EXT.1	Requires that the TSF implements or invokes cryptographic functionality.
	FDP_CER_EXT.1	Requires that the TSF support configured certifcate profiles.
	FDP_CER_EXT.2	Requires that TSF associate certificate requests with certificates.
	FDP_CER_EXT.3	Requires that the TSF support approval of certificates against profiles.
	FDP_CSI_EXT.1	Requires that the TSF provide formatted certificate status information.
	FIA_X509_EXT.1	Requires the TSF support validation of certificates according to a set of rules.
	FIA_X509_EXT.2	Requires that the TOE use X.509 certificates for code signing and other purposes.
	FIA_X509_EXT.3	Requires that the TOE support the use of Certificate Requests to receive a certificate chain.
	FMT_MOF.1/Admin	Defines management functions to be performed exclusively by Administrators.
	FMT_MOF.1/Auditor	Defines management functions to be performed by auditors.
	FMT_MOF.1/CA	Defines management functions to be performed by CA Staff.
	FMT_MOF.1/CO	Defines management functions to be performed by Administrators, Auditor, or CA Staff.
	FMT_MOF.1/RA	Defines management functions to be performed by CA or RA Staff.
	FMT_MTD.1	Requires that only privileged users manage TSF data.
	FDP_CER_EXT.4 (optional)	(Optional) Requires that non-v3 certificates have certain characteristics.
	FDP_STG_EXT.1(optional)	(Optional) Requires that the TSF protect trusted public keys and certificates.
	FPT_NPE_EXT.1 (optional)	(Optional) Requires the TSF enforce rules for submitting NPE certificate requests.
	FPT_TST_EXT.1 (optional)	(Optional) Requires the TSF ensure the integrity of TOE software and firmware.
	FPT_TST_EXT.2 (optional)	(Optional) Requires the TSF ensure the integrity of certain data relevant to TOE security.
	FIA_ENR_EXT.1 (objective)	Requires the TSF to use secure request mechanisms to receive a CA certificate for the TSF's use.
	FIA_ESTC_EXT.2 (objective)	Requires that the TSF use a strengthened implementation of EST through the incorporation of the tls-unique values in its generated requests.
	FIA_ESTS_EXT.2 (objective)	Requires that the TSF use a strengthened implementation of EST through the verification of tls-unique values in requests it receives.
	FCO_NRR_EXT.2 (selection-based)	Requires that the TSF provide certificate-based proof of receipt.
	FCS_CKM_EXT.5 (selection-based)	Requires that the TSF protect public keys from modification.
	FIA_CMCC_EXT.1(selection-based)	Specifies requirements for CMC requests and responses.
	FIA_CMCS_EXT.1 (selection-based)	Defines the types of CMC requests handled by the TSF.
	FIA_ESTC_EXT.1 (selection-based)	Specifies requirements for client-side EST enrollment requests.
	FIA_ESTS_EXT.1 (selection-based)	Specifies requirements for EST enrollment requests.
	FDP_CRL_EXT.1 (selection-based)	Specifies contents for certificate revocation lists.
	FDP_OCSPG_EXT.1 (selection-based)	Specifies the contents of OCSP response messages.
	FDP_SDP_EXT.1 (selection-based)	(Optional) Requires that the TSF protect certain information through encryption.
	FDP_ITT.1 (selection-based)	Requires that the TSF protect user data during transmission between physically separate parts of the TOE.
	FPT_ITT.1 (selection-based)	Requires that the TSF protect data transmitted between different parts of the TOE.
	FPT_TST.1 (selection-based)	Requires that the TSF test the health of the DRBG.
T.UNAUTHORIZED_ACCESS	FCS_CDP_EXT.1	Requires that the TSF implements or invokes cryptographic functionality.
	FCS_STG_EXT.1	Requires secure storage of private and secret keys.
	FIA_UAU_EXT.1	Requires that he TSF provide a mechanism for authenticating privileged users.
	FIA_UIA_EXT.1	Defines the actions permitted prior to authentication of a user.
	FMT_MOF.1/Admin	Defines management functions to be performed exclusively by Administrators.
	FMT_MOF.1/Auditor	Defines management functions to be performed by auditors.
	FMT_MOF.1/CA	Defines management functions to be performed by CA Staff.
	FMT_MOF.1/CO	Defines management functions to be performed by Administrators, Auditor, or CA Staff.
	FMT_MOF.1/RA	Defines management functions to be performed by CA or RA Staff.
	FMT_MTD.1	Requires that only privileged users manage TSF data.
	FMT_SMF.1	Defines management functions implemented or supported by the TOE.
	FMT_SMR.2	Defines user roles maintained or supported by the TSF.
	FPT_KST_EXT.1	Requires that the TSF prevent export of plaintext keys.
	FPT_KST_EXT.2	Requires that the TSF prevent unauthorized use of private and secret keys.
	FPT_SKP_EXT.1	Requires that the TSF be able to prevent reading of pre-shared, private and secret keys.
	FTA_SSL.4	Requires that the TSF support user-initiated termination of their own SSL sessions.
	FTP_TRP.1	Requires the TSF to provide a trusted path to remote entities.
	FCS_COP.1/PBKDF (optional)	(Optional) Requires the TSF to support password-based key derivation.
	FPT_SKY_EXT.1/CA (optional)	(Optional) Requires two-party control for the export of CA signing keys.
	FPT_SKY_EXT.1/OTH (optional)	(Optional) Requires two-party control for the export of other sensitive data or keys.
	FTA_SSL.3 (optional)	(Optional) Requires an inactivity timeout on remote user sessions.
	FTA_SSL_EXT.1 (optional)	(Optional) Requires an inactivity timeout on local user sessions.
	FCS_KSH_EXT.1 (objective)	Requires two-party control for the export of critical keys to the CA operation.
	FCS_COP.1/Hash (selection-based)	Defines permissible cryptographic hash algorithms and sizes.
	FCS_COP.1/KeyedHash (selection-based)	Defines permissible keyed-hash message authentication algorithms.
	FCS_COP.1/Sig (selection-based)	Defines permissible cryptographic signature algorithms.
	FCS_COP.1/SKC (selection-based)	Defines permissible AES encryption algorithms and key sizes.
	FCS_CKM.1 (selection-based)	Specifies allowable algorithms for generation of asymmetric keys.
	FCS_CKM.2 (selection-based)	Specifies allowable algorithms for key establishment.
	FCS_CKM.6 (selection-based)	Specifies requirements for cryptographic key destruction.
	FCS_CKM_EXT.1/DEK (selection-based)	Specifies requirements for asymmetric key generation.
	FCS_CKM_EXT.1/KEK (selection-based)	Specifies requirements for generation of KEKs.
	FCS_CKM_EXT.1/KEKT (selection-based)	Specifies requirements for asymmetric KEKs.
	FCS_CKM_EXT.1/SHARE (selection-based)	Specifies requirements for key shares.
	FCS_CKM_EXT.6 (selection-based)	Requires the TSF to support the secure archival, import and export of keys required for continuity of TOE operations.
	FCS_CKM_EXT.7 (selection-based)	Requires support for a hardware-protected REK.
	FCS_CKM_EXT.8 (selection-based)	Requires that the TSF provide a traceable hierarchy of keys.
	FCS_HTTPS_EXT.1 (selection-based)	Requires that the TSF implement HTTPS over TLS.
	FCS_IPSEC_EXT.1 (selection-based)	Specifies requirements for the TSF implementation of IPsec.
	FCS_RBG.1 (selection-based)	Requires that the TSF have access to DRBG services.
	FCS_RBG.2 (selection-based)	Allows the DRBG to be seeded by an external source.
	FCS_RBG.3 (selection-based)	Allows the DRBG to be seeded by a single internal source.
	FCS_RBG.4 (selection-based)	Allows the DRBG to be seeded by multiple internal sources.
	FCS_RBG.5 (selection-based)	Allows the DRBG to combine noise from multiple sources.
	FIA_AFL.1 (selection-based)	Requires that the TSF detect excessive unsuccessful login attempts from a remote user.
	FIA_PMG_EXT.1 (selection-based)	Specifies password composition rules.
	FIA_PSK_EXT.1 (selection-based)	Defines requirements for pre-shared keys used by the TSF.
	FIA_UAU.7 (selection-based)	Defines feedback permitted to the user during authentication.
	FDP_ITT.1 (selection-based)	Requires that the TSF protect user data during transmission between physically separate parts of the TOE.
	FPT_APW_EXT.1 (selection-based)	Defines protections for plaintext passwords.
	FPT_ITT.1 (selection-based)	Requires that the TSF protect data transmitted between different parts of the TOE.
	FPT_SKY_EXT.2 (selection-based)	Requires that key shares be accessible only by privileged users.
	FTP_ITC.1 (selection-based)	Requires secure communications between the TOE and external IT entities.
T.UNAUTHORIZED_UPDATE	FCS_CDP_EXT.1	Requires that the TSF implements or invokes cryptographic functionality.
	FCS_COP.1/Sig (selection-based)	Defines permissible cryptographic signature algorithms.
	FIA_X509_EXT.2	Specifies the contents of Certificate Request Messages generated by the TSF.
	FPT_TUD_EXT.1	Requires that the TSF support a secure TOE update process.
T.UNDETECTED_ACTIONS	FAU_ADP_EXT.1	Requires the TSF to implement or support audit functionality.
	FAU_GCR_EXT.1	Requires that the TSF store certificates that it issues.
	FAU_GEN.1	Requires that the TSF an audit record for defined auditable events.
	FAU_GEN.2	Requires that the TSF be able to associate audit events with user actions.
	FAU_STG.1	Requires that the TSF identify where audit events are stored.
	FAU_STG.5	Prevents audited events if the audit data storage cannot be written to.
	FIA_UIA_EXT.1	Defines the actions permitted prior to authentication of a user.
	FPT_STM.1	Requires that the TSF provide or support reliable time stamps.
	FAU_SAR.1 (selection-based)	Requires that auditors be able to read all audit records.
	FAU_SAR.3 (selection-based)	Requires support for searches of audit data based on certificate identifier.
	FAU_SCR_EXT.1 (selection-based)	Requires the TSF support review of certificates in a repository.
	FAU_SEL.1 (selection-based)	Requires support for selection of audit events based on specified attributes.
	FAU_STG.2/EXT (selection-based)	Requires the TSF protect audit records from unauthorized deletion.
	FAU_STG.2/STA (selection-based)	Requires that audit records with retention requirements be retained for the appropriate period.
	FAU_STG_EXT.1 (selection-based)	Requires that the TSF ensure the integrity of audit data.
T.USER_DATA_REUSE	FDP_RIP.1	Requires that the TSF ensure that residual information is not perpetuated.
T.WEAK_CRYPTO	FCS_CDP_EXT.1	Requires that the TSF implements or invokes cryptographic functionality.
	FCS_STG_EXT.1	Requires secure storage of private and secret keys.
	FIA_X509_EXT.2	Specifies the contents of Certificate Request Messages generated by the TSF.
	FPT_KST_EXT.1	Requires that the TSF prevent export of plaintext keys.
	FPT_KST_EXT.2	Requires that the TSF prevent unauthorized use of private and secret keys.
	FPT_SKP_EXT.1	Requires that the TSF be able to prevent reading of pre-shared, private and secret keys.
	FPT_TUD_EXT.1	Requires that the TSF support a secure TOE update process.
	FTP_TRP.1	Requires the TSF to provide a trusted path to remote entities.
	FCS_COP.1/PBKDF (optional)	(Optional) Requires the TSF to support password-based key derivation.
	FPT_SKY_EXT.1/CA (optional)	(Optional) Requires two-party control for the export of CA signing keys.
	FPT_SKY_EXT.1/OTH (optional)	(Optional) Requires two-party control for the export of other sensitive data or keys.
	FCS_COP.1/Hash (selection-based)	Defines permissible cryptographic hash algorithms and sizes.
	FCS_COP.1/KeyedHash (selection-based)	Defines permissible keyed-hash message authentication algorithms.
	FCS_COP.1/Sig (selection-based)	Defines permissible cryptographic signature algorithms.
	FCS_COP.1/SKC (selection-based)	Defines permissible AES encryption algorithms and key sizes.
	FCS_CKM.1 (selection-based)	Specifies allowable algorithms for generation of asymmetric keys.
	FCS_CKM.2 (selection-based)	Specifies allowable algorithms for key establishment.
	FCS_CKM_EXT.1/DEK (selection-based)	Specifies requirements for asymmetric key generation.
	FCS_CKM_EXT.1/KEK (selection-based)	Specifies requirements for generation of KEKs.
	FCS_CKM_EXT.1/KEKT (selection-based)	Specifies requirements for asymmetric KEKs.
	FCS_CKM_EXT.1/SHARE (selection-based)	Specifies requirements for key shares.
	FCS_CKM.6 (selection-based)	Specifies requirements for cryptographic key destruction.
	FCS_CKM_EXT.7 (selection-based)	Requires support for a hardware-protected REK.
	FCS_CKM_EXT.8 (selection-based)	Requires that the TSF provide a traceable hierarchy of keys.
	FCS_HTTPS_EXT.1 (selection-based)	Requires that the TSF implement HTTPS over TLS.
	FCS_IPSEC_EXT.1 (selection-based)	Specifies requirements for the TSF implementation of IPsec.
	FCS_RBG.1 (selection-based)	Requires that the TSF have access to DRBG services.
	FCS_RBG.2 (selection-based)	Allows the DRBG to be seeded by an external source.
	FCS_RBG.3 (selection-based)	Allows the DRBG to be seeded by a single internal source.
	FCS_RBG.4 (selection-based)	Allows the DRBG to be seeded by multiple internal sources.
	FCS_RBG.5 (selection-based)	Allows the DRBG to combine noise from multiple sources.
	FDP_ITT.1 (selection-based)	Requires that the TSF protect user data during transmission between physically separate parts of the TOE.
	FIA_PSK_EXT.1 (selection-based)	Defines requirements for pre-shared keys used by the TSF.
	FPT_ITT.1 (selection-based)	Requires that the TSF protect data transmitted between different parts of the TOE.
	FPT_SKY_EXT.2 (selection-based)	Requires that key shares be accessible only by privileged users.
	FTP_ITC.1 (selection-based)	Requires secure communications between the TOE and external IT entities.

5.2 Security Assurance Requirements

The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3. The Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of the Security Objectives. The PP draws from the CC Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing.

While this section contains the complete set of SARs from the CC, the Assurance Activities to be performed by an evaluator are detailed both in Section 5.1 as well as in this section.

The general model for evaluating TOEs against STs written to conform to this PP is as follows:

After the ST has been approved for evaluation, the Common Criteria Testing Laboratory (CCTL) will obtain the TOE, supporting IT environment, and the administrative guides for the TOE. The Assurance Activities listed in the ST (which will be refined by the CCTL to be TOE-specific, either within the ST or in a separate document) will then be performed by the CCTL. The results of these activities will be documented and presented (along with the administrative guidance used) for validation.

For each assurance family, “Developer Notes” are provided on the developer action elements to clarify what, if any, additional documentation/activity needs to be provided by the developer. For the content/presentation and evaluator activity elements, additional assurance activities are described as a whole for the family, rather than for each element. Additionally, the assurance activities described in this section are complementary to those specified in Section 5.1.

The TOE Security Assurance Requirements are identified in Table 4.

Table 4: TOE Security Assurance Requirements

Assurance Class	Assurance Components
Development (ADV)	Basic Functional Specification (ADV_FSP.1)
Guidance Documents (AGD)	Operational User Guidance (AGD_OPE.1)
Guidance Documents (AGD)	Preparative Procedures (AGD_PRE.1)
Life Cycle Support (ALC)	Labeling of the TOE (ALC_CMC.1)
Life Cycle Support (ALC)	TOE CM Coverage (ALC_CMS.1)
Security Target (ASE)	ST Introduction (ASE_INT.1)
	Conformance Claims (ASE_CCL.1)
	Security Objectives for the Operational Environment (ASE_OBJ.1)
	Extended Components Definition (ASE_ECD.1)
	Stated Security Requirements (ASE_REQ.1)
Tests (ATE)	Independent Testing – Conformance (ATE_IND.1)
Vulnerability Assessment (AVA)	Vulnerability Survey (AVA_VAN.1)

5.2.1 Class ADV: Development

The information about the TOE is contained in the guidance documentation available to the end user as well as the TSS portion of the ST. The TOE developer must concur with the description of the product that is contained in the TSS as it relates to the functional requirements. The Assurance Activities contained in Section 5.1 should provide the ST authors with sufficient information to determine the appropriate content for the TSS section.

ADV_FSP.1 Basic Functional Specification (ADV_FSP.1)

Developer action elements:

ADV_FSP.1.1D

The developer shall provide a functional specification.

ADV_FSP.1.2D

The developer shall provide a tracing from the functional specification to the SFRs.

Application Note: As indicated in the introduction to this section, the functional specification comprises the information contained in the AGD_OPE and AGD_PRE documentation, coupled with the information provided in the TSS of the ST. The assurance activities in the functional requirements point to evidence that should exist in the documentation and TSS section; since these are directly associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary.

Content and presentation elements:

ADV_FSP.1.1C

The functional specification shall describe the purpose and method of use for each SFR-enforcing and SFR-supporting TSFI.

ADV_FSP.1.2C

The functional specification shall identify all parameters associated with each SFR-enforcing and SFR-supporting TSFI.

ADV_FSP.1.3C

The functional specification shall provide rationale for the implicit categorization of interfaces as SFR-non-interfering.

ADV_FSP.1.4C

The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification.

Evaluator action elements:

ADV_FSP.1.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

ADV_FSP.1.2E

The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs.

5.2.2 Class AGD: Guidance Documentation

The guidance documents will be provided with the ST. Guidance must include a description of how the IT personnel verifies that the Operational Environment can fulfill its role for the security functionality. The documentation should be in an informal style and readable by the IT personnel. Guidance must be provided for every operational environment that the product supports as claimed in the ST. This guidance includes instructions to successfully install the TSF in that environment; and Instructions to manage the security of the TSF as a product and as a component of the larger operational environment. Guidance pertaining to particular security functionality is also provided; requirements on such guidance are contained in the assurance activities specified with each requirement.

AGD_OPE.1 Operational User Guidance (AGD_OPE.1)

Developer action elements:

AGD_OPE.1.1D

The developer shall provide operational user guidance.

Application Note: Rather than repeat information here, the developer should review the assurance activities for this component to ascertain the specifics of the guidance that the evaluator will be checking for. This will provide the necessary information for the preparation of acceptable guidance.

Content and presentation elements:

AGD_OPE.1.1C

The operational user guidance shall describe, for each privileged user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings.

AGD_OPE.1.2C

The operational user guidance shall describe, for each privileged user role, how to use the available interfaces provided by the TOE in a secure manner.

AGD_OPE.1.3C

The operational user guidance shall describe, for each privileged user role, the available functions and interfaces, in particular all security parameters under the control of the privileged user, indicating secure values as appropriate.

AGD_OPE.1.4C

The operational user guidance shall, for each privileged user role, clearly present each type of security-relevant event relative to the privileged user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.

AGD_OPE.1.5C

The operational user guidance shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences, and implications for maintaining secure operation.

AGD_OPE.1.6C

The operational user guidance shall, for each privileged user role, describe the security measures to be followed in order to fulfill the security objectives for the operational environment as described in the ST.

AGD_OPE.1.7C

The operational user guidance shall be clear and reasonable.

Evaluator action elements:

AGD_OPE.1.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

AGD_PRE.1 Preparative Procedures (AGD_PRE.1)

Developer action elements:

AGD_PRE.1.1D

The developer shall provide the TOE, including its preparative procedures.

Application Note: As with the operational guidance, the developer should look to the assurance activities to determine the required content with respect to preparative procedures.

Content and presentation elements:

AGD_PRE.1.1C

The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with the developer’s delivery procedures.

AGD_PRE.1.2C

The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST.

Evaluator action elements:

AGD_PRE.1.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

AGD_PRE.1.2E

The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation.

5.2.3 Class ALC: Life-cycle Support

At the assurance level provided for TOEs conformant to this PP, life-cycle support is limited to end-user-visible aspects of the life-cycle, rather than an examination of the TOE vendor’s development and configuration management process. This is not meant to diminish the critical role that a developer’s practices play in contributing to the overall trustworthiness of a product; rather, it is a reflection on the information to be made available for evaluation at this assurance level.

ALC_CMC.1 Labeling of the TOE (ALC_CMC.1)

Developer action elements:

ALC_CMC.1.1D

The developer shall provide the TOE and a reference for the TOE.

Content and presentation elements:

ALC_CMC.1.1C

The TOE shall be labeled with its unique reference.

Evaluator action elements:

ALC_CMC.1.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

ALC_CMS.1 TOE CM Coverage (ALC_CMS.1)

Developer action elements:

ALC_CMS.1.1D

The developer shall provide a configuration list for the TOE.

Content and presentation elements:

ALC_CMS.1.1C

The configuration list shall include the following: the TOE itself; and the evaluation evidence required by the SARs.

ALC_CMS.1.2C

The configuration list shall uniquely identify the configuration items.

Evaluator action elements:

ALC_CMS.1.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

5.2.4 Class ASE: Security Target Evaluation

As per ASE activities defined in [CEM]. In addition, there may be Evaluation Activities specified within Section 5.1 and relevant appendices that call for necessary descriptions to be included in the TSS that are specific to the TOE technology type.

5.2.5 Class ATE: Tests

Testing is specified for functional aspects of the system as well as aspects that take advantage of design or implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces with dependency on the availability of design information. One of the primary outputs of the evaluation process is the test report as specified in the following requirements.

ATE_IND.1 Independent Testing – Conformance (ATE_IND.1)

Developer action elements:

ATE_IND.1.1D

The developer shall provide the TOE for testing.

Content and presentation elements:

ATE_IND.1.1C

The TOE shall be suitable for testing.

Evaluator action elements:

ATE_IND.1.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

ATE_IND.1.2E

The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.

Application Note: If the ST author selects SSH, the TSF shall be validated against the Functional Package for Secure Shell (SSH), version 2.0.

Evaluation Activities

ATE_IND.1

The evaluator shall prepare a test plan and report documenting the testing aspects of the system. The test plan covers all of the testing actions contained in the CEM and the body of this PP’s Assurance Activities. While it is not necessary to have one test case per test listed in an Assurance Activity, the evaluator must document in the test plan that each applicable testing requirement in the ST is covered.

The test plan identifies the platforms to be tested, and for those platforms not included in the test plan but included in the ST, the test plan provides a justification for not testing the platforms. This justification must address the differences between the tested platforms and the untested platforms, and make an argument that the differences do not affect the testing to be performed. It is not sufficient to merely assert that the differences have no affect; rationale must be provided. If all platforms claimed in the ST are tested, then no rationale is necessary.

The test plan describes the composition of each platform to be tested, and any setup that is necessary beyond what is contained in the AGD documentation. It should be noted that the evaluator is expected to follow the AGD documentation for installation and setup of each platform either as part of a test or as a standard pre-test condition. This may include special test drivers or tools. For each driver or tool, an argument (not just an assertion) should be provided that the driver or tool will not adversely affect the performance of the functionality by the TOE and its platform. This also includes the configuration of the cryptographic engine to be used. The cryptographic algorithms implemented by this engine are those specified by this PP and used by the cryptographic protocols being evaluated (IPsec, TLS/HTTPS, SSH).

The test plan identifies high-level test objectives as well as the test procedures to be followed to achieve those objectives. These procedures include expected results. The test report (which could just be an annotated version of the test plan) details the activities that took place when the test procedures were executed, and includes the actual results of the tests. This shall be a cumulative account, so if there was a test run that resulted in a failure; a fix installed; and then a successful re-run of the test, the report would show a “fail” and “pass” result (and the supporting details), and not just the “pass” result.

5.2.6 Class AVA: Vulnerability Assessment

For the current generation of this Protection Profile, the evaluation lab is expected to survey open sources to discover what vulnerabilities have been discovered in these types of products. In most cases, these vulnerabilities will require sophistication beyond that of a basic attacker. Until penetration tools are created and uniformly distributed to the evaluation labs, the evaluator will not be expected to test for these vulnerabilities in the TOE. The labs will be expected to comment on the likelihood of these vulnerabilities given the documentation provided by the vendor. This information will be used in the development of penetration testing tools and for the development of future Protection Profiles.

AVA_VAN.1 Vulnerability Survey (AVA_VAN.1)

Developer action elements:

AVA_VAN.1.1D

The developer shall provide the TOE for testing.

Content and presentation elements:

AVA_VAN.1.1C

The TOE shall be suitable for testing.

Evaluator action elements:

AVA_VAN.1.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

AVA_VAN.1.2E

The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE.

AVA_VAN.1.3E

The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack potential.

Appendix A - Optional Requirements

As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the TOE) are contained in the body of this PP. This appendix contains three other types of optional requirements:

The first type, defined in Appendix A.1 Strictly Optional Requirements, are strictly optional requirements. If the TOE meets any of these requirements the vendor is encouraged to claim the associated SFRs in the ST, but doing so is not required in order to conform to this PP.

The second type, defined in Appendix A.2 Objective Requirements, are objective requirements. These describe security functionality that is not yet widely available in commercial technology. Objective requirements are not currently mandated by this PP, but will be mandated in the future. Adoption by vendors is encouraged, but claiming these SFRs is not required in order to conform to this PP.

The third type, defined in Appendix A.3 Implementation-dependent Requirements, are Implementation-dependent requirements. If the TOE implements the product features associated with the listed SFRs, either the SFRs must be claimed or the product features must be disabled in the evaluated configuration.

A.1 Strictly Optional Requirements

A.1.1 Auditable Events for Strictly Optional Requirements

Table 5: Auditable Events for Strictly Optional Requirements
Requirement	Auditable Events	Additional Audit Record Contents
FCS_COP.1/PBKDF
FCS_COP.1/PBKDF
No events specified	N/A
FDP_CER_EXT.4
FDP_CER_EXT.4
Certificate generation (Retention: Extended)	Name/identifier of the certificate. Value of the certificate generated
FDP_SDP_EXT.1
FDP_SDP_EXT.1
No events specified	N/A
FDP_STG_EXT.1
FDP_STG_EXT.1
Changes to the trusted public keys and certificates relevant to TOE functions, including additions and deletions. (Retention: Normal)	The public key and all context information associated with the key.
FPT_NPE_EXT.1
FPT_NPE_EXT.1
All changes to NPE rule sets and NPE. (Retention: Extended)	The changes made to the NPE rule sets and associations
FPT_SKY_EXT.1/CA
FPT_SKY_EXT.1/CA
No events specified	N/A
FPT_SKY_EXT.1/OTH
FPT_SKY_EXT.1/OTH
No events specified	N/A
FPT_TST_EXT.1

	Execution of this set of TSF integrity tests (Retention: Normal)	No additional information
Detected integrity violations (Retention: Normal)	The identity of the object that caused the integrity violation
FPT_TST_EXT.2

	Execution of this set of TSF integrity tests (Retention: Normal)	No additional information
Detected integrity violations	The identity of the object that caused the integrity violation
FTA_SSL.3
FTA_SSL.3
The termination of a remote session by the session termination mechanism (Retention: Normal)	No additional information
FTA_SSL_EXT.1
FTA_SSL_EXT.1
Any attempts at unlocking or termination of an interactive session. (Retention: Normal)	No additional information

A.1.2 Class: Cryptographic Support (FCS)

FCS_COP.1/PBKDF Cryptographic Operation (Password-based Key Derivation Function)

FCS_COP.1.1/PBKDF

The TSF shall [Password-based Key Derivation Functions] in accordance with a specified cryptographic algorithm [HMAC-SHA-384] and cryptographic key sizes [256-bit] that meet the following: [NIST SP 800-32].

Application Note: This requirement is optional. It will be claimed if the method of protecting key shares in FPT_SKY_EXT.2 or any other mechanism to enforce access by privileged user depends on passwords. It may also be claimed if other mechanisms use password-based encryption.

In the first selection for each element, the ST author chooses whether the TOE performs the derivation, or whether it invokes interfaces in the Operational Environment for the functionality.

The cryptographic key sizes in the third selection should be made to correspond to the KEK key sizes selected in FCS_CKM_EXT.1/KEKT. A future requirement will add a refinement to require a PBKDF iteration count of at least 1000.

This password must be conditioned into a string of bits that forms the submask to be used as input into the KEK. Conditioning is be performed using one of the identified hash functions. NIST SP 800-132 requires the use of a pseudo-random function (PRF) consisting of HMAC with an approved hash function. The ST author selects the hash function used, also includes the appropriate requirements for HMAC and the hash function.

A.1.3 Class: User Data Protection (FDP)

FDP_CER_EXT.4 Certificate Status Information

FDP_CER_EXT.4.1

For X.509 certificate formats other than v3, the TSF shall ensure that these certificate formats contain the following general characteristics:

Version (0 or 1);
Unique identifier of the issuer;
keyUsage;
Unique identifier of the certificate
Validity period
Signature field in accordance with FCS_COP.1/Sig

Application Note: This optional requirement can be included if X.509 certificate formats other than the mandated v3 are supported.

FDP_SDP_EXT.1 User Sensitive Data Protection

FDP_SDP_EXT.1.1

The TSF shall [selection: protect, invoke interfaces to the Operational Environment to protect] [selection:

subscriber identity information
subscriber contact information
photograph from official ID such as an organization ID badge, passport or driver’s license,
background check information
copies of legal documents
captured biometrics
[assignment: other personally identifiable information]

] through encryption in accordance with FCS_COP.1/SKC using a DEK.

FDP_SDP_EXT.1.2

The TSF shall [selection: destroy, invoke interfaces to the Operational Environment to destroy] all protected data when no longer required in accordance with the specified cryptographic data destruction method: [selection:

by clearing the DEK encrypting the protected data,
in accordance with the following rules:

For volatile EEPROM the destruction shall be executed by a single direct overwrite consisting of [selection:
- a pseudo random pattern using the TSF’s RBG (as specified in FCS_RBG_EXT.1),
- zeroes
] followed by a read-verify.
h:br/> For volatile flash memory the destruction shall be executed by [selection:
- a single direct overwrite consisting of zeroes,
- a block erase
] followed by a read-verify.

]

Application Note: In the first selection for each element, the ST author chooses whether the TOE performs the protection/destruction, or whether it invokes interfaces in the Operational Environment for the functionality.

The DEK referenced in FDP_SDP_EXT.1.1 is generated by FCS_CKM_EXT.1/DEK.

In the second selection in FDP_SDP_EXT.1.1, the ST author should indicate all protected data (e.g., subscriber PII) that is protected by the TOE or Operational Environment and specify how that protection is accomplished. Information included only in issued certificates is not included in this requirement. This is not a general requirement to protect all PII anywhere on the system, but instead deals only with information used by the TOE in performing CA functions.

For FDP_SDP_EXT.1.2, destroying data refers to rendering it inaccessible to any authorized or unauthorized user or process.

Evaluation Activities

FDP_SDP_EXT.1

TSS

The evaluator shall examine the TSS to verify that it describes (for each supported platform) how the data destruction functionality is performed or invoked.

The evaluator shall examine the TSS to ensure it describes each user data type as indicated in FDP_SDP_EXT.1.1, including where it is stored, how it is protected (including mode and key size used when encrypting the data), when it is destroyed (for example, immediately after use, on system shutdown, etc.); and the type of destruction procedure that is performed.

The evaluator shall ensure that the mode and key size used in the encryption of the data is specified in the FCS_COP.1 SFR.

If the Operational Environment is invoked to perform the functions, the TSS shall list the interfaces (APIs) that are invoked.

Guidance

If the protection and destruction of user data is configurable, the evaluator shall examine the operational guidance to ensure it instructs the administrator how to ensure that user data is protected and destroyed in accordance with this requirement.

Tests

The evaluator shall perform the following tests for each platform listed in the ST:

Test FDP_SDP_EXT.1:1: The evaluator shall, for each user data type listed in the TSS, locate where the data is stored and verify that it is encrypted.
Test FDP_SDP_EXT.1:2: The evaluator shall, for each user data type listed in the TSS, initiate the supported data destruction mechanism according to the documented times that it should be initiated for that user data type (e.g., immediately after use, on system shutdown, etc.) and verify that the protected data has been destroyed.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FDP_STG_EXT.1 User Sensitive Data Protection

FDP_STG_EXT.1.1

The TSF shall use [selection: access controlled storage, an integrity mechanism] to protect the trusted public keys and certificates (trust store elements) used to validate local logon, trusted channel, and external communication to the CA.

Application Note: Public keys used to satisfy CA-related requirements in the ST must be protected. If the TOE protects the keys or a subset of the keys, this SFR is included in the ST. It is acceptable if some or all of the public keys are stored in the OE and protected by OE-provided mechanisms. If this is the case, then the ST author includes OE.PUBLIC_KEY_PROTECTION in the ST. It is acceptable for the TOE to protect some keys and the OE to protect other keys.

There are two allowed methods of providing protection if this requirement is claimed in the ST. The first is that the TOE implements access control mechanisms to perform the protection; this is only claimed when the TOE is providing the storage for the public keys. The second is to provide a cryptographic-based integrity check on the public keys when they are accessed for use by the TOE; this is claimed for public keys stored either by the TOE or in the OE and an integrity mechanism is implemented. If this method is used (the second selection is chosen), then the ST author include FCS_CKM_EXT.5 in the ST as well as this SFR.

A.1.4 Class: Protection of the TSF (FPT)

FPT_NPE_EXT.1 NPE Constraints

FPT_NPE_EXT.1.1

The TSF shall enforce an Administrator-configurable ruleset that specifies authorizations to submit NPE certificate requests.

Application Note: The rulesets specify when approval by a CA, RA, and/or AOR is required and limits the authorizations of RAs or specific Authorized Organizational Representatives (AORs), to approve NPE certificates associated to a particular organization.

FPT_NPE_EXT.1.2

The TSF shall require the CA Operations Staff to register any RA, and shall require a CA Operations Staff or authorized RA to register any AORs, and associate each AOR with an organization or set of devices prior to that AOR making requests on behalf of an assigned organization or devices.

Application Note: Registration authorities may be restricted in the types of certificates they are authorized to request, or the subjects asserted in those requests, but typically have wide authority to request certificates. AORs, on the other hand, are restricted to NPE certificate types, and are further restricted to request certificates for a small number of devices owned by their affiliated organization. Similar to subscriber self-service requests, an AOR’s request authority is provided only for those certificates associated to devices the particular AOR is authorized to manage.

Evaluation Activities

FPT_NPE_EXT.1

TSS

The evaluator shall examine the TSS to ensure it describes the AOR constraint mechanism, including the ruleset and its enforcement.

Guidance

The evaluator shall examine the operational guidance to verify that it describes how to configure the ruleset. The evaluator shall ensure that the operational guidance includes instructions on how the RAs and CA Operations staff register the AORs and associate the AORs with particular organizations. The evaluator shall also examine the operational guidance to ensure it also describes how AORs, RAs or CA Operations Staff perform certificate management on behalf of the organization for which they are registered.

Tests

The evaluator shall perform the following tests:

Test FPT_NPE_EXT.1:1: The evaluator shall assume the Administrator role and configure the ruleset. The evaluator shall then assume other roles and verify that no other roles can modify the ruleset.
Test FPT_NPE_EXT.1:2: The evaluator shall configure the ruleset that restricts an AOR to a particular organization. The evaluator shall assume a CA Operations Staff or RA role and register an AOR with an organization, authorizing the AOR to perform specific operations on that organization’s behalf. The evaluator shall then verify that the AOR can perform each authorized operation on behalf of the organization.
Test FPT_NPE_EXT.1:3: The evaluator shall configure the ruleset that restricts an AOR to a particular organization. The evaluator shall assume a CA Operations Staff or RA role and register an AOR with an organization, authorizing the AOR to perform specific operations on that organization’s behalf. The evaluator shall verify that the AOR cannot perform any operations on behalf of organizations for which it is not registered. The evaluator shall also verify that the AOR cannot perform unauthorized operations on behalf of its assigned organization.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FPT_SKY_EXT.1/CA Split Knowledge Procedures (CA Functionality)

FPT_SKY_EXT.1.1/CA

The TSF shall [selection: support, interface with the operational environment to support] split knowledge procedures to enforce two-party control for the export of CA signing keys and [selection: no other data, [assignment: critical data or keys]] necessary to resume CA functionality after TSF failure using [selection: key sharing mechanisms in accordance with FCS_CKM_EXT.1/KEKT, FCS_CKM_EXT.1/SHARE, FCS_CKM_EXT.6, and FPT_SKY_EXT.2, [assignment: other mechanism]].

Application Note: The intent of this requirement is to limit access to critical keys that are necessary to maintain operations after a failure. Key sharing mechanisms are also referred to as secret sharing mechanisms, or threshold schemes and are commonly used by hardware security modules to clone keys between devices.

If enforcement of split knowledge procedures to provide controlled access to critical keys and data required to restore CA functionality is performed entirely by the OE, then this SFR is not included in the ST and OE.KEY_ARCHIVAL is included in the ST.

Evaluation Activities

FPT_SKY_EXT.1/CA

If the TSF implements a key sharing mechanism, this SFR is satisfied through the referenced SFRs in Appendices B.3 and B.8 of the PP.

Note: FCS_CKM_EXT.1/KEKT specifies how the key shares generated in accordance with FCS_CKM_EXT.1/SHARE are used to produce a KEK to protect the keys listed in this requirement. The protection of those keys with the KEK is done by mechanism required in FCS_CKM_EXT.6. FPT_SKY_EXT.2 specifies access control for the key shares themselves.

TSS

If the TSF interfaces with a cryptographic module in the Operational Environment to implement a key sharing mechanism, the evaluator shall examine the TSS to ensure that the interface to the OE, and cryptographic provider for the key sharing mechanism is described.

If the TSF implements another split knowledge procedure, the evaluator shall examine the TSS to ensure the procedure is adequately described, and assess the procedure to ensure that it is effective in restricting access to the CA signing key and all other selected data and keys.

If the TSF interfaces with the OE to implement other split knowledge procedures, the evaluator shall examine the TSS to ensure the procedure is adequately described, and assess the procedure to ensure that it is effective in restricting access to the CA signing key and all other selected data and keys.

The evaluator shall ensure that the TSS describes the dependence on the OE and identifies any cryptographic providers within the OE used to support the procedures.

Guidance

The evaluator shall examine the AGD guidance to ensure it contains instructions for configuring the OE to restrict access to the CA signing key and all other selected data and keys.

If the TSF implements another split knowledge procedure, the evaluator shall review the AGD to ensure it contains clear instructions to privileged users on how to conduct the procedures.

Tests

There are no test activities for this component.

FPT_SKY_EXT.1/OTH Split Knowledge Procedures (Other Functionality)

FPT_SKY_EXT.1.1/OTH

The TSF shall [selection: support, interface with the operational environment to support] split knowledge procedures to enforce two-party control for the export of [selection: no other data, user private keys, [assignment: critical data or keys]] using [selection: key sharing mechanisms in accordance with FCS_CKM_EXT.1/KEKT, FCS_CKM_EXT.1/SHARE, FCS_CKM_EXT.6, and FPT_SKY_EXT.2, [assignment: other mechanism]].

Application Note: The intent of this requirement is to limit access to other critical keys or data that are archived when the TSF provides, or interfaces with the OE to provide, a split knowledge mechanism different than what is provided to archive and recover the CA signing key and other critical keys and data required to restore CA functionality. This requirement may include protection mechanisms for critical keys and data that are archived to restore optional CA functionality, which are not required to restore basic CA functionality. However, if the TSF provides, or interfaces with the OE to provide, the same mechanism to protect access to all archived keys and data used for both basic and any optional CA functionality, the common mechanism can be described in FPT_SKY_EXT.1/CA and it is not necessary to also include this requirement in the ST.

If enforcement of split knowledge procedures to provide controlled access to critical keys and data not included in FPT_SKY_EXT.1/CA is performed entirely by the OE, then this SFR is not included in the ST and OE.KEY_ARCHIVAL is included in the ST.

Evaluation Activities

FPT_SKY_EXT.1/OTH

If the TSF implements a key sharing mechanism, this SFR is satisfied through the referenced SFRs in Appendices B.3 and B.8 of the PP.

Note: FCS_CKM_EXT.1/KEKT specifies how the key shares generated in accordance with FCS_CKM_EXT.1/SHARE are used to produce a KEK to protect the keys listed in this requirement. The protection of those keys with the KEK is done by mechanism required in FCS_CKM_EXT.6. FPT_SKY_EXT.2 specifies access control for the key shares themselves.

TSS

The evaluator shall ensure that the TSS describes the dependence on the OE and identifies any cryptographic providers within the OE used to support the procedures.

If the TSF implements another split knowledge procedure, the evaluator shall examine the TSS to ensure the procedure is adequately described, and assess the procedure to ensure that it is effective in restricting access to the selected data and keys.

If the TSF interfaces with the OE to implement other split knowledge procedures, the evaluator shall examine the TSS to ensure the procedure is adequately described, and assess the procedure to ensure that it is effective in restricting access to the selected data and keys.

Guidance

The evaluator shall examine the AGD guidance to ensure it contains instructions for configuring the OE to restrict access to the selected data and keys.

If the TSF implements another split knowledge procedure, the evaluator shall review the AGD to ensure it contains clear instructions to privileged users on how to conduct the procedures.

Tests

There are no test activities for this component.

FPT_TST_EXT.1 TOE Integrity Test

FPT_TST_EXT.1.1

The TSF shall apply a [selection: keyed hash according to FCS_COP.1/KeyedHash, digital signature algorithm according to FCS_COP.1/Sig] to the TOE software and firmware. This requirement is similar to the requirements laid out in FPT_TST.1.3, which has been added as a required dependency for FCS_RBG.1. Should this requirement be folded into that one?

FPT_TST_EXT.1.2

The [selection: TSF, Operational Environment] shall verify the integrity of the TOE software and firmware [selection: at power-up, at initialization, on-demand by a privileged user].

Application Note: The ST author includes this SFR when the TSF includes a mechanism that can perform integrity tests on software/firmware, for instance, if the TSF includes an operating system.

The ST author selects “integrity test failure” in FPT_FLS.1 if this component is included in the ST.

When FCS_CDP_EXT.1 indicates that FCS_COP.1/KeyedHash, or FCS_COP.1/Sig are implemented by the OE, FPT_TST_EXT.1.1 is in accordance with those SFR if the TSF interfaces with the OE to invoke the algorithms indicated.

FPT_TST_EXT.2 Integrity Test

FPT_TST_EXT.2.1

The TSF shall apply a [selection: keyed hash according to FCS_COP.1/KeyedHash, digital signature algorithm according to FCS_COP.1/Sig] to the [selection: Trust Anchor Database element(s), TSF keys used to manage certificates, certificate database, [assignment: other data relevant to TSF security]]. This requirement is similar to the requirements laid out in FPT_TST.1.2, which has been added as a required dependency for FCS_RBG.1. Should this requirement be folded into that one?

FPT_TST_EXT.2.2

Integrity shall be verified at [selection: power-up, initialization, on-demand by a privileged user].

Application Note: The ST author includes this SFR when the TSF itself provides integrity protection for any of the items listed in the second selection of FPT_TST_EXT.2.1.

The ST author selects “integrity test failure” in FPT_FLS.1 if this component is included in the ST.

A.1.5 Class: TOE Access (FTA)

FTA_SSL.3 TSF-Initiated Termination

FTA_SSL.3.1

The TSF shall terminate session after a [assignment: administrator-configurable time interval of user activity].

Application Note: This requirement is included if the TSF is implementing the mechanism used to terminate remote sessions after a defined time period. If this requirement is not included in the ST, then OE.SESSION_PROTECTION_REMOTE will be included in the ST.

FTA_SSL_EXT.1 TSF-Initiated Session Locking

FTA_SSL_EXT.1.1

The TSF shall, for local interactive sessions, [selection:

lock the session–- disable any activity of the user’s data access/display devices other than unlocking the session, and requiring that the privileged user reauthenticate to the TSF prior to unlocking the session;
terminate the session

] after an Administrator-configured time period of inactivity.

Application Note: This requirement is included if the TSF is implementing the mechanism used to terminate or lock local sessions after a defined time period. If this requirement is not included in the ST, then OE.SESSION_PROTECTION_LOCAL will be included in the ST.

A.2 Objective Requirements

A.2.1 Auditable Events for Objective Requirements

Table 6: Auditable Events for Objective Requirements
Requirement	Auditable Events	Additional Audit Record Contents
FCS_KSH_EXT.1
FCS_KSH_EXT.1
No events specified	N/A
FIA_ENR_EXT.1
FIA_ENR_EXT.1
No events specified	N/A
FIA_ESTC_EXT.2
FIA_ESTC_EXT.2
No events specified	N/A
FIA_ESTS_EXT.2
FIA_ESTS_EXT.2
No events specified	N/A

A.2.2 Class: Cryptographic Support (FCS)

FCS_KSH_EXT.1 Key Sharing

FCS_KSH_EXT.1.1

This objective SFR should be reviewed to determine if it should change status with the next release of this PP. Per the App Note, this SFR is intended to replace FPT_SKY_EXT.1. The TSF shall [selection: support, interface with the operational environment to support] split knowledge procedures to enforce two-party control for the export of CA signing keys [selection: no other data, [assignment: critical data or keys]] necessary to resume CA functionality after TSF failure using key sharing mechanisms in accordance with FCS_CKM_EXT.1.1/KEKT, FCS_CKM_EXT.1.2/KEKT, FCS_CKM_EXT.7.1 and FPT_SKY_EXT.1.1/CA.

Application Note: This SFR, which mandates the use of key sharing to control the export of CA signing keys, is intended to replace FPT_SKY_EXT.1/CA in future versions of this PP.

A.2.3 Class: Identification and Authentication (FIA)

FIA_ENR_EXT.1 Certificate Enrollment

FIA_ENR_EXT.1.1

This SFR appears to be covered by the X.509 FP requirement FIA_X509_EXT.3. It may be appropriate to remove this objective SFR. The TSF shall be able to generate a certificate request to an external certification authority to receive a CA certificate for a CA's signing key using [selection:

PKCS#10 in accordance with FIA_X509_EXT.3
Enrollment over Secure Transport (EST) in accordance with FIA_ESTC_EXT.1
Certificate Management over CMM in accordance with FIA_CMCC_EXT.1

]

Application Note: The external certification authority may be a root or intermediate certification authority that is used to issue and manage the TOE’s embedded CA’s certificate. It is not to be used to directly issue end entity certificates to requested servers instead of the TOE’s embedded CA.

FIA_ESTC_EXT.2 EST Client use of TLS-unique value

FIA_ESTC_EXT.2.1

The parent requirement for this SFR (FIA_ESTC_EXT.1) will be moved to the X.509 FP, whose version of FIA_ESTC_EXT.1 does not include a requirement to include a tls-unique value. A determination will need to be made on if this requirement should be included in a future version of the X.509 FP, or how this requirement should be handled in another case. The TSF shall generate tls-unique values and integrate them into EST requests it generates in accordance with RFC 7030 section 3.5.

Application Note: This SFR describes an optional element of RFC 7030 that strengthens the authentication provided by EST. While RFC 7030 requires EST servers to validate the tls-unique values when presented, this requirement is not implemented in current EST servers. FIA_ESTC_EXT.2.1 will be integrated into FIA_ESTC_EXT.1 in a subsequent release of this EP and should be claimed if the EST implementation supports it.

FIA_ESTS_EXT.2 Enrollment over Secure Transport (EST) Server

FIA_ESTS_EXT.2.1

The parent requirement for this SFR (FIA_ESTS_EXT.1) will be moved to the X.509 FP, whose version of FIA_ESTs_EXT.1 does not include a requirement to include a tls-unique value. A determination will need to be made on if this requirement should be included in a future version of the X.509 FP, or how this requirement should be handled in another case. The TSF shall verify tls-unique values offered by EST clients in accordance with RFC 7030 section 3.5.

Application Note: The ability for EST servers to verify tls-unique values is required by RFC 7030, but is not common in current EST libraries.

A.3 Implementation-dependent Requirements

A.3.1 Auditable Events for Implementation-dependent Requirements

Table 7: Auditable Events for Implementation-dependent Requirements
Requirement	Auditable Events	Additional Audit Record Contents
FAU_SAR.1
FAU_SAR.1
No events specified	N/A
FAU_SAR.3
FAU_SAR.3
No events specified	N/A
FAU_SEL.1
FAU_SEL.1
All modifications to the audit configuration that occur while the audit collection functions are operating. (Retention: Normal)	No additional information
FAU_STG.2/EXT
FAU_STG.2/EXT
No events specified	N/A
FAU_STG.2/STA
FAU_STG.2/STA
No events specified	N/A
FCS_CKM_EXT.1/DEK
FCS_CKM_EXT.1/DEK
No events specified	N/A

A.3.2 Class: Security Audit (FAU)

FAU_SAR.1 Audit Review

This component must be included in the ST if the TOE implements any of the following features:

TOE supports Audit Review

FAU_SAR.1.1

The TSF shall provide [Auditors] with the capability to read [all information] from the audit data.

FAU_SAR.1.2

The TSF shall provide the audit data in a manner suitable for the Auditor to interpret the information.

FAU_SAR.3 Selectable Audit Review

This component must be included in the ST if the TOE implements any of the following features:

TOE supports Audit Review

FAU_SAR.3.1

The TSF shall provide the ability to apply [searches] of audit data based on [assignment: object identifier of certificate associated with the event].

Application Note: This SFR is included in the ST by the ST author if the operations provided by the TSF (as specified in FAU_ADP_EXT.1) include the review of audit records. If this SFR is not selected, the ST author includes OE.AUDIT_REVIEW. FAU_SCR_EXT.1 defines the ability of the TOE to search a certificate repository to find certificates based on certain values of individual fields, and return an object identifier of the certificate. The intent of this SFR--along with FAU_SCR_EXT.1--is that the auditor has the ability to obtain a certificate’s unique identifier by searching for other known fields and then using that unique identifier as an input to searching audit data for all activities involving that certificate. Therefore, the assignment for this SFR and the corresponding assignment in FAU_SCR_EXT.1 are to be made identical by the ST author.

FAU_SEL.1 Selective Audit

This component must be included in the ST if the TOE implements any of the following features:

TSF Supports Audit Pre-Select

FAU_SEL.1.1

The TSF shall be able to select the set of events to be audited from the set of all auditable events based on the following attributes:

[selection: object identity, user identity, subject identity, host identity, event type]
[assignment: list of additional attributes that audit selectivity is based upon].

Application Note: This SFR is included in the ST by the ST author if the operations provided by the TSF (as specified in FAU_ADP_EXT.1) include the pre-selection of audit records.

FAU_STG.2/EXT Protected Audit Data Storage (Extended Audit Data)

This component must be included in the ST if the TOE implements any of the following features:

TSF Supports Storage of Audit Records

FAU_STG.2.1/EXT

The TSF shall protect the stored audit data in the audit trail from unauthorized deletion .

FAU_STG.2.2/EXT

The TSF shall be able to [prevent] unauthorized modifications to the stored audit data in the audit trail.

Application Note: This requirement applies to audit data stored within the TOE boundary that is expected to persist intact beyond the validity of certificates issued by the CA, even in the event of unexpected TSF failure. Refer to Table 4 through Table 6 for the auditable events marked as requiring extended retention that are relevant to this SFR.

Audit events that are not covered by this SFR (that is, those requiring extended retention and stored in the OE) will be protected via integrity and redundancy mechanisms typically provided in archive servers. To reflect this, if any audit events marked “extended” in tables 4, 5, and 6 are stored in the OE, then OE.AUDIT_RETENTION is included in the ST.

If any audit storage provided by the TOE is used for audit events marked “extended” in tables 4, 5, and 6 that are included in the ST, then this SFR will be included in the ST by the ST author.

Evaluation Activities

FAU_STG.2/EXT

TSS

The evaluator shall examine the TSS to ensure that it lists each type of audit log generated by the TOE. For each audit log, the TSS shall describe how it is stored, where it is located, and how it is protected. The evaluator shall verify that the TSS’ description of the protection includes prevention of deletion prior to the retention period. The TSS description shall also include prevention of modification of events after they are written to the audit trail. If the TSF requires the actions of an Auditor to meet these requirements, the TSS shall describe the restrictions on Auditor activity. If roles other than the Auditor are provided with an interface for accessing the stored audit records, the TSS shall provide a justification for why the role cannot delete or modify the audit records.

Guidance

There are no AGD assurance activities for this requirement beyond what is necessary to satisfy the requirements in [CEM].

Tests

The testing may be accomplished with the testing performed by FAU_STG.2/STA.

The evaluator shall perform the following tests for each role other than the Auditor role:

Test FAU_STG.2/EXT:1: For each audit event marked identified with extended retention requirements in the ST, the evaluator shall assume a role and attempt to delete the stored audit records, then verify that the attempted deletion failed.
Test FAU_STG.2/EXT:2: For each audit event marked identified with extended retention requirements in the ST, the evaluator shall assume a role and attempt to modify the stored audit records and verify that the attempted modification was prevented.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE's ST. Justification must be provided for those platforms that were excluded from testing.

FAU_STG.2/STA Protected Audit Data Storage (Standard Audit Data)

This component must be included in the ST if the TOE implements any of the following features:

TSF Supports Storage of Audit Records

FAU_STG.2.1/STA

The TSF shall protect the stored audit data in the audit trail from unauthorized deletion.

FAU_STG.2.2/STA

The TSF shall be able to [prevent] unauthorized modifications to the stored audit data in the audit trail.

Application Note: This requirement applies when the audit data are stored by the TOE itself. If the TSF does not store all (or any) of the audit data, OE.AUDIT_STORAGE is included in the ST.

A.3.3 Class: Cryptographic Support (FCS)

FCS_CKM_EXT.1/DEK Symmetric Key Generation (DEKs)

This component must be included in the ST if the TOE implements any of the following features:

TOE Responsible for Protecting Subscriber Information

FCS_CKM_EXT.1.1/DEK

The TSF shall [selection: generate, invoke interfaces provided by the Operational Environment to generate] data encryption keys (DEKs) of size [selection: 128-bit, 256-bit] using [selection:

an RBG that meets this profile (as specified in FCS_RBG_EXT.1)
a key generation capability of the Operational Environment
a TSF-provided mechanism that combines KEKs in a way that preserves the effective entropy of each factor by [selection:
- using an XOR operation
- concatenating the keys and using a key derivation function (KDF) in accordance with SP 800-108
- encrypting one key with another in accordance with FCS_COP.1/SKC and using modes [selection: AES-CCM, AES-GCM, AES Key Wrap, AES Key Wrap with Padding]
]

Application Note: Data encryption keys (DEKs) are used to protect data at rest (e.g., subscriber PII of security critical parameters) that needs to be encrypted. These are distinguished from KEKs (whose generation is described in FCS_CKM_EXT.1/KEK) that are used to protect other keys – DEKs, other KEKs, and other types of keys stored by the user or applications.

The first selection must match the selection for this component in FCS_CDP_EXT.1 in terms of whether this functionality is implemented by the TOE or through the OE.

The second selection is simply the number of bits in the DEK.

For the third selection, if the TSF invokes an RBG that is implemented by the TOE or implemented by the OE, the first item is selected and FCS_RBG_EXT.1 is included in the ST. If the TSF invokes a key-generation mechanism in the OE (that is not a direct invocation of an RBG), then the second item (“a key generation capability of the Operational Environment”) is selected; in this case the second item of the first selection ("invoke interfaces provided by the Operational Environment to generate") should have also been chosen. If the TSF uses a method to combine KEKs to produce the DEK, the third item is selected and the method used to produce the DEK from the KEKs is chosen in the fourth selection. Additionally, if this third item is selected (TSF combining KEKs to produce the DEK), then FCS_CKM_EXT.1/KEK (to specify how the KEKs used are generated) and FCS_CKM_EXT.7 (to specify how the REK that anchors the KEKs is generated and protected) in Annex B.8 must be included. Finally, if the third item in the fourth selection statement is chosen (key wrap), then FCS_COP.1/SKC will be included in the ST and the appropriate key wrap method will be chosen in the fifth selection.

Appendix B - Selection-based Requirements

As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the TOE or its underlying platform) are contained in the body of this PP. There are additional requirements based on selections in the body of the PP: if certain selections are made, then additional requirements below must be included.

B.1 Auditable Events for Selection-based Requirements

Table 8: Auditable Events for Selection-based Requirements
Requirement	Auditable Events	Additional Audit Record Contents
FAU_SCR_EXT.1
FAU_SCR_EXT.1
No events specified	N/A
FAU_STG_EXT.1
FAU_STG_EXT.1
No events specified	N/A
FCO_NRR_EXT.2
FCO_NRR_EXT.2
No events specified	N/A
FCS_CKM.1

	Generation of non-ephemeral key for TOE-related funtions. (Retention: Normal)	Public key generated if successful
[selection: Generation of ephemeral key for TOE-related functions. (Retention: Normal), None]	Public key generated if successful.
FCS_CKM.2

	Establishment of non-ephemeral key for TOE-related funtions. (Retention: Normal)	Key established if successful
[selection: Establishment of ephemeral key for TOE-related functions. (Retention: Normal), None]	Key established if successful.
FCS_CKM.6
FCS_CKM.6
Failure of the key destruction process for TOE keys (Retention: Normal)	Identity of object or entity being cleared.
FCS_CKM_EXT.1/KEK
FCS_CKM_EXT.1/KEK
No events specified	N/A
FCS_CKM_EXT.1/KEKT
FCS_CKM_EXT.1/KEKT
No events specified	N/A
FCS_CKM_EXT.1/SHARE
FCS_CKM_EXT.1/SHARE
No events specified	N/A
FCS_CKM_EXT.5
FCS_CKM_EXT.5
Failure of the key destruction process for TOE related keys. (Retention: Normal)	No additional information
FCS_CKM_EXT.6
FCS_CKM_EXT.6
All key archival actions. (Retention: Extended)	No additional information
FCS_CKM_EXT.7
FCS_CKM_EXT.7
No events specified	N/A
FCS_CKM_EXT.8
FCS_CKM_EXT.8
No events specified	N/A
FCS_COP.1/Hash
FCS_COP.1/Hash
No events specified	N/A
FCS_COP.1/KeyedHash
FCS_COP.1/KeyedHash
No events specified	N/A
FCS_COP.1/SKC
FCS_COP.1/SKC
No events specified	N/A
FCS_COP.1/SigGen

	All occurrences of signature generation using a CA signing key. (Retention: Extended)	Name/identifier of object being signed. Identifier of key used for signing.
Failure in signature generation. (Retention: Normal)	No additional information
FCS_COP.1/SigVer

	All occurrences of signature generation using a CA signing key. (Retention: Extended)	Name/identifier of object being signed. Identifier of key used for signing.
Failure in signature generation. (Retention: Normal)	No additional information
FCS_HTTPS_EXT.1

	Failure to establish an HTTPS session. (Retention: Normal)	Reason for failure. Non-TOE endpoint of attempted connection (IP address).
Establishment/Termination of an HTTPS session. (Retention: Normal)	Non-TOE enpoint of connection (IP address).
FCS_IPSEC_EXT.1

	Failure to establish an IPsec SA. (Retention: Normal)	Reason for failure. Non-TOE endpoint of connection attempt (IP address).
Establishment/Termination of an IPsec SA. (Retention: Normal)	Non-TOE endpoint of connection attempt (IP address).
FCS_RBG.1
FCS_RBG.1
No events specified	N/A
FCS_RBG.2
FCS_RBG.2
No events specified	N/A
FCS_RBG.3
FCS_RBG.3
No events specified	N/A
FCS_RBG.4
FCS_RBG.4
No events specified	N/A
FCS_RBG.5
FCS_RBG.5
No events specified	N/A
FDP_CRL_EXT.1
FDP_CRL_EXT.1
Failure to generate CRL. (Retention: Normal)	No additional information
FDP_ITT.1
FDP_ITT.1
No events specified	N/A
FDP_OCSPG_EXT.1
FDP_OCSPG_EXT.1
Failure to generate cerficate status information. (Retention: Normal)	No additional information
FIA_AFL.1

	The reaching of the threshold for the unsuccessful authentication attempts. (Retention: Normal)	No additional information
	The action taken.	No additional information
The reenablement of disabled nonadministrative accounts. (Retention: Normal)	No additional information
FIA_CMCC_EXT.1

	CMC requests (generated or received) containing certificate requests or revocation requests. (Retention: Extended)	Identifiers for all entities authenticating the request, including the entity providing client authentication for the CMC transport (if any). The submitted request
CMC responses issued. (Retention: Extended)	Any signed response.
FIA_CMCS_EXT.1

	CMC requests (generated or received) containing certificate requests or revocation requests. (Retention: Extended)	Identifiers for all entities authenticating the request, including the entity providing client authentication for the CMC transport (if any). The submitted request
CMC responses issued. (Retention: Extended)	Any signed response.
FIA_ESTC_EXT.1

	EST requests (generated or received) containing certificate requests or revocation requests. (Retention: Extended)	Identifiers for all entities authenticating the request, including the entity providing client authentication for the EST transport (if any). The submitted request.
EST responses issued. (Retention: Extended)	Any signed response.
FIA_ESTS_EXT.1

	EST requests (generated or received) containing certificate requests or revocation requests. (Retention: Extended)	Identifiers for all entities authenticating the request, including the entity providing client authentication for the EST transport (if any). The submitted request.
EST responses issued. (Retention: Extended)	Any signed response.
FIA_PMG_EXT.1
FIA_PMG_EXT.1
No events specified	N/A
FIA_PSK_EXT.1
FIA_PSK_EXT.1
No events specified	N/A
FIA_UAU.7
FIA_UAU.7
No events specified	N/A
FIA_X509_EXT.3
FIA_X509_EXT.3
No events specified	N/A
FPT_APW_EXT.1
FPT_APW_EXT.1
No events specified	N/A
FPT_ITT.1
FPT_ITT.1
No events specified	N/A
FPT_SKY_EXT.2
FPT_SKY_EXT.2
Access control violations for users involved in key share establishment or control. (Retention: Extended)	No additional information
FPT_TST.1

	Execution of this set of TSF integrity tests (Retention: Normal)	No additional information
Detected integrity violations (Retention: Normal)	The identity of the object that caused the integrity violation
FTP_ITC.1

	Initiation of the trusted channel. (Retention: Normal)	No additional information
	Termination of the trusted channel. (Retention: Normal)	No additional information
Failure of the trusted channel functions. (Retention: Normal)	Identification of the initiator and target of failed trusted channels establishment attempt.

B.2 Class: Security Audit (FAU)

FAU_SCR_EXT.1 Certificate Repository Review

The inclusion of this selection-based component depends upon selection in FAU_GCR_EXT.1.1.

FAU_SCR_EXT.1.1

The TSF shall [selection: provide, invoke the Operational Environment to provide] the capability to search for certificates containing specified values of the following certificate fields: [selection:

subject name
individual components of subject alternative name
subject ID
issuer ID
algorithm ID
public key
key usage
extended key usage
serial number
[assignment: list of other certificate fields]

], returning all matching certificates and [assignment: object identifier(s) of matching certificate(s)].

Application Note: The ability to search on certificate fields is useful for conducting forensic analysis. If the certificate repository is stored within the TOE boundary, then the first item of the first selection is chosen. If the repository is stored in the OE, but the auditor uses TSF interfaces to perform this function on the repository, then the second item of the first selection is chosen. It is allowed that this function be provided entirely by the OE (when the repository is stored in the OE); if this is the case, then this requirement is not included in the ST, but instead the OE.CERTIFICATE_REPOSITORY_SEARCH objective is included (this objective is omitted in the other two cases, when this SFR is included in the ST).

In the second selection and assignment, the ST author includes/fills in the values that can be searched on for this function; at least one value is required to be selected.

FAU_STG_EXT.1 Audit Data Retention

The inclusion of this selection-based component depends upon selection in FAU_STG.1.1.

FAU_STG_EXT.1.1

The TSF shall apply the following rules for retention of audit data:

Audit records required to have extended retention shall be retained at least until an auditor configured extension beyond the validity of all certificates impacted by the event.
[assignment: list of rules]

Application Note: This SFR is to be included if “locally on the TOE” is selected in FAU_STG_EXT.1, and OE.AUDIT_RETENTION is not included in the ST. The TSF may apply different policies for different types of audit data (e.g. one type of record may be stored indefinitely while another type is automatically purged after a set period of time). If this SFR is not included in the ST, then OE.AUDIT_RETENTION is included in the ST.

B.3 Class: Communications (FCO)

FCO_NRR_EXT.2 Certificate-Based Proof of Receipt

The inclusion of this selection-based component depends upon selection in FIA_CMCS_EXT.1.2.

FCO_NRR_EXT.2.1

The TSF shall provide proof of receipt for [selection: CMC, EST] by providing signed responses using mechanisms in accordance with [selection: FIA_CMCS_EXT.1, FIA_ESTS_EXT.1].

Application Note: Based on what is chosen in the selections, the applicable requirements from Annex B (i.e., FIA_CMCS_EXT.1, FIA_ESTS_EXT.1) must be included.

This SFR is claimed if “CMC full responses” is selected in FIA_CMCS_EXT.1.2.

B.4 Class: Cryptographic Support (FCS)

FCS_CKM.1 Cryptographic Key Generation

The inclusion of this selection-based component depends upon selection in FCS_CDP_EXT.1.1.

FCS_CKM.1.1

The TSF shall cryptographic keys in accordance with a specified cryptographic key generation algorithm [selection:

RSA schemes using cryptographic key sizes of 3072-bit or greater that meet the following: FIPS PUB 186-5, “Digital Signature Standard (DSS)”, Appendix B.3;
ECC schemes using “NIST curves” P-384 that meet the following: FIPS PUB 186-5, “Digital Signature Standard (DSS)”, Appendix B.4;
FFC Schemes using “safe-prime” groups that meet the following: ‘NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography,”
FFC Schemes using Diffie-Hellman group 14 that meets the following: RFC 3526

] and specified cryptographic key sizes [assignment: equivalent to or greater than a symmetric key strength of 112 bits] ~~that meet the following: [assignment: list of standards]~~.

Application Note: The ST authors should specify whether the TOE generates these keys or whether the Operational Environment is used.

For keys used for authentication, only RSA- or ECC-based selections are allowed. The ST author will make clear in the ST which keys are used for what purpose.

This component requires that the TSF or Operational Environment be able to generate the public/private key pairs that are used for key establishment purposes for the various cryptographic protocols (HTTPS, TLS, IPsec, SSH) used by the TOE. he ST author selects all key establishment schemes used for the selected cryptographic protocols. For Diffie-Hellman group 14, ST authors should make the corresponding selection from the SFR instead of using the Finite field-based key establishment selection.

Since the domain parameters to be used are specified by the requirements of the protocol in this PP, it is not expected that the TOE will generate domain parameters, and therefore there is no additional domain parameter validation needed when the TOE complies with the protocols specified in this PP.

The generated key strength of RSA keys need to be equivalent to, or greater than, a symmetric key strength of 112 bits. See NIST Special Publication 800-57, “Recommendation for Key Management” for information about equivalent key strengths.

Evaluation Activities

FCS_CKM.1

TSS

The evaluator shall ensure that the TSS identifies the key sizes supported. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme.

Guidance

The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE or OE to use the selected key generation scheme(s) and key size(s) for all cryptographic protocols defined in the Security Target.

Tests

If this requirement is met by the TOE, the evaluator shall verify the implementation of the key generation routines of the supported schemes using the following tests:

Key Generation for FIPS PUB 186-5 RSA Schemes

The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d.

Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include:

Random Primes:
- Provable Primes
- Probable Primes
Primes with Conditions:
- Primes p1, p2, q1,q2, p and q shall all be provable primes
- Primes p1, p2, q1, and q2 shall be provable primes and p and q shall be probable primes
- Primes p1, p2, q1,q2, p and q shall all be probable primes

Key Generation for Elliptic Curve Cryptography (ECC)

FIPS 186-5 ECC Key Generation Test

For P-384, the evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation.

FIPS 186-5 Public Key Verification (PKV) Test

For each supported NIST curve, i.e., P-384, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e., correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values.

Key Generation for Finite-Field Cryptography (FFC)

The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and public key y.

The Parameter generation specifies 2 ways (or methods) to generate the cryptographic prime q and the field prime p:

Primes q and p shall both be provable primes
Primes q and field prime p shall both be probable primes

and two ways to generate the cryptographic group generator g:

Generator g constructed through a verifiable process
Generator g constructed through an unverifiable process.

The Key generation specifies 2 ways to generate the private key x:

len(q) bit output of RBG where 1 <=x <= q-1
len(q) + 64 bit output of RBG, followed by a mod q-1 operation and a +1 operation, where 1<= x<=q-1.

The security strength of the RBG must be at least that of the security offered by the FFC parameter set.

To test the cryptographic and field prime generation method for the provable primes method and/or the group generator g for a verifiable process, the evaluator must seed the TSF parameter generation routine with sufficient data to deterministically generate the parameter set.

For each key length supported, the evaluator shall have the TSF generate 25 parameter sets and key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated from a known good implementation. Verification must also confirm

g != 0,1
q divides p-1
g^q mod p = 1
g^x mod p = y

for each FFC parameter set and key pair.

Diffie-Hellman Group 14 and FFC Schemes using "safe-prime" groups

Testing for FFC Schemes using Diffie-Hellman group 14 and/or "safe-prime" groups is done as part of testing in FCS_CKM.2.1.

Equivalency Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FCS_CKM.2 Cryptographic Key Establishment

The inclusion of this selection-based component depends upon selection in FCS_CDP_EXT.1.1.

FCS_CKM.2.1

The TSF shall in accordance with a specified cryptographic key [selection:

RSA-based key establishment schemes that meet the following: RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 8017, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.2;
Elliptic curve-based key establishment schemes that meet the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”;
Finite field-based key establishment schemes that meet the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”;
Key establishment scheme using Diffie-Hellman group 14 that meets the following: RFC 3526

] ~~that meet the following: [assignment: list of standards]~~.

Application Note: This is a refinement of the SFR FCS_CKM.2 to deal with key establishment rather than key distribution. The ST authors should specify whether the TOE performs the key establishment function or whether the Operational Environment is used.

The ST author selects all key establishment schemes used for the selected cryptographic protocols. For Diffie-Hellman group 14, ST authors should make the corresponding selection from the SFR instead of using the Finite field-based key establishment selection.

The elliptic curves used for the key establishment scheme correlate with the curves specified in FCS_CKM.1.1.

The domain parameters used for the finite field-based key establishment scheme are specified by the key generation according to FCS_CKM.1.1.

Evaluation Activities

FCS_CKM.2

TSS

The evaluator shall ensure that the supported key establishment schemes correspond to the key generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme (including whether the TOE acts as a sender, a recipient, or both). If Diffie-Hellman group 14 is selected from FCS_CKM.2.1, the TSS shall describe how the implementation meets RFC 3526 Section 3.

Guidance

The evaluator shall examine the AGD guidance to ensure it contains instructions for configuring the TOE or Operational Environment to use the selected key establishment scheme(s).

Tests

If this requirement is met by the TOE, the evaluator shall verify the implementation of the key generation routines of the supported schemes using the following tests:

SP800-56A Key Establishment Schemes

The evaluator shall verify a TOE's implementation of SP800-56A key agreement schemes using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has implemented the components of the key agreement scheme according to the specifications in the Recommendation. These components include the calculation of the DLC primitives (the shared secret value Z) and the calculation of the derived keying material (DKM) via the Key Derivation Function (KDF). If key confirmation is supported, the evaluator shall also verify that the components of key confirmation have been implemented correctly, using the test procedures described below. This includes the parsing of the DKM, the generation of MACdata and the calculation of MACtag.

Function Test

The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement scheme-key agreement role combination, KDF type, and, if supported, key confirmation role- key confirmation type combination, the tester shall generate 10 sets of test vectors. The data set consists of one set of domain parameter values (FFC) or the NIST approved curve (ECC) per 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested.

The evaluator shall obtain the DKM, the corresponding TOE’s public keys (static and/or ephemeral), the MAC tag(s), and any inputs used in the KDF, such as the Other Information field OI and TOE id fields.

If the TOE does not use a KDF defined in SP 800-56A, the evaluator shall obtain only the public keys and the hashed value of the shared secret.

The evaluator shall verify the correctness of the TSF’s implementation of a given scheme by using a known good implementation to calculate the shared secret value, derive the keying material DKM, and compare hashes or MAC tags generated from these values.

If key confirmation is supported, the TSF shall perform the above for each implemented approved MAC algorithm.

Validity Test The Validity test verifies the ability of the TOE to recognize another party’s valid and invalid key agreement results with or without key confirmation. To conduct this test, the evaluator shall obtain a list of the supporting cryptographic functions included in the SP800-56A key agreement implementation to determine which errors the TOE should be able to recognize. The evaluator generates a set of 24 (FFC) or 30 (ECC) test vectors consisting of data sets including domain parameter values or NIST approved curves, the evaluator’s public keys, the TOE’s public/private key pairs, MACTag, and any inputs used in the KDF, such as the other info and TOE id fields.

The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value Z, the DKM, the other information field OI, the data to be MACed, or the generated MACTag. If the TOE contains the full or partial (only ECC) public key validation, the evaluator will also individually inject errors in both parties’ static public keys, both parties’ ephemeral public keys and the TOE’s static private key to assure the TOE detects errors in the public key validation function and/or the partial key validation function (in ECC only). At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass).

The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE’s results with the results using a known good implementation verifying that the TOE detects these errors.

RSAES-PKCS1-v1_5 Key Establishment Schemes

The evaluator shall verify the correctness of the TSF’s implementation of RSAES-PKCS1-v1_5 by using a known good implementation for each protocol selected in FTP_ITC, FTP_TRP, and FPT_ITT.

Diffie-Hellman Group 14

The evaluator shall verify the correctness of the TSF’s implementation of Diffie-Hellman group 14 by using a known good implementation for each protocol selected in FTP_TRP.1, FTP_ITC.1 and FPT_ITT.1 that uses Diffie-Hellman group 14.

Equivalency Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FCS_CKM.6 Timing and Event of Cryptographic Key Destruction

The inclusion of this selection-based component depends upon selection in FCS_CDP_EXT.1.1.

FCS_CKM.6.1

The TSF shall [selection: destroy, invoke interfaces provided by the Operational Environment to destroy] [all plaintext keying material and cryptographic security parameters] when [no longer needed].

Application Note: The interface referenced in the requirement could take different forms, the most likely of which is an application programming interface to an OS kernel. There may be various levels of abstraction visible. For instance, in a given implementation the application may have access to the file system details and may be able to logically address specific memory locations. In another implementation, the application may simply have a handle to a resource and can only ask the platform to delete the resource. The level of detail to which the TOE has access will be reflected in the TSS section of the ST.

Several selections allow assignment of a ‘value that does not contain any CSP’. This means that the TOE uses some other specified data not drawn from an RBG meeting FCS_RBG_EXT requirements, and not being any of the particular values listed as other selection options. The point of the phrase ‘does not contain any CSP’ is to ensure that the overwritten data is carefully selected, and not taken from a general ‘pool’ that might contain current or residual data that itself requires confidentiality protection.

Key destruction does not apply to the public component of asymmetric key pairs.

FCS_CKM.6.2

The TSF shall destroy cryptographic keys and critical security parameters which are not permanently protected from export by hardware specified by FCS_CKM.6.1 in accordance with a specified cryptographic key destruction method [selection:

by clearing the KEK encrypting the target key
for volatile memory, the destruction shall be executed by a [selection:
- single direct overwrite consisting of [selection:
  - a pseudo-random pattern using the TSF’s RBG
  - zeroes
  - ones
  - a new value of a key
  - [assignment: some value that does not contain any CSP]
  ]
- removal of power to the memory
- destruction of reference to the key directly followed by a request for garbage collection
]
for non-volatile memory that consists of the invocation of an interface provided by the underlying platform that [selection:
- logically addresses the storage location of the key and performs a [selection: single, [assignment: ST author-defined multi-pass]] direct overwrite consisting of [selection:
  - a pseudo-random pattern using the TSF’s RBG
  - zeroes
  - ones
  - a new value of a key
  - [assignment: some value that does not contain any CSP]
  ]
- instructs the underlying platform to destroy the abstraction that represents the key
]

] that meets the following: [no standard].

Evaluation Activities

FCS_CKM.6

TSS

The evaluator shall examine the TSS to ensure it describes each of the secret keys (keys used for symmetric encryption), private keys, and critical security parameters; when they are destroyed (for example, immediately after use, on system shutdown, etc.); and the type of destruction procedure that is performed (overwrite with zeros, overwrite three times with random pattern, etc.). If different types of memory are used to store the materials to be protected, the evaluator shall examine the TSS to ensure it describes the destruction procedure in terms of the memory in which the data are stored.

Guidance

The evaluator shall examine the AGD guidance to ensure it contains instructions for configuring the TOE to support the required key destruction functionality.

Tests

If this requirement is met by volatile memory in the TOE boundary (the second item in the second selection of FCS_CKM.6.1), the evaluator shall attempt to perform the following tests:

Test FCS_CKM.6:1: The evaluator shall utilize appropriate combinations of specialized operational environment and development tools (debuggers, simulators, etc.) for the TOE and instrumented TOE builds to test that keys are cleared correctly, including all intermediate copies of the key that may have been created internally by the TOE during normal cryptographic processing with that key.

Cryptographic TOE implementations in software shall be loaded and exercised under a debugger to perform such tests. The evaluator shall perform the following test for each key subject to clearing, including intermediate plaintext copies of keys that are subsequently encrypted for storage by the TOE:
1. Load the instrumented TOE build in a debugger.
2. Record the value of the key in the TOE subject to clearing.
3. Cause the TOE to perform a normal cryptographic processing with the key from #1.
4. Cause the TOE to clear the key.
5. Cause the TOE to stop the execution but not exit.
6. Cause the TOE to dump the entire memory footprint of the TOE into a binary file.
7. Search the content of the binary file created in #4 for instances of the known key value from #1.
The test succeeds if no copies of the key from #1 are found in step #7 above and fails otherwise.

The evaluator shall perform this test on all keys, including those subsequently encrypted for storage, to ensure plaintext intermediate copies are cleared.
Test FCS_CKM.6:2: (Conditional) In cases where the TOE is implemented in firmware and operates in a limited operating environment that does not allow the use of debuggers, the evaluator shall utilize a simulator for the TOE on a general purpose operating system. The evaluator shall confirm that keys can be tracked and that destruction occurs. The evaluator shall provide a rationale explaining the instrumentation of the simulated test environment and justifying the obtained test results.

Equivalency Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FCS_CKM_EXT.1/KEK Symmetric Key Generation (KEKs)

The inclusion of this selection-based component depends upon selection in FCS_CKM_EXT.1.1/DEK.

FCS_CKM_EXT.1.1/KEK

The TSF shall be able to [selection: generate, invoke interfaces in the Operational Environment to generate] [selection:

asymmetric KEKs of [assignment: security strength greater than or equal to 112 bits] security strength in accordance with FCS_CKM.1
[selection: size 128-bit, 256-bit] symmetric KEKs using [selection:
- an RBG that meets this profile (as specified in FCS_RBG_EXT.1), a key generation capability of the Operational Environment
- a TSF-provided mechanism that combines KEKs in a way that preserves the effective entropy of each factor by [selection:
  - using an XOR operation
  - concatenating the keys and using a key derivation function (KDF) in accordance with SP 800-108
  - encrypting one key with another in accordance with FCS_COP.1/SKC and using modes [selection: AES-CCM, AES-GCM, AES Key Wrap, AES Key Wrap with Padding]
  ]
]

Application Note: This SFR must be included in the ST if "a TSF-provided mechanism that combines KEKs..." is selected in FCS_CKM_EXT.1/DEK.

There are three major types of keys described in this PP: asymmetric keys used by the TSF for signing, establishing secure channels, and TOE integrity; data encryption keys (DEKs); and key encryption keys (KEKs). Additionally, the TSF may optionally generate subscriber keys. KEKs are used to protect any of these keys. When KEKs protect other keys, they form a key hierarchy. When key hierarchies are used to protect keys generated via a mechanism other than a validated RGB in accordance with FCS_RBG_EXT.1, FCS_CKM_EXT.7 in Annex B.8 must be included. Additionally, FCS_CKM_EXT.8 must also be included in these cases to ensure the consistency of the entire key hierarchy.

This requirement addresses the generation of KEKs used to protect other keys but not used to archive those keys; key archival is addressed by FCS_CKM_EXT.1/KEKT, FCS_CKM_EXT.1/SHARE, and FCS_CKM_EXT.6.

The ST author can select asymmetric or symmetric KEKs (or both). If asymmetric KEKs are selected, the security strength corresponding to the modulus (per FCS_CKM.1 will be in assigned in the requirement in the ST. If symmetric generation is chosen, then the size of the symmetric key is as selected, and the method or methods of generating the symmetric KEKs also will need to be selected.

For the generation of symmetric KEKs, if any option but the RBG option is selected, FCS_CKM_EXT.7 in Annex B.8 must be included.

In the first selection, the ST author chooses whether the TOE performs the operation, or whether it invokes interfaces in the Operational Environment for the functionality.

The second selection indicates if the KEK generated is asymmetric or symmetric, and the requirements on each.

If an asymmetric KEK is generated, then the ST author specifies the security strength of the mechanism in terms of the number of bits, and also includes FCS_CKM.1 in the ST.

If a symmetric KEK is generated, the number of bits of the KEK is specified in the third selection, and then the method of generating the DEK is selected in the fourth (and subsequent) selection.

For the fourth selection, if the TSF invokes an RBG that is implemented by the TOE or implemented by the OE, the first item is selected and FCS_RBG_EXT.1 is included in the ST. If the TSF invokes a key-generation mechanism in the OE (that is not a direct invocation of an RBG), then the second item (“a key generation capability of the Operational Environment”) is selected; in this case the second item of the first selection ("invoke interfaces provided by the Operational Environment to perform") should have also been chosen. If the TSF uses a method to combine KEKs to produce a KEK, the third item is selected and the method used to produce the KEK from the other KEKs is chosen in the fifth selection. If the third item in the fifth selection statement is chosen (key wrap), then FCS_COP.1/SKC will be included in the ST and the appropriate key wrap method will be chosen in the sixth selection.

FCS_CKM_EXT.1/KEKT Symmetric Key Generation (KEKs for TOE Key Archival)

The inclusion of this selection-based component depends upon selection in FCS_CDP_EXT.1.1.

FCS_CKM_EXT.1.1/KEKT

The TSF shall be able to [selection: generate, invoke interfaces provided by the Operational Environment to generate] [selection: asymmetric KEKs of [assignment: security strength greater than or equal to 112 bits] security strength , symmetric KEKs of size 256-bit ] using

[selection:

an Operational Environment-provided mechanism that combines Key Shares and produces a KEK,
a TSF-provided mechanism that combines Key Shares in a way that preserves the effective entropy of each factor by [selection:
- polynomial interpolation based on Shimir’s secret sharing scheme
- geometric construction based on Blakely’s secret sharing mechanism,
- encrypting a shared secret with multiple public keys using a threshold cryptographic scheme
- computing Chinese Remainders, via a Asmuth-Bloom threshold secret sharing scheme,
- [assignment: a secure, threshold-based secret sharing scheme]
]

] for the archival and recovery of TOE keys from two or more shares according to a key sharing mechanism.

Application Note: This SFR is included when the third selection in FPT_SKY_EXT.1/CA or FPT_SKY_EXT.1/OTH indicates that a “key sharing mechanisms in accordance with…” is used. This requirement specifies how the KEK that will be used to protect the keys listed in FPT_SKY_EXT.1/CA or FPT_SKY_EXT.1/OTH is generated from two or more shares. The generation of the shares themselves is specified in FCS_CKM_EXT.1/SHARE, which the ST author includes whenever this SFR is included in the ST. The key that is generated by this requirement is used by the mechanisms specified in FCS_CKM_EXT.6 to protect the keys specified in FPT_SKY_EXT.1/CA or FPT_SKY_EXT.1/OTH.

In the first selection, the ST author chooses whether the TOE performs the operation, or whether it invokes interfaces in the Operational Environment for the functionality.

The second selection indicates if the KEK generated is asymmetric or symmetric.

If an asymmetric KEK is generated, then the ST author specifies the security strength of the mechanism in terms of the number of bits.

If a symmetric KEK is generated, the number of bits of the KEK is specified in the third selection.

For the fourth selection, identify the key sharing mechanism used and reference analysis that documents the basis for the security and entropy preservation.

FCS_CKM_EXT.5 Public Key Integrity

The inclusion of this selection-based component depends upon selection in FCS_CDP_EXT.1.1.

FCS_CKM_EXT.5.1

The TSF shall [selection: protect, invoke interfaces in the Operational Environment to protect] public keys used to meet CA requirements against undetected modification through the use of [selection: digital signatures (in accordance with FCS_COP.1/Sig), keyed hashes (in accordance with FCS_COP.1/KeyedHash)].

FCS_CKM_EXT.5.2

The [selection: digital signature, keyed hash] used to protect a public key shall be verified upon each access to the key.

Application Note: This SFR is included when the second selection in FDP_STG_EXT.1.1 is chosen, and applies to the public keys listed in that SFR. If integrity protection is provided entirely by the OE with no interaction from the TOE (and that is the only method of protecting the public keys), then FDP_STG_EXT.1 should not be claimed in the ST, and instead OE.PUBLIC_KEY_PROTECTION should be included in the ST.

The first item in the first selection is chosen when the TSF performs the cryptographic operation in the second selection itself. If the OE performs the cryptographic operation (calculation of the digital signature or keyed hash), the ST author chooses the second item in the first selection. In either case, the TSF is the entity responsible for checking the public key on each access and taking actions on integrity failures.

The ST author selects “integrity failure on Trust Anchor database” for FPT_FLS.1 if this SFR is included in the ST.

FCS_CKM_EXT.6 Key Archival

The inclusion of this selection-based component depends upon selection in FCS_CDP_EXT.1.1.

FCS_CKM_EXT.6.1

The TSF shall [selection: provide, invoke interfaces in the Operational Environment to provide] a mechanism to protect TOE secret and private keys required for continuity of operations and [selection: user private keys, no other keys].

FCS_CKM_EXT.6.2

The TSF shall [selection: be able to, invoke interfaces in the Operational Environment to be able to] export the protected keys (in FCS_CKM_EXT.6.1) for the purpose of archival in encrypted form.

FCS_CKM_EXT.6.3

The TSF shall [selection: be able to, invoke interfaces in the Operational Environment to be able to] import protected keys (in FCS_CKM_EXT.6.1) for the purpose of continued operations after failure.

FCS_CKM_EXT.6.4

The TSF shall [selection: encrypt, invoke interfaces in the Operational Environment to encrypt] the keys specified in FCS_CKM_EXT.6.1 in accordance with [selection: FCS_COP.1/SKC, FCS_CKM.1] using the KEK generated in accordance with FCS_CKM_EXT.1/KEKT.

FCS_CKM_EXT.6.5

The TSF shall [selection: decrypt, invoke interfaces in the Operational Environment to decrypt] the keys specified in FCS_CKM_EXT.6.1 in accordance with [selection: FCS_COP.1/SKC, FCS_CKM.1] using the KEK generated in accordance with FCS_CKM_EXT.1/KEKT.

Application Note: This requirement is required when ‘key sharing mechanisms…’ is selected in FPT_SKY_EXT.1/CA or FPT_SKY_EXT.1/OTH, and ensures that the archival of any keys required for continuity of operations (e.g., signature keys used to sign CRLs) from the TOE involves encryption of those keys using KEKs that were derived using key sharing mechanisms as specified in FCS_CKM_EXT.1/KEKT.

FCS_CKM_EXT.7 Key Generation for KEKs

The inclusion of this selection-based component depends upon selection in FCS_CKM_EXT.1.1/DEK, FCS_CKM_EXT.1.1/KEK.

FCS_CKM_EXT.7.1

The [selection: TSF, Operational environment] shall support a hardware protected REK generated in accordance with FCS_CKM_EXT.1.1/KEK.

FCS_CKM_EXT.7.2

A REK shall not be able to be read from or exported from the hardware.

FCS_CKM_EXT.7.3

The TSF shall be able only to request encryption/decryption by the key and shall not be able to read, import, or export a REK.

FCS_CKM_EXT.7.4

A REK shall be generated [selection: by a RBG in accordance with FCS_RBG_EXT.1, according to FCS_CKM.1].

Application Note: This SFR must be included in the ST if "a TSF-provided mechanism that combines KEKs..." is selected in FCS_CKM_EXT.1/KEK or if "a TSF-provided mechanism that combines KEKs..." is selected in FCS_CKM_EXT.1/DEK.

Either asymmetric or symmetric keys are allowed; the ST author makes the selection appropriate for the device. Symmetric keys must be of size 256 bits in order to correspond with FCS_COP.1/SKC. Asymmetric keys may be of any strength corresponding to FCS_CKM.1.

The lack of a public/documented API for importing or exporting, when a private/undocumented API exists, is not sufficient to meet this requirement.

When TSF is selected in FCS_CKM_EXT.7.1, the RBG used to generate a REK may be a RBG native to a hardware key container that is within the TOE boundary or may be generated using an off-device RBG during manufacturing. If generated by an off-device RBG during manufacturing, the device manufacturer shall not be able to access a REK after the manufacturing process has been completed. If a hardware component in the Operational Environment stores the REK, the RBG may be resident in the component where the REK is stored, or in a separate component. The assurance activities for these cases differ.

This SFR is included when FCS_CKM_EXT.1/KEK is included and selects generation of symmetric KEKs that are not generated by an RBG. Additionally, FCS_CKM_EXT.8 must also be included when this SFR is included to ensure the consistency of the entire key hierarchy.

FCS_CKM_EXT.8 Key Hierarchy Entropy

The inclusion of this selection-based component depends upon selection in FCS_CKM_EXT.1.1/DEK, FCS_CKM_EXT.1.1/KEK.

FCS_CKM_EXT.8.1

The TSF shall provide a traceable hierarchy of keys (DEKs or KEKs) formed from combinations or by encrypting one key with another to a REK generated in accordance with FCS_RBG_EXT.1 using a hardware-based mechanism.

FCS_CKM_EXT.8.2

Key entropy for KEKs shall be preserved according to the sensitivity of the DEK, KEK, or key it encrypts.

FCS_CKM_EXT.8.3

Key entropy for DEKs shall be [selection: 128, 256] bits in accordance with the sensitivity of the data encrypted.

Application Note: This SFR must be included in the ST if "a TSF-provided mechanism that combines KEKs..." is selected in FCS_CKM_EXT.1/KEK or if "a TSF-provided mechanism that combines KEKs..." is selected in FCS_CKM_EXT.1/DEK.

KEKs may form key hierarchies, each rooted in a root encryption key (REK); a REK is considered a KEK. DEKs are used to protect data (e.g., subscriber PII). KEKs are used to protect other keys–- DEKs, other KEKs, and other types of keys stored by the user or applications. A REK is a special KEK that uses available hardware protections (e.g., trusted platform module (TPM) or external hardware cryptographic module) and is generated in accordance with FCS_RBG_EXT.1.

FCS_COP.1/Hash Cryptographic Operation (Cryptographic Hashing)

The inclusion of this selection-based component depends upon selection in FCS_CDP_EXT.1.1.

FCS_COP.1.1/Hash

The TSF shall [cryptographic hashing services] in accordance with a specified cryptographic algorithm [SHA-384] and sizes [384] bits that meet the following: [FIPS Pub 180-4, “Secure Hash Standard”].

Application Note: The selection of the hashing algorithm must correspond to the selection of the message digest size; for example, if SHA-256 is chosen, then the only valid message digest size selection would be 256 bits.

The TSF hashing functions can be implemented in one of two modes. The first mode is the byte-oriented mode. In this mode the TSF only hashes messages that are an integral number of bytes in length; i.e., the length (in bits) of the message to be hashed is divisible by 8. The second mode is the bit-oriented mode. In this mode the TSF hashes messages of arbitrary length. As there are different tests for each mode, an indication is given in the following sections for the bit-oriented vs. the byte-oriented test modes.

Evaluation Activities

FCS_COP.1/Hash

TSS

Regardless of whether the requirement is met by the TSF or TOE platform, the evaluator shall examine the TSS to ensure that all hash functions use the approved algorithms, modes and key sizes.

Guidance

The evaluator shall examine the AGD guidance to ensure it documents how to configure the TOE or the TOE in conjunction with the Operational Environment for the required hash sizes. The AGD guidance shall also include instructions for disabling deprecated algorithms.

Tests

If this requirement is met by the TOE, the evaluator shall perform all of the following tests for each hash algorithm implemented by the TSF and used to satisfy the requirements of this PP.

Short Messages Test -- Bit-Oriented Mode

The evaluator shall devise an input set consisting of m+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m bits. The message text shall be pseudorandomly generated. The evaluator shall compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF.

Short Messages Test -- Byte-Oriented Mode

The evaluator shall devise an input set consisting of m/8+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m/8 bytes, with each message being an integral number of bytes. The message text shall be pseudorandomly generated. The evaluator shall compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF.

Selected Long Messages Test -- Bit-Oriented Mode

The evaluator shall devise an input set consisting of m messages, where m is the block length of the hash algorithm. The length of the ith message is 512 + 99*i, where 1 ≤ i ≤ m. The message text shall be pseudorandomly generated. The evaluator shall compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF.

Selected Long Messages Test -- Byte-Oriented Mode

The evaluator shall devise an input set consisting of m/8 messages, where m is the block length of the hash algorithm. The length of the ith message is 512 + 8*99*i, where 1 ≤ i ≤ m/8. The message text shall be pseudorandomly generated. The evaluator shall compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF.

Pseudorandomly Generated Messages Test

This test is for byte-oriented implementations only. The evaluator shall randomly generate a seed that is n bits long, where n is the length of the message digest produced by the hash function to be tested. The evaluator shall then formulate a set of 100 messages and associated digests by following the algorithm provided in Figure 1 of [SHAVS]. The evaluator shall then ensure that the correct result is produced when the messages are provided to the TSF.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FCS_COP.1/KeyedHash Cryptographic Operation (Keyed-Hash Message Authentication)

The inclusion of this selection-based component depends upon selection in FCS_CDP_EXT.1.1.

FCS_COP.1.1/KeyedHash

The TSF shall [keyed hash message authentication] in accordance with a specified cryptographic algorithm [HMAC-SHA-384 with key size [assignment: key size (in bits) used in HMAC]] and sizes [384] bits that meet the following: [FIPS Pub 198-1,“The Keyed Hash Message Authentication Code”; FIPS Pub 180-4, “Secure Hash Standard”].

Application Note: The intent of this requirement is to specify the keyed hash message authentication function used when used for key establishment purposes for the various cryptographic protocols used by the TOE (e.g., trusted channel). The hash selection must support the message digest size selection. The hash selection should be consistent with the overall strength of the algorithm used for FCS_COP.1/SKC.

FCS_COP.1/SKC Cryptographic Operation (AES Encryption/Decryption)

The inclusion of this selection-based component depends upon selection in FCS_CDP_EXT.1.1.

FCS_COP.1.1/SKC

The TSF shall [encryption and decryption] in accordance with a specified cryptographic algorithm:

and cryptographic key size [256-bit] ~~that meet the following: [assignment: list of standards]~~.

Application Note: For the third selection of FCS_COP.1.1/SKC, the ST author should choose the mode or modes in which AES operates.

This SFR is in support of multiple TOE encryption requirements. AES-CBC is used for encryption only, AES-CCM and AES-GCM for encryption and authentication, AES-XTS for encryption only, and AES Key Wrap and AES Key Wrap with Padding for key wrapping. It is necessary for the ST author to ensure that the selected AES modes and key sizes are consistent with the claims made in any of the selection-based cryptographic protocols (e.g. if FCS_IPSEC_EXT.1 is selected, CBC and/or GCM must be selected).

Evaluation Activities

FCS_COP.1/SKC

TSS

Regardless of whether the requirement is met by the TSF or the TSF in conjunction with the TOE platform, the evaluator shall examine the TSS to ensure that all key encryption and decryption functions use the approved algorithms, modes, and key sizes.

Guidance

The evaluator shall examine the AGD guidance to ensure it contains instructions for configuring the TOE or the TOE in conjunction with the Operational Environment for the required encryption algorithms and associated modes and key sizes.

Tests

The following tests shall be performed for functionality implemented by the TSF.

AES-CBC Tests

AES-CBC Known Answer Tests

There are four Known Answer Tests (KATs), described below. In all KATs, the plaintext, ciphertext, and IV values shall be 128-bit blocks. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

KAT-1. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of 5 plaintext values for each key size selected and obtain the ciphertext value that results from AES-CBC encryption of the given plaintext using a key value of all zeros and an IV of all zeros. Five plaintext values shall be encrypted with an all-zeros key of length equal to the selected key size, for each key size selected.

To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using the ciphertext values as input and AES-CBC decryption. KAT-2. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of 5 key values for each key size selected and obtain the ciphertext value that results from AES-CBC encryption of an all-zeros plaintext using the given key value and an IV of all zeros. Five of the keys shall be of length equal to the selected key size, for each key size selected.

To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using an all-zero ciphertext value as input and AES-CBC decryption.

KAT-3. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of key values described below for each key size selected and obtain the ciphertext value that results from AES encryption of an all-zeros plaintext using the given key value and an IV of all zeros. The keys in each set shall have the same length as the selected key size, for each key size, N. Key I in each set shall have the leftmost I bits be ones and the rightmost N-I bits be zeros, for I in [1,N].

To test the decrypt functionality of AES-CBC, the evaluator shall supply the two sets of key and ciphertext value pairs described below and obtain the plaintext value that results from AES-CBC decryption of the given ciphertext using the given key and an IV of all zeros. Each set of key/ciphertext pairs shall have N N-bit key/ciphertext pairs, and the second set of key/ciphertext pairs for selected key size, N. Key I in each set shall have the leftmost I bits be ones and the rightmost N-I bits be zeros, for I in [1,N]. The ciphertext value in each pair shall be the value that results in an all-zeros plaintext when decrypted with its corresponding key.

KAT-4. To test the encrypt functionality of AES-CBC, the evaluator shall supply the set of 128 plaintext values described below and obtain ciphertext values that result from AES-CBC encryption of the given plaintext using a key value of all zeros of length equal to the selected key size with an IV of all zeros for each key size selected. Plaintext value I in each set shall have the leftmost I bits be ones and the rightmost 128-I bits be zeros, for I in [1,128].

To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using ciphertext values of the same form as the plaintext in the encrypt test as input and AES-CBC decryption.

AES-CBC Multi-Block Message Test

The evaluator shall test the encrypt functionality by encrypting an i-block message where 1 < I <=10. The evaluator shall choose a key, an IV and plaintext message of length I blocks and encrypt the message, using the mode to be tested, with the chosen key and IV. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation.

The evaluator shall also test the decrypt functionality for each mode by decrypting an i-block message where 1 < I <=10. The evaluator shall choose a key, an IV and a ciphertext message of length I blocks and decrypt the message, using the mode to be tested, with the chosen key and IV. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key and IV using a known good implementation.

AES-CBC Monte Carlo Tests

The evaluator shall test the encrypt functionality using a set of 100 plaintext, IV, and key 3-tuples for each selected key size. The plaintext and IV values shall be 128-bit blocks. For each 3-tuple, 1000 iterations shall be run as follows:

				# Input: PT, IV, Key
				for I = 1 to 1000:
					if I == 1:
						CT[1] = AES-CBC-Encrypt(Key, IV, PT)
						PT = IV
					else:
						CT[i] = AES-CBC-Encrypt(Key, PT)
						PT = CT[i-1]

The ciphertext computed in the 1000th iteration (i.e., CT[1000]) is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation.

The evaluator shall test the decrypt functionality using the same test as for encrypt, exchanging CT and PT and replacing AES-CBC-Encrypt with AES-CBCDecrypt.

AES-CCM Tests

The evaluator shall test the generation-encryption and decryption-verification functionality of AES-CCM for the following input parameter and tag lengths:

Each selected key length

Two payload lengths.One payload length shall be the shortest supported payload length, greater than or equal to zero bytes. The other payload length shall be the longest supported payload length, less than or equal to 32 bytes (256 bits).

Two payload lengths. One payload length shall be the shortest supported payload length, greater than or equal to zero bytes. The other payload length shall be the longest supported payload length, less than or equal to 32 bytes (256 bits).

Two or three associated data lengths. One associated data length shall be 0, if supported. One associated data length shall be the shortest supported payload length, greater than or equal to zero bytes. One associated data length shall be the longest supported payload length, less than or equal to 32 bytes (256 bits). If the implementation supports an associated data length of 216 bytes, an

Nonce lengths. All supported nonce lengths between 7 and 13 bytes, inclusive, shall be tested.

Tag lengths. All supported tag lengths of 4, 6, 8, 10, 12, 14 and 16 bytes shall be tested.

To test the generation-encryption functionality of AES-CCMP, the evaluator shall perform the following four tests:

Test FCS_COP.1/SKC:1: For EACH supported key and associated data length and ANY supported payload, nonce and tag length, the evaluator shall supply one key value, one nonce value and 10 pairs of associated data and payload values and obtain the resulting ciphertext.
Test FCS_COP.1/SKC:2: . For EACH supported key and payload length and ANY supported associated data, nonce and tag length, the evaluator shall supply one key value, one nonce value and 10 pairs of associated data and payload values and obtain the resulting ciphertext.
Test FCS_COP.1/SKC:3: For EACH supported key and nonce length and ANY supported associated data, payload and tag length, the evaluator shall supply one key value and 10 associated data, payload and nonce value 3-tuples and obtain the resulting ciphertext.
Test FCS_COP.1/SKC:4: For EACH supported key and tag length and ANY supported associated data, payload and nonce length, the evaluator shall supply one key value, one nonce value and 10 pairs of associated data and payload values and obtain the resulting ciphertext.

To determine correctness in each of the above tests, the evaluator shall compare the ciphertext with the result of generation-encryption of the same inputs with a known good implementation.

To test the decryption-verification functionality of AES-CCM, for EACH combination of supported associated data length, payload length, nonce length and tag length, the evaluator shall supply a key value and 15 nonce, associated data and ciphertext 3-tuples and obtain either a FAIL result or a PASS result with the decrypted payload. The evaluator shall supply 10 tuples that should FAIL and 5 that should PASS per set of 15.

Additionally, the evaluator shall use tests from the IEEE 802.11-02/362r6 document “Proposed Test vectors for IEEE 802.11 TG”, dated September 10, 2002, Section 2.1 AES-CCMP Encapsulation Example and Section 2.2 Additional AES CCMP Test Vectors to further verify the IEEE 802.11-2007 implementation of AES-CCMP.

AES-Galois\Counter Mode (GCM) Monte Carlo Test

The evaluator shall test the authenticated encrypt functionality of AES-GCM for each combination of the following input parameter lengths:

Each selected key length

Two plaintext lengths. One of the plaintext lengths shall be a non-zero integer multiple of 128 bits, if supported. The other plaintext length shall not be an integer multiple of 128 bits, if supported.

Three AAD lengths. One AAD length shall be 0, if supported. One AAD length shall be a non-zero integer multiple of 128 bits, if supported. One AAD length shall not be an integer multiple of 128 bits, if supported.

Two IV lengths. If 96 bit IV is supported, 96 bits shall be one of the two IV lengths tested.

The evaluator shall test the encrypt functionality using a set of 10 key, plaintext, AAD, and IV tuples for each combination of parameter lengths above and obtain the ciphertext value and tag that results from AES-GCM authenticated encrypt. Each supported tag length shall be tested at least once per set of 10. The IV value may be supplied by the evaluator or the implementation being tested, as long as it is known.

The evaluator shall test the decrypt functionality using a set of 10 key, ciphertext, tag, AAD, and IV 5-tuples for each combination of parameter lengths above and obtain a Pass/Fail result on authentication and the decrypted plaintext if Pass. The set shall include five tuples that Pass and five that Fail.

The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

XTS-AES Monte Carlo Test

The evaluator shall test the encrypt functionality of XTS-AES for each combination of the following input parameter lengths:

Each selected key length

Three data unit (i.e., plaintext) lengths. One of the data unit lengths shall be a non-zero integer multiple of 128 bits, if supported. One of the data unit lengths shall be an integer multiple of 128 bits, if supported. The third data unit length shall be either the longest supported data unit length or 216 bits, whichever is smaller.

Using a set of 100 key, plaintext and 128-bit random tweak value 3-tuples and obtain the ciphertext that results from XTS-AES encrypt.

The evaluator may supply a data unit sequence number instead of the tweak value if the implementation supports it. The data unit sequence number is a base-10 number ranging between 0 and 255 that implementations convert to a tweak value internally.

The evaluator shall test the decrypt functionality of XTS-AES using the same test as for encrypt, replacing plaintext values with ciphertext values and XTSAES encrypt with XTS-AES decrypt.

AES Key Wrap (AES-KW) and Key Wrap with Padding (AES-KWP) Test

The evaluator shall test the authenticated encryption functionality of AES-KW for EACH combination of the following input parameter lengths:

Each selected key length

Three plaintext lengths. One of the plaintext lengths shall be two semiblocks (128 bits). One of the plaintext lengths shall be three semiblocks (192 bits). The third data unit length shall be the longest supported plaintext length less than or equal to 64 semi-blocks (4096 bits).

Using a set of 100 key and plaintext pairs and obtain the ciphertext that results from AES-KW authenticated encryption. To determine correctness, the evaluator shall use the AES-KW authenticated-encryption function of a known good implementation.

The evaluator shall test the authenticated-decryption functionality of AES-KW using the same test as for authenticated-encryption, replacing plaintext values with ciphertext values and AES-KW authenticated-encryption with AES-KW authenticated-decryption.

The evaluator shall test the authenticated-encryption functionality of AES-KWP using the same test as for AES-KW authenticated-encryption with the following change in the three plaintext lengths:

One plaintext length shall be one octet. One plaintext length shall be 20 octets (160 bits).

One plaintext length shall be the longest supported plaintext length less than or equal to 512 octets (4096 bits).

The evaluator shall test the authenticated-decryption functionality of AES-KWP using the same test as for AES-KWP authenticated-encryption, replacing plaintext values with ciphertext values and AES-KWP authenticated-encryption with AES-KWP authenticated-decryption.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FCS_COP.1/SigVer Cryptographic Operation (Cryptographic Signature)

The inclusion of this selection-based component depends upon selection in FCS_CDP_EXT.1.1.

FCS_COP.1.1/SigVer

The TSF shall [cryptographic signature verification services] in accordance with a specified cryptographic algorithms [selection:

RSA Digital Signature Algorithm (rDSA) with a key size (modulus) of [assignment: 3072 bits or greater] that meets FIPS-PUB 186-5, “Digital Signature Standard”
Elliptic Curve Digital Signature Algorithm (ECDSA) with a key size of 256 bits or greater that meets FIPS PUB 186-5, “Digital Signature Standard” with “NIST curves” P-384 and [selection: P-521, no other curves] (as defined in FIPS PUB 186-5, “Digital Signature Standard”)
Digital Signature Algorithm (DSA) with a key size (modulus) of 2048 bits or greater, that meets FIPS-PUB 186-5, “Digital Signature Standard”]

] ~~and cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards].~~

Application Note: The ST should specify whether the TOE performs the algorithms, or whether the TOE in combination with the Operational Environment is used.

The ST author should choose the algorithm implemented to verify digital signatures; if more than one algorithm is available, this requirement (and the corresponding FCS_CKM.1 requirement) should be iterated to specify the functionality. For the algorithm chosen, the ST author should make the appropriate assignments/selections to specify the parameters that are implemented for that algorithm.

For elliptic curve-based schemes, the key size refers to the log2 of the order of the base point. As the preferred approach for digital signatures, ECDSA will be required in future publications of this PP.

Evaluation Activities

FCS_COP.1/SigVer

TSS

Regardless of whether the requirement is met by the TSF or TOE platform, the evaluator shall examine the TSS to ensure that all signature verification functions use the approved algorithms and key sizes.

Guidance

The evaluator shall examine the AGD guidance to ensure it contains instructions for configuring the TOE or the TIE in conjunction with the Operational Environment for the required signature algorithms and associated modes and key sizes.

Tests

The following tests shall be performed for functionality implemented by the TSF.

FIPS 186-5 Public Key Verification (PKV) Test

For each supported NIST curve, i.e., P-384 and P-521, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e., correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values.

ECDSA Algorithm Tests

ECDSA FIPS 186-5 Signature Verification Test

For each supported NIST curve (i.e.,P-384 and P-521) and SHA function pair, the evaluator shall generate a set of 10 1024-bit message, public key and signature tuples and modify one of the values (message, public key or signature) in five of the 10 tuples. The evaluator shall obtain in response a set of 10 PASS/FAIL values.

RSA Signature Algorithm Tests

Signature Verification Test

The evaluator shall perform the Signature Verification test to verify the ability of the TOE to recognize another party’s valid and invalid signatures. The evaluator shall inject errors into the test vectors produced during the Signature Verification Test by introducing errors in some of the public keys e, messages, IR format, and/or signatures. The TOE attempts to verify the signatures and returns success or failure.

The evaluator shall use these test vectors to emulate the signature verification test using the corresponding parameters and verify that the TOE detects these errors.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FCS_COP.1/SigGen Cryptographic Operation (Cryptographic Signature)

The inclusion of this selection-based component depends upon selection in FCS_CDP_EXT.1.1.

FCS_COP.1.1/SigGen

The TSF shall [cryptographic signature generation services] in accordance with a specified cryptographic algorithms [selection:

RSA Digital Signature Algorithm (rDSA) with a key size (modulus) of [assignment: 3072 bits or greater] that meets FIPS-PUB 186-5, “Digital Signature Standard”
Elliptic Curve Digital Signature Algorithm (ECDSA) with a key size of 384 bits or greater that meets FIPS PUB 186-5, “Digital Signature Standard” with “NIST curves” P-384 (as defined in FIPS PUB 186-5, “Digital Signature Standard”)

] ~~and cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards].~~

Application Note: The ST should specify whether the TOE performs the algorithms, or whether the TOE in combination with the Operational Environment is used.

The ST author should choose the algorithm implemented to perform digital signature generation; if more than one algorithm is available, this requirement (and the corresponding FCS_CKM.1 requirement) should be iterated to specify the functionality. For the algorithm chosen, the ST author should make the appropriate assignments/selections to specify the parameters that are implemented for that algorithm.

For elliptic curve-based schemes, the key size refers to the log2 of the order of the base point. As the preferred approach for digital signatures, ECDSA will be required in future publications of this PP.

Evaluation Activities

FCS_COP.1/SigGen

TSS

Regardless of whether the requirement is met by the TSF or TOE platform, the evaluator shall examine the TSS to ensure that all signature generation functions use the approved algorithms and key sizes.

Guidance

Tests

The following tests shall be performed for functionality implemented by the TSF.

Key Generation

Key Generation for RSA Signature Schemes

The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d.

Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include:

Random Primes:

Provable Primes
Probable Primes

Primes with Conditions:

Primes p1, p2, q1,q2, p and q shall all be provable primes
Primes p1, p2, q1, and q2 shall be provable primes and p and q shall be probable primes
Primes p1, p2, q1,q2, p and q shall all be probable primes

To test the key generation method for the Random Provable primes method and for all the Primes with Conditions methods, the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. This includes the random seed(s), the public exponent of the RSA key, and the desired key length. For each key length supported, the evaluator shall have the TSF generate 25 key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated from a known good implementation.

ECDSA Key Generation Tests

FIPS 186-5 ECDSA Key Generation Test

For each supported NIST curve, i.e., P-384, the evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation.

ECDSA Algorithm Tests

ECDSA FIPS 186-5 Signature Generation Test

For each supported NIST curve (i.e., P-384) and SHA function pair, the evaluator shall generate 10 1024-bit long messages and obtain for each message a public key and the resulting signature values R and S. To determine correctness, the evaluator shall use the signature verification function of a known good implementation.

RSA Signature Algorithm Tests

Signature Generation Tests

The evaluator shall verify the implementation of RSA Signature Generation by the TOE using the Signature Generation Test. To conduct this test the evaluator must generate or obtain 10 messages from a trusted reference implementation for each modulus size/SHA combination supported by the TSF. The evaluator shall have the TOE use their private key and modulus value to sign these messages.

The evaluator shall verify the correctness of the TSF’s signature using a known good implementation and the associated public keys to verify the signatures.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FCS_HTTPS_EXT.1 HTTPS Protocol

The inclusion of this selection-based component depends upon selection in FTP_ITC.1.1, FTP_TRP.1.1.

FCS_HTTPS_EXT.1.1

The TSF shall implement the HTTPS protocol that complies with RFC 2818.

Application Note: The ST author must provide enough detail to determine how the implementation is complying with the standard(s) identified; this can be done either by adding elements to this component, or by additional detail in the TSS.

FCS_HTTPS_EXT.1.2

The TSF shall implement HTTPS using TLS.

FCS_IPSEC_EXT.1 IPsec Protocol

The inclusion of this selection-based component depends upon selection in FTP_ITC.1.1, FTP_TRP.1.1.

FCS_IPSEC_EXT.1.1

The TSF shall implement IPsec to protect communication among TSF components and between TSF and OE components as specified in RFC 4301 and discard unauthorized communication.

Application Note: RFC 4301 calls for an IPsec implementation to protect IP traffic through the use of a Security Policy Database (SPD). The SPD is used to define how IP packets are to be handled: PROTECT the packet (e.g., encrypt the packet), BYPASS the IPsec services (e.g., no encryption), or DISCARD the packet (e.g., drop the packet). The SPD can be implemented in various ways, including router access control lists, firewall rulesets, a “traditional” SPD, etc. Regardless of the implementation details, there is a notion of a “rule” that a packet is “matched” against and a resulting action that takes place.

While there must be a means to order the rules, a general approach to ordering is not mandated, as long as the SPD can distinguish the IP packets and apply the rules accordingly. There may be multiple SPDs (one for each network interface), but this is not required.

FCS_IPSEC_EXT.1.2

The TSF shall have a nominal, final entry in the SPD that matches anything that is otherwise unmatched, and discards it.

FCS_IPSEC_EXT.1.3

The TSF shall implement transport mode and [selection: tunnel mode, no other mode].

FCS_IPSEC_EXT.1.4

The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using the cryptographic algorithms [AES-GCM-256 (specified in RFC 4106)] together with a Secure Hash Algorithm (SHA)-based HMAC.

FCS_IPSEC_EXT.1.5

The TSF shall implement the protocol [IKEv2] as defined in RFC 5996 and [selection: with no support for NAT traversal, with mandatory support for NAT traversal as specified in RFC 5996, section 2.23)], and [selection: no other RFCs for hash functions, RFC 4868 for hash functions].

Application Note: If the TOE implements SHA-2 hash algorithms, the ST author shall select RFC 4868.

FCS_IPSEC_EXT.1.6

The TSF shall ensure the encrypted payload in the IKEv2 protocol uses the cryptographic algorithms AES-GCM-256 as specified in RFC 5282.

FCS_IPSEC_EXT.1.7

The TSF shall ensure that IKEv2] SA lifetimes can be configured by an Administrator based on [selection:

number of packets/bytes;
length of time, where the time values can be configured within [assignment: integer range including 24] hours.

]

Application Note: The ST author chooses either packet/volume-based lifetimes or time-based lifetimes. This requirement must be accomplished by providing Security Administrator-configurable lifetimes (with appropriate instructions in documents mandated by AGD_OPE). Hardcoded limits are not acceptable. In general, instructions for setting the parameters of the implementation, including lifetime of the SAs, should be included in the operational guidance generated for AGD_OPE.

FCS_IPSEC_EXT.1.8

The TSF shall ensure that [IKEv2] Child SA lifetimes can be configured by an Administrator based on [selection:

number of packets/bytes;
length of time, where the time values can be configured within [assignment: integer range including 8] hours

FCS_IPSEC_EXT.1.9

The TSF shall generate the secret value x used in the IKE Diffie-Hellman key exchange (“x” in g^x mod p) using the random bit generator specified in FCS_RBG.1, and having a length of at least [assignment: (one or more) number(s) of bits that is at least twice the security strength of the negotiated Diffie-Hellman group] bits.

Application Note: For DH groups 19 and 20, the "x" value is the point multiplier for the generator point G.

Since the implementation may allow different Diffie-Hellman groups to be negotiated for use in forming the SAs, the assignment in FCS_IPSEC_EXT.1.9 may contain multiple values. For each DH group supported, the ST author consults Table 2 in NIST SP 800-57 “Recommendation for Key Management –Part 1: General” to determine the security strength (“bits of security”) associated with the DH group. Each unique value is then used to fill in the assignment. For example, suppose the implementation supports DH group 14 (2048-bit MODP) and group 20 (ECDH using NIST curve P-384). From Table 2, the bits of security value for group 14 is 112, and for group 20 it is 192.

FCS_IPSEC_EXT.1.10

The TSF shall generate nonce used in [IKEv2] exchanges of length [at least 128 bits in size and at least half the output size of the negotiated pseudorandom function (PRF) hash].

Application Note: Because nonces may be exchanged before the DH group is negotiated, the nonce used should be large enough to support all TOE-chosen proposals in the exchange.

FCS_IPSEC_EXT.1.11

The TSF shall ensure that all IKE protocols implement [selection: DH Group 20 (384-bit Random ECP), no other DH groups].

Application Note: It should be noted that if any additional DH groups are specified, they must comply with the requirements (in terms of the ephemeral keys that are established) listed in FCS_CKM.1/FCS_CKM.2.

FCS_IPSEC_EXT.1.12

The TSF shall be able to ensure by default that the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the [IKEv2 IKE_SA] connection is greater than or equal to the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the [IKEv2 CHILD_SA] connection.

Application Note: While it is acceptable for this capability to be configurable, the default configuration in the evaluated configuration (either "out of the box" or by configuration guidance in the AGD documentation) must enable this functionality.

FCS_IPSEC_EXT.1.13

The TSF shall ensure that all IKE protocols perform peer authentication using a [selection: RSA, ECDSA] that use X.509v3 certificates that conform to RFC 4945 and [selection: Pre-shared Keys, no other method].

Application Note: At least one public-key-based Peer Authentication method is required in order to conform to this PP; one or more of the public key schemes is chosen by the ST author to reflect what is implemented. The ST author also ensures that appropriate FCS requirements reflecting the algorithms used (and key generation capabilities, if provided) are listed to support those methods. Note that the TSS will elaborate on the way in which these algorithms are to be used (for example, 2409 specifies three authentication methods using public keys; each one supported will be described in the TSS).

FCS_IPSEC_EXT.1.14

The TSF shall support peer identifiers of the following types: [selection: IP address, Fully Qualified Domain Name (FQDN), user FQDN, Distinguished Name (DN)] and [selection: no other reference identifier type, [assignment: other supported reference identifier types]].

Application Note: The TOE must support at least one of the following identifier types: IP address, Fully Qualified Domain Name (FQDN), user FQDN, or Distinguished Name (DN). In the future, the TOE will be required to support all of these identifier types. The TOE is expected to support as many IP address formats (IPv4 and IPv6) as IP versions supported by the TOE in general. The ST author may assign additional supported identifier types in the second selection.

FCS_IPSEC_EXT.1.15

The TSF shall not establish an SA if the presented identifier does not match the configured reference identifier of the peer.

Application Note: At this time, only the comparison between the presented identifier in the peer’s certificate and the peer’s reference identifier is mandated by the testing below. However, in the future, this requirement will address two aspects of the peer certificate validation: 1) comparison of the peer’s ID payload to the peer’s certificate which are both presented identifiers, as required by RFC 4945 and 2) verification that the peer identified by the ID payload and the certificate is the peer expected by the TOE (per the reference identifier). At that time, the TOE will be required to demonstrate both aspects (i.e. that the TOE enforces that the peer’s ID payload matches the peer’s certificate which both match configured peer reference identifiers).

Excluding the DN identifier type (which is necessarily the Subject DN in the peer certificate), the TOE may support the identifier in either the Common Name or Subject Alternative Name (SAN) or both. If both are supported, the preferred logic is to compare the reference identifier to a presented SAN, and only if the peer’s certificate does not contain a SAN, to fall back to a comparison against the Common Name. In the future, the TOE will be required to compare the reference identifier to the presented identifier in the SAN only, ignoring the Common Name.

The configuration of the peer reference identifier is addressed by FMT_SMF.1.1.

Evaluation Activities

FCS_IPSEC_EXT.1

TSS

The evaluator shall examine the TSS and determine that it describes what takes place when a packet is processed by the TOE, e.g., the algorithm used to process the packet. The TSS describes how the SPD is implemented and the rules for processing both inbound and outbound packets in terms of the IPsec policy. The TSS describes the rules that are available and the resulting actions available after matching a rule. The TSS describes how those rules and actions form the SPD in terms of the DISCARD (e.g., drop the packet), and PROTECT (e.g., encrypt the packet) actions defined in RFC 4301 (BYPASS should not be included).

As noted in section 4.4.1 of RFC 4301, the processing of entries in the SPD is non-trivial and the evaluator shall determine that the description in the TSS is sufficient to determine which rules will be applied to protect communication between TOE components and authorized external IT entities, and discard all other communications. This description shall cover both the initial packets (that is, no SA is established on the interface or for that particular packet) as well as packets that are part of an established SA.

The evaluator checks the TSS to ensure it states that the VPN can be established to operate in tunnel mode and/or transport mode (as identified in FCS_IPSEC_EXT.1.3).

The evaluator shall examine the TSS to verify that the algorithms supported are described. In addition, the evaluator ensures that the SHA-based HMAC algorithm conforms to the algorithms specified in FCS_COP.1/KeyedHash.

The evaluator shall examine the TSS to verify that IKEv2 is implemented. It may be that this is a configurable option.

The evaluator shall ensure the TSS identifies the algorithms used for encrypting the IKEv2 payload.

If the cryptographic functionality is implemented by the Operational Environment and invoked by the TOE, the evaluator shall examine the TSS to determine that it lists the cryptographic provider for the functionality and the interfaces that are invoked.

The evaluator shall check to ensure that, for each DH group supported, the TSS describes the process for generating "x" (as defined in FCS_IPSEC_EXT.1.). The evaluator shall verify that the TSS indicates that the random number generated that meets the requirements in this PP is used, and that the length of "x" meets the stipulations in the requirement.

The evaluator shall check to ensure that the DH groups specified in the requirement are listed as being supported in the TSS. If there is more than one DH group supported, the evaluator checks to ensure the TSS describes how a particular DH group is specified/negotiated with a peer.

The evaluator shall check that the TSS describes the potential strengths (in terms of the number of bits in the symmetric key) of the algorithms that are allowed for the IKE and ESP exchanges. The TSS shall also describe the checks that are done when negotiating IKEv2 CHILD_SA suites to ensure that the strength (in terms of the number of bits of key in the symmetric algorithm) of the negotiated algorithm is less than or equal to that of the IKE SA that is protecting the negotiation.

The evaluator ensures that the TSS identifies RSA and/or ECDSA as being used to perform peer authentication. The description shall be consistent with the algorithms as specified in FCS_COP.1/Sig Cryptographic Operations (for cryptographic signature).

If pre-shared keys are chosen in the selection, the evaluator shall check to ensure that the TSS describes how pre-shared keys are established and used in authentication of IPsec connections. The evaluator shall check that the operational guidance describes how pre-shared keys are to be generated and established. The description in the TSS and the operational guidance shall also indicate how pre-shared key establishment is accomplished for TOEs that can generate a pre-shared key as well as TOEs that simply use a pre-shared key.

The evaluator shall ensure that the TSS describes how the TOE compares the peer’s presented identifier to the reference identifier. This description shall include whether the certificate presented identifier is compared to the ID payload presented identifier, which field(s) of the certificate are used as the presented identifier (DN, Common Name, or SAN), and, if multiple fields are supported, the logical order comparison. If the ST author assigned an additional identifier type, the TSS description shall also include a description of that type and the method by which that type is compared to the peer’s presented certificate.

Guidance

The evaluator shall examine the operational guidance to verify it instructs the Administrator how to construct entries into the SPD that specify a rule for processing a packet. The description includes both cases – a rule that ensures packets between authorized components are protected and a rule that all other packets are dropped. The evaluator shall determine that the description in the operational guidance is consistent with the description in the TSS, and that the level of detail in the operational guidance is sufficient to allow the administrator to set up the SPD in an unambiguous fashion. This includes a discussion of how ordering of rules impacts the processing of an IP packet.

The evaluator shall confirm that the operational guidance contains instructions on how to configure the connection in each mode selected.

The evaluator checks the operational guidance to ensure it provides instructions on how to configure the TOE/platform to use the algorithms.

The evaluator shall check the operational guidance to ensure it instructs the administrator how to configure the TOE/platform to use IKEv2, and uses the guidance to configure the TOE/platform to perform NAT traversal for the following test (if selected).

The evaluator ensures that the operational guidance describes the configuration of the mandated algorithms, as well as any additional algorithms selected in the requirement. The guidance is then used to configure the TOE/platform to perform the following test for each ciphersuite selected.

The evaluator shall verify that the values for SA lifetimes can be configured and that the instructions for doing so are located in the operational guidance. If time-based limits are supported, the evaluator ensures that the Administrator is able to configure Phase 1 SA values for 24 hours. Currently there are no values mandated for the number of packets or number of bytes, the evaluator just ensures that this can be configured if selected in the requirement.

The evaluator shall verify that the values for SA lifetimes can be configured and that the instructions for doing so are located in the operational guidance. If time-based limits are supported, the evaluator ensures that the Administrator is able to configure Phase 2 SA values for 8 hours. Currently there are no values mandated for the number of packets or number of bytes, the evaluator just ensures that this can be configured if selected in the requirement.

The evaluator ensures the operational guidance describes how to set up the TOE to use certificates with RSA and/or ECDSA signatures and public keys. In order to construct the environment and configure the TOE for the following tests, the evaluator will ensure that the operational guidance describes how to configure the TOE to connect to a trusted CA, and ensure a valid certificate for that CA is loaded into the TOE and marked “trusted”.

The evaluator shall ensure that the operational guidance includes the configuration of the reference identifier(s) for the peer.

Tests

The evaluator uses the operational guidance to configure the TOE to carry out the following tests:

Test FCS_IPSEC_EXT.1:1: The evaluator shall configure the SPD such that there is a rule for dropping a packet, encrypting a packet. The selectors used in the construction of the rule shall be different such that the evaluator can generate a packet and send packets to the gateway with the appropriate fields (fields that are used by the rule - e.g., the IP addresses, TCP/UDP ports) in the packet header. The evaluator performs both positive and negative test cases for each type of rule (e.g., a packet that matches the rule and another that does not match the rule). The evaluator observes via the audit trail, and packet captures that the TOE exhibited the expected behavior: appropriate packets were dropped encrypted by the IPsec implementation.
Test FCS_IPSEC_EXT.1:2: The evaluator shall devise several tests that cover a variety of scenarios for packet processing. As with Test 1, the evaluator ensures both positive and negative test cases are constructed. These scenarios shall exercise the range of possibilities for SPD entries and processing modes as outlined in the TSS and operational guidance. Potential areas to cover include rules with overlapping ranges and conflicting entries, inbound and outbound packets, and packets that establish SAs as well as packets that belong to established SAs. The evaluator shall verify, via the audit trail and packet captures, for each scenario that the expected behavior is exhibited, and is consistent with both the TSS and the operational guidance.

The assurance activity for this element is performed in conjunction with the activities for FCS_IPSEC_EXT.1.1.

The evaluator uses the operational guidance to configure the TOE to carry out the following tests:

Test FCS_IPSEC_EXT.1:3: The evaluator shall configure the SPD such that there is a rule for dropping a packet, encrypting a packet, and allowing a packet to flow in plaintext. The evaluator may use the SPD that was created for verification of FCS_IPSEC_EXT.1.1. The evaluator shall construct a network packet that matches the rule to allow the packet to flow in plaintext and send that packet. The evaluator should observe that the network packet is passed to the proper destination interface with no modification. The evaluator shall then modify a field in the packet header; such that it no longer matches the evaluator-created entries (there may be a “TOE/platform created” final entry that discards packets that do not match any previous entries). The evaluator sends the packet, and observes that the packet was dropped.

The evaluator shall perform the following test(s) based on the selections chosen:

Test FCS_IPSEC_EXT.1:4: (conditional) If tunnel mode is selected, the evaluator uses the operational guidance to configure the TOE/platform to operate in tunnel mode and also configures a VPN peer to operate in tunnel mode. The evaluator configures the TOE/platform and the VPN peer to use any of the allowable cryptographic algorithms, authentication methods, etc. to ensure an allowable SA can be negotiated. The evaluator shall then initiate a connection from the TOE/Platform to the VPN peer. The evaluator observes (for example, in the audit trail and the captured packets) that a successful connection was established using the tunnel mode.
Test FCS_IPSEC_EXT.1:5: The evaluator uses the operational guidance to configure the TOE/platform to operate in transport mode and also configures a VPN peer to operate in transport mode. The evaluator configures the TOE/platform and the VPN peer to use any of the allowed cryptographic algorithms, authentication methods, etc. to ensure an allowable SA can be negotiated. The evaluator then initiates a connection from the TOE/platform to connect to the VPN peer. The evaluator observes (for example, in the audit trail and the captured packets) that a successful connection was established using the transport mode.

The evaluator shall configure the TOE/platform as indicated in the operational guidance configuring the TOE/platform to use the supported algorithms, attempt to establish a connection using ESP, and verify that the attempt succeeds.

Tests are performed in conjunction with the other IPsec evaluation activities with the exception of the activity below:

Test FCS_IPSEC_EXT.1:6: (Conditional) The evaluator shall configure the TOE/platform so that it will perform NAT traversal processing as described in the TSS and RFC 5996, section 2.23. The evaluator shall initiate an IPsec connection and determine that the NAT is successfully traversed.

The evaluator shall configure the TOE/platform to use the ciphersuite under test to encrypt the IKEv1 and/or IKEv2 payload and establish a connection with a peer device, which is configured to only accept the payload encrypted using the indicated ciphersuite. The evaluator will confirm the algorithm was that used in the negotiation.

When testing this functionality, the evaluator needs to ensure that both sides are configured appropriately. From the RFC “A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is responsible for enforcing its own lifetime policy on the SA and rekeying the SA when necessary. If the two ends have different lifetime policies, the end with the shorter lifetime will end up always being the one to request the rekeying. If the two ends have the same lifetime policies, it is possible that both will initiate a rekeying at the same time (which will result in redundant SAs). To reduce the probability of this happening, the timing of rekeying requests SHOULD be jittered.”

Each of the following tests shall be performed:

Test FCS_IPSEC_EXT.1:7: (Conditional) The evaluator shall configure a maximum lifetime in terms of the number of packets (or bytes) allowed following the operational guidance. The evaluator shall configure a test peer with a packet/byte lifetime that exceeds the lifetime of the TOE. The evaluator shall establish an SA between the TOE and the test peer, and determine that once the allowed number of packets (or bytes) through this SA is exceeded, a new SA is negotiated. The evaluator shall verify that the TOE initiates a Phase 1 negotiation.
Test FCS_IPSEC_EXT.1:8: (Conditional) The evaluator shall configure a maximum lifetime of 24 hours for the Phase 1 SA following the operational guidance. The evaluator shall configure a test peer with a lifetime that exceeds the lifetime of the TOE. The evaluator shall establish an SA between the TOE and the test peer, maintain the Phase 1 SA for 24 hours, and determine that once 24 hours has elapsed, a new Phase 1 SA is negotiated. The evaluator shall verify that the TOE initiates a Phase 1 negotiation.

Test FCS_IPSEC_EXT.1:9: (Conditional) The evaluator shall configure a maximum lifetime in terms of the number of packets (or bytes) allowed following the operational guidance. The evaluator shall configure a test peer with a packet/byte lifetime that exceeds the lifetime of the TOE. The evaluator shall establish an SA between the TOE and the test peer, and determine that once the allowed number of packets (or bytes) through this SA is exceeded, a new SA is negotiated. The evaluator shall verify that the TOE initiates a Phase 2 negotiation.
Test FCS_IPSEC_EXT.1:10: (Conditional) The evaluator shall configure a maximum lifetime of 8 hours for the Phase 2 SA following the operational guidance. The evaluator shall configure a test peer with a lifetime that exceeds the lifetime of the TOE. The evaluator shall establish an SA between the TOE and the test peer, maintain the Phase 1 SA for 8 hours, and determine that once 8 hours has elapsed, a new Phase 2 SA is negotiated. The evaluator shall verify that the TOE initiates a Phase 2 negotiation.

Test FCS_IPSEC_EXT.1:11: The evaluator shall check to ensure that, for each PRF hash supported, the TSS describes the process for generating each nonce. The evaluator shall verify that the TSS indicates that the random number generated that meets the requirements in this PP is used, and that the length of the nonces meet the stipulations in the requirement.

For each supported DH group, the evaluator shall test to ensure that all supported IKE protocols can be successfully completed using that particular DH group.

The evaluator follows the guidance to configure the TOE/platform to perform the following tests.

Test FCS_IPSEC_EXT.1:12: The evaluator shall successfully negotiate an IPsec connection using each of the supported algorithms and hash functions identified in the requirements.
Test FCS_IPSEC_EXT.1:13: The evaluator shall attempt to establish an SA for ESP that selects an encryption algorithm with more strength than that being used for the IKE SA (i.e., symmetric algorithm with a key size larger than that being used for the IKE SA). Such attempts should fail.
Test FCS_IPSEC_EXT.1:14: The evaluator shall attempt to establish an IKE SA using an algorithm that is not one of the supported algorithms and hash functions identified in the requirements. Such an attempt should fail.
Test FCS_IPSEC_EXT.1:15: The evaluator shall attempt to establish an SA for ESP (assumes the proper parameters where used to establish the IKE SA) that selects an encryption algorithm that is not identified in FCS_IPSEC_EXT.1.4. Such an attempt should fail.

For efficiency sake, the testing that is performed may be combined with the testing for FIA_X509_EXT.1, FIA_X509_EXT.2 (for IPsec connections), and FCS_IPSEC_EXT.1.1. The following tests shall be repeated for each peer authentication selected in the FCS_IPSEC_EXT.1.1 selection above:

Test FCS_IPSEC_EXT.1:16: The evaluator shall configure the TOE to use a private key and associated certificate signed by a trusted CA and shall establish an IPsec connection with the peer.
Test FCS_IPSEC_EXT.1:17: [conditional] The evaluator shall generate a pre-shared key off-TOE and use it, as indicated in the operational guidance, to establish an IPsec connection with the peer.

The assurance activities for this element are performed in conjunction with the assurance activities for the next element.

For each supported identifier type (excluding DNs), the evaluator shall repeat the following tests:

Test FCS_IPSEC_EXT.1:18: For each field of the certificate supported for comparison, the evaluator shall configure the peer’s reference identifier on the TOE (per the administrative guidance) to match the field in the peer’s presented certificate and shall verify that the IKE authentication succeeds.
Test FCS_IPSEC_EXT.1:19: For each field of the certificate support for comparison, the evaluator shall configure the peer’s reference identifier on the TOE (per the administrative guidance) to not match the field in the peer’s presented certificate and shall verify that the IKE authentication fails.
Test FCS_IPSEC_EXT.1:20: (conditional) If, according to the TSS, the TOE supports both Common Name and SAN certificate fields and uses the preferred logic outlined in the Application Note, the tests above with the Common Name field shall be performed using peer certificates with no SAN extension. Additionally, the evaluator shall configure the peer’s reference identifier on the TOE to not match the SAN in the peer’s presented certificate but to match the Common Name in the peer’s presented certificate, and verify that the IKE authentication fails.
Test FCS_IPSEC_EXT.1:21: (conditional) If the TOE supports DN identifier types, the evaluator shall configure the peer’s reference identifier on the TOE (per the administrative guidance) to match the subject DN in the peer’s presented certificate and shall verify that the IKE authentication succeeds. To demonstrate a bit-wise comparison of the DN, the evaluator shall change a single bit in the DN (preferably, in an Object Identifier (OID) in the DN) and verify that the IKE authentication fails.
Test FCS_IPSEC_EXT.1:22: (conditional) If the TOE supports both IPv4 and IPv6 and supports IP address identifier types, the evaluator must repeat test 1 and 2 with both IPv4 address identifiers and IPv6 identifiers. Additionally, the evaluator shall verify that the TOE verifies that the IP header matches the identifiers by setting the presented identifiers and the reference identifier with the same IP address that differs from the actual IP address of the peer in the IP headers and verifying that the IKE authentication fails.
Test FCS_IPSEC_EXT.1:23: (conditional) If, according to the TSS, the TOE performs comparisons between the peer’s ID payload and the peer’s certificate, the evaluator shall repeat the following test for each combination of supported identifier types and supported certificate fields (as above). The evaluator shall configure the peer to present a different ID payload than the field in the peer’s presented certificate and verify that the TOE fails to authenticate the IKE peer.

FCS_RBG.1 Random Bit Generation (RBG)

The inclusion of this selection-based component depends upon selection in FCS_CDP_EXT.1.1.

FCS_RBG.1.1

The TSF shall [selection: perform, invoke interfaces in the operational environment to perform] deterministic random bit generation services using [selection:

Hash_DRBG (any)
HMAC_DRBG (any)
CTR_DRBG (AES)

] in accordance with [NIST SP 800-90A] after initialization with a seed.

Application Note: NIST SP 800-90A contains three different methods of generating random numbers; each of these, in turn, depends on underlying cryptographic primitives (hash functions/ciphers). The ST author will select the function used and include the specific underlying cryptographic primitives used in the requirement or in the TSS. While any of the identified hash functions (SHA-224, SHA-256, SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based implementations for CTR_DRBG are allowed.

The ST author selects "TSF RBG failure" in FPT_FLS.1 if this component is included in the ST.

FCS_RBG.1.2

The TSF shall use a [selection: TSF noise source [assignment: name of noise source], multiple TSF noise sources [assignment: names of noise sources], TSF interface for seeding] for initialized seeding.

Application Note:

For the selection in this requirement, the ST author selects "TSF noise source" if a single noise source is used as input to the DRBG. The ST author selects "multiple TSF noise sources" if a seed is formed from a combination of two or more noise sources within the TOE boundary. If the TSF implements two or more separate DRBGs that are seeded in separate manners, this SFR should be iterated for each DRBG. If multiple distinct noise sources exist such that each DRBG only uses one of them, then each iteration would select "TSF noise source"; "multiple TSF noise sources" is only selected if a single DRBG uses multiple noise sources for its seed. The ST author selects "TSF interface for seeding" if noise source data is generated outside the TOE boundary.

If "TSF noise source" is selected, FCS_RBG.3 must be claimed.

If "multiple TSF noise sources" is selected, FCS_RBG.4 and FCS_RBG.5 must be claimed.

If "TSF interface for seeding" is selected, FCS_RBG.2 must be claimed.

FCS_RBG.1.3

The TSF shall update the RBG state by [selection: reseeding, uninstantiating and reinstantiating] using a [selection: TSF noise source [assignment: name of noise source], TSF interface for seeding] in the following situations: [selection:

on demand
on the condition: [assignment: condition]
after [assignment: time]

] in accordance with [assignment: list of standards].

Evaluation Activities

FCS_RBG.1.1

TSS

The evaluator shall verify that the TSS identifies the DRBGs used by the TOE.

Guidance

If the DRBG functionality is configurable, the evaluator shall verify that the operational guidance includes instructions on how to configure this behavior.

Tests

The evaluator shall perform the following tests:

The evaluator shall perform 15 trials for the DRBG implementation. If the DRBG is configurable, the evaluator shall perform 15 trials for each configuration. The evaluator shall also confirm that the operational guidance contains appropriate instructions for configuring the DRBG functionality.

If the DRBG has prediction resistance enabled, each trial consists of (1) instantiate DRBG, (2) generate the first block of random bits (3) generate a second block of random bits (4) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The next two are additional input and entropy input for the first call to generate. The final two are additional input and entropy input for the second call to generate. These values are randomly generated. "generate one block of random bits" means to generate random bits with number of returned bits equal to the Output Block Length (as defined in NIST SP 800-90A).

If the DRBG does not have prediction resistance, each trial consists of (1) instantiate DRBG, (2) generate the first block of random bits (3) reseed, (4) generate a second block of random bits (5) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The fifth value is additional input to the first call to generate. The sixth and seventh are additional input and entropy input to the call to reseed. The final value is additional input to the second generate call.

The following list contains more information on some of the input values to be generated/selected by the evaluator.

Entropy input: The length of the entropy input value must equal the seed length.
Nonce: If a nonce is supported (CTR_DRBG with no Derivation Function does not use a nonce), the nonce bit length is one-half the seed length.
Personalization string: The length of the personalization string must be less than or equal to seed length. If the implementation only supports one personalization string length, then the same length can be used for both values. If more than one string length is support, the evaluator shall use personalization strings of two different lengths. If the implementation does not use a personalization string, no value needs to be supplied.
Additional input: The additional input bit lengths have the same defaults and restrictions as the personalization string lengths.

FCS_RBG.1.2

Documentation will be produced - and the evaluator shall perform the activities - in accordance with Appendix D - Entropy Documentation and Assessment appendix and the Clarification to the Entropy Documentation and Assessment Annex.

TSS

There are no additional TSS evaluation activities for this element.

Guidance

There are no additional Guidance evaluation activities for this element.

Tests

There are no test activities for this element.

FCS_RBG.1.3

TSS

The evaluator shall verify that the TSS identifies how the DRBG state is updated, and the situations under which this may occur.

Guidance

If the ST claims that the DRBG state can be updated on demand, the evaluator shall verify that the operational guidance has instructions for how to perform this operation.

Tests

There are no test activities for this element.

FCS_RBG.2 Random Bit Generation (External Seeding)

The inclusion of this selection-based component depends upon selection in FCS_RBG.1.2.

FCS_RBG.2.1

The TSF shall be able to accept a minimum input of [assignment: minimum input length greater than zero] from a TSF interface for the purpose of seeding.

Application Note: This requirement is claimed when a DRBG is seeded with entropy from one or more noise sources that are outside the TOE boundary. Typically the entropy produced by an environmental noise source is conditioned such that the input length has full entropy and is therefore usable as the seed. However, if this is not the case, it should be noted what the minimum entropy rate of the noise source is so that the TSF can collect a sufficiently large sample of noise data to be conditioned into a seed value.

FCS_RBG.3 Random Bit Generation (Internal Seeding - Single Source)

The inclusion of this selection-based component depends upon selection in FCS_RBG.1.2.

FCS_RBG.3.1

The TSF shall be able to seed the RBG using a [selection: TSF software-based noise source, TSF hardware-based noise source] [assignment: name of noise source] with a minimum of [assignment: number of bits] bits of min-entropy.

Application Note: This requirement is claimed when a DRBG is seeded with entropy from a single noise source that is within the TOE boundary. Min-entropy should be expressed as a ratio of entropy bits to sampled bits so that the total amount of data needed to ensure full entropy is known, as well as the conditioning function by which that data is reduced in size to the seed.

FCS_RBG.4 Random Bit Generation (Internal Seeding - Multiple Sources)

The inclusion of this selection-based component depends upon selection in FCS_RBG.1.2.

FCS_RBG.4.1

The TSF shall be able to seed the RBG using [selection: [assignment: number] TSF software-based noise source(s), [assignment: number] TSF hardware-based noise source(s)].

Application Note: This requirement is claimed when a DRBG is seeded with entropy from multiple noise sources that are within the TOE boundary. FCS_RBG.5 defines the mechanism by which these sources are combined to ensure sufficient minimum entropy.

FCS_RBG.5 Random Bit Generation (Combining Noise Sources)

The inclusion of this selection-based component depends upon selection in FCS_RBG.1.2.

FCS_RBG.5.1

The TSF shall [assignment: combining operation] [selection: output from TSF noise source(s), input from TSF interface(s) for seeding] to create the entropy input into the derivation function as defined in [assignment: list of standards], resulting in a minimum of [assignment: number of bits] bits of min-entropy.

Application Note: Examples of typical combining operations include, but are not limited to, XORing or hashing.

B.5 Class: User Data Protection (FDP)

FDP_CRL_EXT.1 Certificate Revocation List Validation

The inclusion of this selection-based component depends upon selection in FIA_UAU_EXT.1.1.

FDP_CRL_EXT.1.1

If the version field is present, then it shall contain a 1.
If the CRL contains any critical extensions, then the version field shall be present and contain the integer 1.
If the issuer field contains a null Name (e.g., a sequence of zero relative distinguished names), then the CRL shall contain a critical issuerAltName extension.
The signature and signatureAlgorithm fields shall contain the OID for a digital signature algorithm in accordance with FCS_COP.1/Sig.
The thisUpdate field shall indicate the issue date of the CRL.
The time specified in the nextUpdate field (if populated) shall not precede the time specified in the thisUpdate field.

Application Note: This SFR must be included in the ST if TODO.

FDP_ITT.1 Basic Internal Transfer Protection

The inclusion of this selection-based component depends upon selection in FIA_UAU_EXT.1.1.

FDP_ITT.1.1

The TSF shall ~~enforce the [assignment: access control SFP(s) and/or information flow control SFP(s)] to~~ prevent the [disclosure, modification] of user data when it is transmitted between physically-separated parts of the TOE

Application Note: It is unclear what the inclusion criteria for this selection-based SFR are. The encoding of this SFR in the XML points to a dummy location in FIA_UAU_EXT.1 but is commented as being wrong. This requirement must be included in the ST if...

To refine this requirement, the phrase “[assignment: access control SFP(s) and/or information flow control SFP(s)] to” was removed and the phrase “through the use of [selection, choose at least one of: IPsec, SSH, TLS, TLS/HTTPS]” was added.

This requirement ensures all communications between components of a distributed TOE is protected through the use of an encrypted communications channel. The data passed in this trusted communication channel are encrypted as defined by the protocol chosen in the first selection. The ST author chooses the mechanism(s) supported by the TOE, and then ensures the detailed requirements in Annex C corresponding to their selection are copied to the ST if not already present.

If SSH is selected, the TOE is expected to conform to the Functional Package for Secure Shell (SSH), version 2.0.

FDP_OCSPG_EXT.1 OCSP Basic Response Generation

The inclusion of this selection-based component depends upon selection in FIA_UAU_EXT.1.1.

FDP_OCSPG_EXT.1.1

This SFR is defined in the X.509 FP (FDP_OCSP_EXT.1). A review of these two versions of the SFRs is needed to determine the appropriate assignments/selections such that the configuration is comparable to its old definitions. Note that the X.509 FP version of the SFR contains more granular requirements for the signature algorithms used to sign responses. The TSF shall ensure that all mandatory fields in the OCSP response contain values in accordance with the standards specified in FDP_CSI_EXT.1. At a minimum, the following items shall be enforced:

The version field shall indicate a current version.
The signatureAlgorithm field shall contain the object identifier (OID) for a digital signature algorithm in accordance with FCS_COP.1/Sig.
The thisUpdate field shall indicate the time at which the status being indicated is known to be correct.
The producedAt field shall indicate the time at which the OCSP responder signed the response.
The time specified in the nextUpdate field (if populated) shall not precede the time specified in the thisUpdate field.

Application Note: This SFR must be included in the ST if TODO.

If RFC 6960 is selected in FCO_NRO_EXT.2.2, the current version is 1 (value 0) and the fields are as named above. If ‘other OCSP standard’ is selected, then the equivalent fields for items a – e above should be identified and the current version should match the specification.

Evaluation Activities

FDP_OCSPG_EXT.1

TSS

The evaluator shall examine the TSS to ensure it indicates whether the TOE supports OCSP and, if so, describes the OCSP response function. Also, the evaluator shall ensure that the TSS identifies which of the values identified in FDP_OCSPG_EXT.1.1 can be included in OCSP responses.

Guidance

There are no additional Guidance evaluation activities for this component.

Tests

If the TOE supports configuration of the OCSP function, the evaluator shall examine the operational guidance to ensure that instructions are available to configure the OCSP response function in accordance with FDP_OCSPG_EXT.1.1.

The evaluator shall perform the following tests:

Test FDP_OCSPG_EXT.1:1: For each OCSP response format identified in FCO_NRO_EXT.2.2, the evaluator shall configure the OCSP response function, establish a client and submit, in turn, an OCSP request to the TSF for the status of a certificate issued by a CA implemented by the TOE and which is not revoked, a certificate issued by a CA implemented by the TOE which has been revoked, and a certificate not issued by a CA implemented by the TOE. The evaluator shall ensure that the responses satisfy all constraints in FDP_OCSPG_EXT.1.1 and reflects the correct status in accordance with the referenced standard.
Test FDP_OCSPG_EXT.1:2: For each OCSP response format defined in FDP_CSI_EXT.1.1, and for each item a-e of this SFR, the evaluator shall attempt to create an OCSP response that violates the required conditions. The evaluator shall determine that all such attempts are rejected by the TSF.

Equivalency Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

B.6 Class: Identification and Authentication (FIA)

FIA_AFL.1 Authentication Failure Handling

The inclusion of this selection-based component depends upon selection in FIA_UAU_EXT.1.1.

FIA_AFL.1.1

The TSF shall to detect when [an administrator configurable positive integer within [assignment: range of acceptable values]] unsuccessful authentication attempts occur related to [remote login by a privileged user].

FIA_AFL.1.2

When the defined number of unsuccessful authentication attempts has been [met], the TSF shall [selection: prevent the remote privileged user from successfully authenticating until [assignment: action] is taken by an Administrator, prevent the privileged user from successfully authenticating until an Administrator defined time period has elapsed].

Application Note: This requirement is applicable only if the TOE provides its own password-based authentication mechanism. Thus it is included in the ST only if "local password-based authentication mechanism" is selected in FIA_UAU_EXT.1.1.

This requirement does not apply to a privileged user at the local console, since it does not make sense to lock a local privileged user’s account in this fashion. This could be addressed by (for example) requiring a separate account for local privileged users or having the authentication mechanism implementation distinguish local and remote login attempts. The “action” taken by an administrator is implementation specific and would be defined in the administrator guidance (for example, lockout reset or password reset). The ST author chooses one of the selections for handling of authentication failures depending on how the TOE has implemented this handler.

Evaluation Activities

FIA_AFL.1

TSS

The evaluator shall examine the TSS to determine that it contains a description, for each supported method for remote administrative actions, of how successive unsuccessful authentication attempts are detected and tracked. The TSS shall also describe the method by which the remote privileged user is prevented from successfully logging on to the TOE, and the actions necessary to restore this ability.

If the Operational Environment is responsible for this function, the evaluator shall verify that the TSS describes that function.

Guidance

The evaluator shall examine the operational guidance to ensure that instructions for configuring the number of successive unsuccessful authentication attempts (1.1) and time period (1.2, if implemented) are provided, and that the process of allowing the remote privileged user to once again successfully log on is described for each “action” specified (if that option is chosen). If different actions or mechanisms are implemented depending on the authentication method (e.g., TLS vs. SSH), all must be described.

If the Operational Environment is responsible for this function, the evaluator shall verify that the operational guidance instructs the reader to rely on this capability.

Tests

The evaluator shall perform the following tests for each method by which remote privileged users access the TOE, either directly or by authenticating to the Operational Environment from which the TOE inherits user information (e.g., TLS, SSH):

Test FIA_AFL.1:1: [conditional on first selection item]: The evaluator shall use the operational guidance to configure the number of successive unsuccessful authentication attempts allowed by the TOE. The evaluator shall test that once the limit is reached, attempts with valid credentials are not successful. For each action specified by the requirement, the evaluator shall show that following the operational guidance and performing each action to allow the remote privileged user access are successful.
Test FIA_AFL.1:2: [conditional on second selection item]: The evaluator shall use the operational guidance to configure the number of successive unsuccessful authentication attempts allowed by the TOE and a time period after which valid logins will be allowed for a remote privileged user. After exceeding the specified number of invalid login attempts and showing that valid login is not possible, the evaluator shall show that waiting for the interval defined by the time period before another access attempt will result in the ability for the remote privileged user to successfully log on using valid credentials.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FIA_CMCC_EXT.1 Certificate Management over CMS (CMC) Client

FIA_CMCC_EXT.1.1

This SFR is defined in the X.509 FP. A review of these two versions of the SFRs is needed to determine the appropriate assignments/selections such that the configuration is comparable to its old definitions. Note that the X.509 version of this SFR lacks an explicit element to require the CA Operations Staff to export requests and import responses. The TSF shall be able to generate CMC full requests and [selection: simple requests, no other requests] and to accept and process CMC simple and CMC full responses in accordance with RFC 5272 as updated by RFC 6402, meeting the compliance requirements for a client and end-entity in accordance with RFC 5474 as updated by RFC 6402.

FIA_CMCC_EXT.1.2

The TSF shall export CMC requests and import CMC responses under the control of a privileged user under the CA Operations Staff role.

FIA_CMCC_EXT.1.3

Application Note: This SFR is included in the ST if TODO.

A CA implemented by the TOE that is not a root CA will need to interface with a root or intermediate CA.

Evaluation Activities

FIA_CMCC_EXT.1

TSS

The evaluator shall examine the TSS to ensure that it describes how CMC client support is provided.

Guidance

If the TSS indicates that neither AuthenticatedData or Identity Proof Version 2 Control mechanisms using shared secretes are supported, the evaluator shall also examine the operational guidance to ensure that it describes how to authenticate requests for subordinate CA certificates, initial subscriber certificates and, if supported, initial certificates for Registration Authority Officers, when no other certificates are available.

Tests

Testing for FIA_CMCC_EXT.1 is performed in conjunction with tests in FIA_CMCS_EXT.1, performing additional test activities as follows:

While completing test 2 for FIA_CMCS_EXT.1 for Test Group A:

Test 2:
- The evaluator shall review the CA-1 TSF’s trust store and observe that the offline CA-0 certificate is trusted.
- The evaluator shall log onto the CA-1 TSF using a privileged user without CA Operations Staff privilege (e.g., with administrator privileges), and attempt to export the request, observing that the attempt fails.
- The evaluator shall examine the certificate request(s) generated on the CA-1 TSF are compliant with with RFC 5272 as updated by RFC 6402 and RFC 5474 as updated by RFC 6402.

After completing tests in Test Group B the evaluator shall perform the following:

Test 5:
- The evaluator shall establish a third instance of the TSF implementing an online CA (CA-2) subordinate to the online CA-1 established for Test Group B in FIA_CMCC_EXT.1.
- For one of the request types indicated in the selection for FIA_CMCC_EXT.1.1 and one of the POP control supported, the evaluator shall log into the CA-2 TSF in the CA Operations Staff role and cause CA-2 to generate CMC request.
- The evaluator shall cause the CA-2 CMC request to be authenticated (using any available mechanism) to CA-1, and install the certificate for the CA using CA-1’s CMC response.
- The evaluator shall cause the CA-2 TSF to generate a valid certificate update request.
- The evaluator shall send the update request to the CA-1 TSF via HTTPS.
- The evaluator shall observe that the CA-2 TSF receives and processes the response from CA-1 and that the updated CA-2 certificate is available for use.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FIA_CMCS_EXT.1 Certificate Management over CMS (CMC) Server

FIA_CMCS_EXT.1.1

This SFR is defined in the X.509 FP. A review of these two versions of the SFRs is needed to determine the appropriate assignments/selections such that the configuration is comparable to its old definitions. Note that the X.509 version of this SFR is more open-ended in several places compared to this SFR (e.g., cryptographic support required per FIA_CMCS_EXT.1.4). The TSF shall be able to accept and process CMC full requests and [selection: simple requests, no other requests].

FIA_CMCS_EXT.1.2

The TSF shall be able to generate CMC simple responses and [selection: CMC full responses, no other] that are consistent with the selected certificate profile and which are in accordance with RFC 5272 as updated by RFC 6402, meeting the compliance requirements for CMS server and certification authorities in accordance with RFC 5474 as updated by RFC 6402.

FIA_CMCS_EXT.1.3

The TSF shall require CMC transport over HTTPS for online CMC messages in accordance with RFC 5273 as updated by RFC 6402, where the HTTPS is established in accordance with FCS_HTTPS_EXT.1. For CMC requests containing certificate requests other than initial certificate requests authenticated using shared secrets in AuthenticatedData requests or in the Identity Proof Version 2 Control of SignedData requests, the TSF shall require HTTPS with client authentication, shall ensure the authenticating entity is the same as the entity signing the CMC request and any subject indicated in the requested certificate(s) are the same as the authenticating entity, or the authenticating entity is [selection: an authorized RA for the requested subject, an AOR registered for the requested subject, no other entity].

FIA_CMCS_EXT.1.4

The TSF shall require CMC simple and full messages use cryptographic support in accordance with this profile. At a minimum the TSF shall ensure:

Signature generation and verification for SignedData are performed in accordance with FCS_COP.1/Sig
Encryption for EnvelopedData is performed in accordance with FCS_COP.1/SKC
PasswordRecipientInfo for EnvelopedData or AuthenticatedData is derived in accordance with FCS_COP.1/PBKDF
hashAlgId in Identity Proof Version 2 control, keyGenAlgorithm in Pop Link Witness Version 2 control, witnessAlgID in Encrypted POP and Decrypted POP controls, hashAlgorithm in Publish Trust Anchors control are in accordance with FCS_COP.1/Hash
macAlgId in Identity Proof Version 2 control, macAlgorithm in POP Link Witness Version 2 Control, and the POPAlgID in Encrypted POP and Decrypted POP controls, are in accordance with FCS_COP.1/KeyedHash
DHPOP mechanisms shall be as specified in RFC 6955 with cryptographic support in accordance with this Protection Profile

FIA_CMCS_EXT.1.5

The TSF shall accept, process and export CMC messages under the control of local privileged user sessions for privileged users with CA Operations Staff, [selection: RA Staff, no other] role.

Application Note: This SFR is selected if TODO.

FIA_CMCS_EXT.1.5 focuses on offline root CAs that do not have direct connection to external IT entities.

In subsequent versions of the PP, the TSF will be required to meet the Suite B profile for CMC as described in RFC 6403.

Evaluation Activities

FIA_CMCS_EXT.1

TSS

The evaluator shall examine the TSS to ensure that it describes how CMC server support is provided.

The evaluator shall examine the TSS to determine how initial requests are authenticated when no certificates are available.

Guidance

The evaluator shall examine the operational guidance to ensure it contains instructions on how to configure CMC processing to support the TOE’s certificate profiles.

If the TSS indicates that neither AuthenticatedData or Identity Proof Version 2 Control mechanisms using shared secretes are supported, the evaluator shall also examine the operational guidance to ensure that it describes how to authenticate requests for subordinate CA certificates, initial subscriber certificates and, if supported, initial certificates for Registration Authority Officers, when no other certificates are available.

Tests

The evaluator shall perform the following tests:

Test Group A. Offline CA Operations:

Test FIA_CMCS_EXT.1:1:
- The evaluator shall establish the TSF in an offline mode to provide an operational root CA, (CA-0) according to AGD-PRE.
- The evaluator shall use a CMC client to generate and export a CMC full request to obtain CA-0’s certificate. The evaluator shall log into the TSF with CA Operations Staff role to submit the request, and observe that the CA-0’s certificate is returned in the response.
- [Conditional on CMC support for shared secrets:] While still logged into the TSF, the evaluator shall establish a username and shared secret to be used to authenticate a subordinate CA (CA-1) for use in Test 2.
- The evaluator shall install the CA’s certificate into the CMC client’s trust store for use in subsequent tests.
Test FIA_CMCS_EXT.1:2:
- The evaluator shall establish a second instance of the TSF to be a subordinate CA (CA-1) to the root CA established in Test 1.
- The evaluator shall log into the CA-1 TSF in the CA Operations Staff role and load the self-signed certificate obtained in Test 1 into the CA-1’s trust store
- The evaluator shall generate certificate request(s):
  - [Conditional on CMC support shared secrets]: The evaluator shall request the CA-1 TSF to generate a CMC requests for the CA-0 TSF to sign its certificate, using the established username as password from test 1 to authenticate the request using CMC AuthenticatedData or Identity Proof Version 2 Control mechanisms,
  - [Conditional on CMC support for shared secrets] The evaluator shall generate two CMC request for certificates on the CMC client using the same authentication mechanism(s) as on the subordinate CA-1 TSF. The first request CMC client shall use the same username established by the CA-0 TSF, but use a modified the shared secret. The second request shall use a modified the username, but use the established shared secret.
  - [Conditional, if the TSF does not provide CMC support for shared secrets:] The evaluator shall follow operational guidance to generate a certificate request for the CA-1 TSF that can be authenticated by manual processes.
Test FIA_CMCS_EXT.1:3:
- The evaluator shall sign into the CA-0 TSF in the CA Operations Staff role and submit in turn the requests generated in Test 2.
- The evaluator shall observe that the CA-0 TSF generates a CMC response containing CA-1’s signed certificate for the correctly authenticated request, and that the root CA certificate repository and audit trail indicates successful generation.
- [Conditional on CMC support for shared secrets:] For each request from the CMC client including modified authentication data, the evaluator shall observe that the CA-0 TSF either generates a full CMC request indicating errors or does not return a request, and that the CA-0 TSF’s audit trail indicates the errors.
Test FIA_CMCS_EXT.1:4: The evaluator shall sign into the subordinate CA in the CA Operations Staff role, import the simple CMC response and complete the initialization of the CA-1 TSF in accordance with OGD-PRE.

Test Group B. Online subordinate CA (uses root and subordinate CA established in offline tests):

Test FIA_CMCS_EXT.1:5:
- [Conditional on CMC support for shared secrets:] The evaluator shall log onto the CA-1 TSF in the CA Operations Staff role and establish a username and shared secret for entities represented by the CMC client established above. A different username and shared secret should be used for at least as many entities are there are request types and POP controls (but at least two).
- For each request type indicated in the selection for FIA_CMCS_EXT.1.1 and for each POP control supported, the evaluator shall use the CMC client to establish a CMC request, using a different identifier (subject name) for each request.
- [Conditional on CMC support for shared secrets:] The evaluator shall log onto the subordinate CA in the CA Operations Staff role and establish a username and shared secret for entities represented by the CMC client established above. A different username and shared secret should be used for at least as many entities are there are request types and POP controls (but at least two).
- For each request type indicated in the selection for FIA_CMCS_EXT.1.1 and for each POP control supported, the evaluator shall use the client to establish a CMC request, using a different identifier (subject name) for each request.
  - [Conditional on CMC support for shared secrets:] The evaluator shall authenticate the requests using the established username/shared secret combinations.
  - [Conditional on TSF not providing CMC support for shared secrets:] The evaluator shall generate certificate requests that can be authenticated via mechanisms described in the OGD.
- The evaluator shall copy each request, and create new requests with modified POP values.
- [Conditional on CMC support for shared secrets:] The evaluator shall establish an HTTPS session without client authentication between the CMC client and the CA-1 TSF, and submit in turn, each of the modified requests, observing that the CA-1 TSF returns full CMC responses indicating POP errors, or does not return responses and the CA-1 TSF’s logs indicate the errors.
- The evaluator shall then submit in turn, each of the unmodified requests under the HTTPS session, provide any required approvals, and observe that the CA-1 TSF returns CMC responses containing signed end-entity certificates, each of which properly chain to the root CA-0 and that the CA-1 TSF’s repository and audit trail indicate successful issuance.
Test FIA_CMCS_EXT.1:6:
- The evaluator shall select one of the client’s certificates and use the CMC client to generate a CMC request for a certificate update, authenticated with the selected certificate.
- The evaluator shall submit the request under the existing, nonauthenticated HTTPS session, and observe that either the CA-1 TSF responds with a full CMC response indicating that the transport is invalid or that no response is provided and the CA-1 TSF’s audit trail indicates the error.
Test FIA_CMCS_EXT.1:7: The evaluator shall establish a new HTTPS session between the CMC client and the CA-1 TSF using client authentication with the selected client certificate (and associated private key) and resubmit the request selected in Test 2, observing that the CA-1 TSF returns a simple CMC response containing a valid certificate for the client. The HTTPS session is retained for Test 4.
Test FIA_CMCS_EXT.1:8: The evaluator shall select a second client certificate, with a different subject name from that used to establish the HTTPS session, and shall generate a CMC request to update that certificate. The evaluator shall observe that the CA-1 TSF returns a full CMC response indicating CMC transport failure or does not respond, and that the CA1 audit trail indicates the error.

Test Group C. Support for Certificate Profiles

Test FIA_CMCS_EXT.1:9: The evaluator shall configure the CA-1 TSF to use a certificate profile requiring extensions not used in Test Groups A or B.
Test FIA_CMCS_EXT.1:10: The evaluator shall select a valid certificate and use the CMC client to generate a CMC request to update the certificate that is otherwise valid, but not populating the required extension, establish an HTTPS session between the client and the CA-1 TSF with client authentication using the selected client certificate and associated private key, and submit the CMC request. The evaluator shall observe that the CA-1 TSF responds in one of the following ways:
- returns a full CMC response rejecting the update indicating a profile error
- returns a simple CMC response containing a certificate meeting the current profile (implicitly rejecting the request without the required extension), or
- does not return a response, and the CA-1 TSF’s audit trail indicates the error,
Test FIA_CMCS_EXT.1:11: The evaluator shall generate another otherwise valid CMC request for the selected certificate, this time populating the extension, but with an invalid value. The evaluator shall submit the request via the proper HTTPS transport and observe that the that the CA-1 TSF responds in one of the following ways:
- returns a full CMC response rejecting the update indicating a profile error
- returns a simple CMC response containing a certificate meeting the current profile (implicitly rejecting the request without the required extension), or
- does not return a response, and the CA-1 TSF’s audit trail indicates the error,
Test FIA_CMCS_EXT.1:12: The evaluator shall generate and submit a valid CMC request including the extension and observe that the subordinate CA returns a simple CMC response with the updated certificate and that the subordinate CA certificate repository and audit trail indicate the successful issuance.

Test Group D. Additional Testing of Controls

Test FIA_CMCS_EXT.1:13: For each required control, the evaluator shall generate and submit an otherwise valid CMC request including a certificate update where the control is missing, or submitted with an invalid value, and observe that the subordinate CA returns a full CMC with the error indicated or does not respond, and that the subordinate CA audit trail indicates the error.

Test Group E. Additional Cryptographic Testing

Test FIA_CMCS_EXT.1:14: For each item in FIA_CMCS_EXT.1.5, the evaluator shall generate and submit an otherwise valid CMC request including a certificate update where the item uses an invalid cryptographic mechanism, and observe that the subordinate CA returns a full CMC indicating the failure or does not respond, and that the subordinate CA audit trail indicates the error.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FIA_ESTC_EXT.1 Enrollment over Secure Transport (EST) Client

FIA_ESTC_EXT.1.1

This SFR is defined in the X.509 FP. A review of these two versions of the SFRs is needed to determine the appropriate assignments/selections such that the configuration is comparable to its old definitions. Note that the X.509 version of this SFR does not contain requirements to validate EST servers per FCS_TLSC_EXT.2 in FIA_ESTC_EXT.1.4. It additionally contains a requirement to be able to update its EST-specific Trust Anchor Database per a specific process in RFC 7030. The TSF shall use the Enrollment over Secure Transport (EST) as specified in RFC 7030 to obtain its CA certificate and [assignment: other certificates for the TOE] from an EST server associated to an external certification authority certification authority (external CA) to which a CA implemented by the TSF is subordinate.

FIA_ESTC_EXT.1.2

The TSF shall be able to obtain EST server and CA certificates for authorized EST services via [selection:

implicit TA database configured by an [selection: administrator, CA operations staff]
an explicit TA database populated via a TLS-authenticated EST CA certificate request in accordance with RFC 7030 section 4.1.2 and FCS_TLSC_EXT.2 (as defined in the Functional Package for Transport Layer Security (TLS), version 2.0)

FIA_ESTC_EXT.1.3

The TSF shall authenticate EST servers using X.509 certificates that chain to trust store elements from the [selection: implicit TA database, explicit TA database] in accordance with FIA_X.509_EXT.1/Rev for all EST requests.

FIA_ESTC_EXT.1.4

The TSF shall authenticate its certificate enrollment requests to receive the signing certificate for CA implemented by the TOE, and [assignment: other certificates required to authenticate the TOE] , from an authorized EST server using [selection:

HTTP basic authentication transported over TLS in accordance with RFC 7030 section 3.2.3 and FCS_TLSC_EXT.2 (as defined in the Functional Package for Transport Layer Security (TLS), version 2.0).
HTTP digest authentication using a cryptographic hash algorithm in accordance with FCS_COP.1/HASH, transported over TLS in accordance with RFC 7030 section 3.2.3 and FCS_TLSC_EXT.2 (as defined in the Functional Package for Transport Layer Security (TLS), version 2.0).
Certificate-based authentication in accordance with RFC 7030 section 3.3.2 and FCS_TLSC_EXT.2 (as defined in the Functional Package for Transport Layer Security (TLS), version 2.0) using [assignment: a pre-existing certificate authorized by the EST server]

FIA_ESTC_EXT.1.5

The TSF shall generate authenticated re-enrollment requests in accordance with RFC 7030 Section 3.3.2 and FCS_TLSC_EXT, using an existing valid certificate with the same subject name as the requested certificate and which was issued by the external CA.

Application Note: This SFR must be included in the ST is TODO.

A CA used as an intermediate certification authority in a PKI will need to make requests to external CAs to which it is subordinate. It is acceptable to use EST to generate these requests.

The third choice in the selection for FIA_ESTC_EXT.1.4 is selected if a pre-existing certificate exists. The assignment should specify whether this pre-existing certificate is established by the vendor, or installed by a privileged user.

Evaluation Activities

FIA_ESTC_EXT.1

TSS

The evaluator shall examine the TSS to ensure it describes the implementation of this protocol, the certificates obtained, and any pre-existing certificates or trust anchor databases used by the protocol.

Guidance

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 examine the operational guidance to ensure it contains instructions for obtaining or configuring the TA database (implicit or explicit) and any required initial certificates.

Tests

The evaluator shall perform the following tests:

Test FIA_ESTC_EXT.1:1: The evaluator shall establish an external CA and EST server, and configure the TOE as indicated in the AGD to authorize the EST server for EST services using the external CA. The evaluator shall examine the TOE logs and TA database(s) using available interfaces to ensure the EST server and external CA’s certificates are authorized for EST services.
Test FIA_ESTC_EXT.1:2: For each authentication method specified in FIA_ESTC_EXT.1.4, the evaluator shall generate one or more certificate enrollment requests using the authentication method to obtain TOE required certificates from the authorized CA via the EST server established in Test 1. In accordance with guidance documentation, the evaluator shall obtain all required certificates in aggregate to allow the TOE to operate a CA.
Test FIA_ESTC_EXT.1:3: The evaluator shall make a valid request for a certificate to be issued by the CA certificate obtained in test 2, and confirm that the certificate received from the TOE is signed by the TOE’s CA certificate issued by the external CA.
Test FIA_ESTC_EXT.1:4: The evaluator shall generate a re-enrollment request and submit it to the authorized EST server in accordance with FIA_ESTC_EXT.1 to update the CA’s signing certificate the same CA implemented by the TOE used in Test 3. The evaluator shall make a valid request for a certificate from that CA, and observe that the new CA certificate signs the returned certificate.
Test FIA_ESTC_EXT.1:5: The evaluator shall establish a second EST server configured to authorize the TOE’s EST client but which not authorized by the client to provide EST services. The evaluator shall generate an enrollment request for the TOE’s embedded CA signing certificate, and submit it to the second EST server. The evaluator shall repeat Test 3, observing that the certificate returned by the second EST server is not listed as the issuer of certificate chain returned.

Equivalency Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FIA_ESTS_EXT.1 Enrollment over Secure Transport (EST) Server

FIA_ESTS_EXT.1.1

FIA_ESTS_EXT.1.2

The TSF shall authenticate EST clients for initial enrollment and for supplemental authentication via [selection:

HTTP basic authentication in accordance with RFC7030 section 3.2.3;
HTTP digest authentication using a cryptographic hash algorithm in accordance with FCS_COP.1/Hash and RFC 7030 section 3.2.3;
TLS certificate-based mutual authentication in accordance with RFC 7030 section 3.3.2 and FCS_TLSS_EXT.1 (as defined in the Functional Package for Transport Layer Security (TLS), version 2.0).

FIA_ESTS_EXT.1.3

The TSF shall authorize EST clients based on [selection: the authenticated client certificate is issued by the same issuer that asserts id-kp-cmcRA in its extended key usage extension as specified by RFC 7030 Section 3.7, [assignment: policy used by the TOE to determine client authorization in accordance with RFC 7030 section 3.7].

Application Note: Enrollment over Secure Transport (EST) uses the simple Certificate Request Message as specified in RFC 7030. EST also uses HTTPS as specified in FCS_HTTPS_EXT.1 to establish a secure connection with an EST client.

This SFR is included in the ST if TODO. If this requirement is included in the ST, the ST author includes FCS_TLSS_EXT.1 (as defined in the Functional Package for Transport Layer Security (TLS), version 2.0).

For FIA_ESTS_EXT.1.3, the ST author selects the method used to authenticate clients for initial enrollment, or in cases where supplemental authentication is required. If the second item is chosen in the selection, the ST author includes FCS_COP.1/Hash in the ST.

For FIA_ESTS_EXT.1.4, the ST author should specify how the TOE determines a client is authorized if the request does not have the id-kp-cmcRA EKU included in its certificate. The assignment requires that this method be compliant with the requirements in RFC 7030, section 3.7.

If only the third item is chosen in the selection for FIA_ESTS_EXT.1.3, or if the first item is chosen in the selection for FIA_ESTS_EXT.1.4, then support of an RA or AOR is required for initial authentication and SFR selections associated to the support for these optional roles must be claimed.

Evaluation Activities

FIA_ESTS_EXT.1

TSS

The evaluator shall examine the TSS to ensure it describes the implementation of this protocol. If the description indicates the use or RA or AOR for initial issuance or authorization of certificates, the evaluator shall examine the TSS to ensure that these roles are supported.

Guidance

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.

Tests

The evaluator shall perform the following tests:

Test FIA_ESTS_EXT.1:1: 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.
Test FIA_ESTS_EXT.1:2: 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.
Test FIA_ESTS_EXT.1:3: If “a certificate issued by the same issuer that asserts id-kpcmcRA 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 Certification Authority functionality that asserts id-kpcmcRA in its extended key usage extension. The evaluator shall confirm that the TOE issues a certificate and returns it to the client.
Test FIA_ESTS_EXT.1:4: If “a certificate issued by the same issuer that asserts id-kpcmcRA 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-kpcmcRA in its extended key usage extension and which is not associated with RA or AOR privileges by the CA. The evaluator shall confirm that the TOE does not issue a certificate.
Test FIA_ESTS_EXT.1:5: The evaluator shall modify the EST client or setup a man-in-the-middle tool between the EST client and TOE to perform the and modify a valid certificate request by modifying at least one byte in the certificationRequestInfo field of the certificate request message and verify that the TOE rejects the request.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FIA_PMG_EXT.1 Password Management

The inclusion of this selection-based component depends upon selection in FIA_UAU_EXT.1.1.

FIA_PMG_EXT.1.1

The TSF shall provide the following password management capabilities for privileged passwords:

Passwords shall be able to be composed of any combination of upper and lower case letters, numbers, and the following special characters: [selection: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(”, “)”, [assignment: other characters]];
Minimum password length shall be settable by the Administrator, and support passwords of 14 characters or greater.

FIA_PSK_EXT.1 Pre-Shared Key Composition

The inclusion of this selection-based component depends upon selection in FCS_IPSEC_EXT.1.13.

FIA_PSK_EXT.1.1

The TSF shall be able to use pre-shared keys for IPsec.

Application Note: The TOE may need to support pre-shared keys for use in the IPsec protocol (if it does, “Pre-shared Keys” will be selected as a peer authentication method in FCS_IPSEC_EXT.1.13). There are two types of pre-shared keys: text-based (which are required) and bit-based (which are optional)—supported by the TOE, as specified in the requirements below. The first type is referred to as “text-based pre-shared keys”, which refer to pre-shared keys that are entered by users as a string of characters from a standard character set, similar to a password. Such pre-shared keys must be conditioned so that the string of characters is transformed into a string of bits, which is then used as the key.

The second type is referred to as “bit-based pre-shared keys” (for lack of a standard term); this refers to keys that are either generated by the TSF on a command from the administrator, or input in "direct form" by an administrator. "Direct form" means that the input is used directly as the key, with no "conditioning" as was the case for text-based pre-shared keys. An example would be a string of hex digits that represent the bits that comprise the key.

The requirements below mandate that the TOE must support text-based pre-shared keys and optionally support bit-based pre-shared keys, although generation of the bit-based pre-shared keys may be done either by the TOE or in the operational environment.

FIA_PSK_EXT.1.2

The TSF shall be able to accept text-based pre-shared keys that:

are 22 characters and [selection: [assignment: other supported lengths], no other lengths];
composed of any combination of upper and lower case letters, numbers, and special characters (that include: "!", "@", "#", "$", "%", "^", "&", "*", "(", and ")").

FIA_PSK_EXT.1.3

The TSF shall condition the text-based pre-shared keys by using [selection: SHA1, SHA-256, SHA-512, [assignment: method of conditioning text string]] and be able to [selection: use no other pre-shared keys, accept bit-based pre-shared keys, generate bit-based pre-shared keys using the random bit generator specified in FCS_RBG_EXT.1].

Application Note: For the length of the text-based pre-shared keys, a common length (22 characters) is required to help promote interoperability. If other lengths are supported they should be listed in the assignment; this assignment can also specify a range of values (e.g., "lengths from 5 to 55 characters") as well.

In the second selection for FIA_PSK_EXT.1.3, the ST author fills in the method by which the text string entered by the administrator is “conditioned” into the bit string used as the key. This can be done by using one of the specified hash functions, or some other method through the assignment statement. If “bit-based pre-shared keys” is selected, the ST author specifies whether the TSF merely accepts bit-based pre-shared keys, or is capable of generating them. If it generates them, the requirement specified that they must be generated using the RBG specified by the requirements. If the use of bit-based pre-shared keys is not supported, the ST author chooses “use no other pre-shared keys”.

Evaluation Activities

FIA_PSK_EXT.1

TSS

The evaluator shall examine the TSS to ensure that it states that text-based preshared keys of 22 characters are supported, and that the TSS states the conditioning that takes place to transform the text-based pre-shared key from the key sequence entered by the user (e.g., ASCII representation) to the bit string used by IPsec, and that this conditioning is consistent with the first selection in the FIA_PSK_EXT.1.3 requirement. If the assignment is used to specify conditioning, the evaluator will confirm that the TSS describes this conditioning.

Guidance

The evaluator shall examine the operational guidance to determine that it provides guidance on the composition of strong text-based pre-shared keys, and (if the selection indicates keys of various lengths can be entered) that it provides information on the merits of shorter or longer pre-shared keys. The guidance must specify the allowable characters for pre-shared keys, and that list must be a super-set of the list contained in FIA_PSK_EXT.1.2.

If “bit-based pre-shared keys” is selected, the evaluator shall confirm the operational guidance contains instructions for either entering bit-based preshared keys for each protocol identified in the requirement, or generating a bit-based pre-shared key (or both). The evaluator shall also examine the TSS to ensure it describes the process by which the bit-based pre-shared keys are generated (if the TOE supports this functionality), and confirm that this process uses the RBG specified in FCS_RBG_EXT.1.

Tests

The evaluator shall perform the following tests:

Test FIA_PSK_EXT.1:1: The evaluator shall compose at least 15 pre-shared keys of 22 characters that cover all allowed characters in various combinations that conform to the operational guidance, and demonstrates that a successful protocol negotiation can be performed with each key.
Test FIA_PSK_EXT.1:2: [conditional]: If the TOE supports pre-shared keys of multiple lengths, the evaluator shall repeat Test 1 using the minimum length; the maximum length; and an invalid length. The minimum and maximum length tests should be successful, and the invalid length must be rejected by the TOE.
Test FIA_PSK_EXT.1:3: [conditional]: If the TOE supports bit-based pre-shared keys but does not generate such keys, the evaluator shall obtain a bit-based pre-shared key of the appropriate length and enter it according to the instructions in the operational guidance. The evaluator shall then demonstrate that a successful protocol negotiation can be performed with the key.
Test FIA_PSK_EXT.1:4: [conditional]: If the TOE supports bit-based pre-shared keys and does generate such keys, the evaluator shall generate a bit-based pre-shared key of the appropriate length and use it according to the instructions in the operational guidance. The evaluator shall then demonstrate that a successful protocol negotiation can be performed with the key.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FIA_UAU.7 Protected Authentication Feedback

The inclusion of this selection-based component depends upon selection in FIA_UAU_EXT.1.1.

FIA_UAU.7.1

The TSF shall provide only [obscured feedback and [assignment: list of other feedback]] to the user while the authentication is in progress.

FIA_X509_EXT.3 X509 Certificate Request

The inclusion of this selection-based component depends upon selection in FIA_UAU_EXT.1.1.

FIA_X509_EXT.3.1

This SFR is defined in the X.509 FP. A review of these two versions of the SFRs is needed to determine the appropriate assignments/selections such that the configuration is comparable to its old definitions. Note that the X.509 FP version of this SFR includes support for alternate request mechanisms as compared to this SFR. The TSF shall generate a Certificate Request Message as specified by RFC 2986 and be able to provide the following information in the request: public key, CA's distinguished name, [assignment: other information describing the CA implemented by the TOE].

Application Note: The public key is the public key portion of the public-private key pair generated by the TOE as specified in FCS_CKM.1. The CA distinguished name and any additional information shall be configurable by a CA Operations Staff role.

FIA_X509_EXT.3.2

The TSF shall validate the chain of certificates from the Root CA upon receiving the CA Certificate Response.

Application Note: This SFR must be included in the ST if TODO.

B.7 Class: Protection of the TSF (FPT)

FPT_APW_EXT.1 Protection of Privileged User Password

The inclusion of this selection-based component depends upon selection in FIA_UAU_EXT.1.1.

FPT_APW_EXT.1.1

The TSF shall store passwords in non-plaintext form.

FPT_APW_EXT.1.2

The TSF shall prevent the reading of plaintext passwords.

Application Note: This requirement is applicable only if the TOE provides its own password-based authentication mechanism. Thus it is included in the ST only if "local password-based authentication mechanism" is selected in FIA_UAU_EXT.1.1.

The intent of the requirement is that raw password authentication data are not stored in the clear, and that no user or administrator is able to read the plaintext password through “normal” interfaces. An all-powerful administrator of course could directly read memory to capture a password but is trusted not to do so.

In this version of the PP there are no requirements on the method used to store the passwords in non-plaintext form, but cryptographic methods based on the requirements in FCS_COP are preferred. In future versions of this PP, FCS_COP-based cryptographic methods that conform to the Level 2 Credential Storage requirements from NIST SP 800-63 will be required.

FPT_ITT.1 Basic Internal TSF Data Transfer Protection

The inclusion of this selection-based component depends upon selection in FIA_UAU_EXT.1.1.

FPT_ITT.1.1

The TSF shall protect TSF data from [disclosure, modification] when it is transmitted between separate parts of the TOE

Application Note: It is unclear what the inclusion criteria for this selection-based SFR are. The encoding of this SFR in the XML points to a dummy location in FIA_UAU_EXT.1 but is commented as being wrong. This SFR must be included in the ST if ...

This requirement ensures all communications between components of a distributed TOE is protected through the use of an encrypted communications channel. The data passed in this trusted communication channel are encrypted as defined the protocol chosen in the first selection. The ST author chooses the mechanism(s) supported by the TOE, and then ensures the detailed requirements in Annex B corresponding to their selection are copied to the ST if not already present.

If SSH is selected, the TOE is expected to conform to the Functional Package for Secure Shell (SSH), version 2.0.

FPT_SKY_EXT.2 Key Share Access

The inclusion of this selection-based component depends upon selection in FIA_UAU_EXT.1.1.

FPT_SKY_EXT.2.1

The [selection: TSF, Operational Environment] shall ensure that key shares generated in accordance with FCS_CKM_EXT.1/SHARE are accessible only to privileged users, and that each share is only accessible to a single privileged user as configured by an Administrator.

Application Note: This SFR shall be included if “key sharing mechanisms in accordance with FCS_CKM_EXT.1/KEKT, FCS_CKM_EXT.1/SHARE, FCS_CKM_EXT.6, and FPT_SKY_EXT.2” is selected in FPT_SKY_EXT.1.1/CA or FPT_SKY_EXT.1.1/OTH. It should be noted that this protection can be accomplished via FCS_COP.1/PBKDF; if it is, then that SFR should be included in the ST.

FPT_TST.1 TSF Self-Testing

The inclusion of this selection-based component depends upon selection in FCS_CDP_EXT.1.1.

FPT_TST.1.1

The TSF shall run a suite of the following self-tests [selection: during initial start-up, periodically during normal operation, at the request of the authorized user, at the conditions [assignment: conditions under which self-test should occur]] to demonstrate the correct operation of [TSF DRBG specified in FCS_RBG.1].

FPT_TST.1.2

The TSF shall provide authorized users with the capability to verify the integrity of [[DRBG seed/output data]].

FPT_TST.1.3

The TSF shall provide authorized users with the capability to verify the integrity of [[TSF DRBG specified in FCS_RBG.1]].

Application Note: This SFR is a required dependency of FCS_RBG.1. It is intended to require that any DRBG implemented by the TOE undergo health testing to ensure that the random bit generation functionality has not been degraded. If the TSF supports multiple DRBGs, this SFR should be iterated to describe the self-test behavior for each.

B.8 Class: Trusted Path/Channels (FTP)

FTP_ITC.1 Inter-TSF Trusted Channel

The inclusion of this selection-based component depends upon selection in FIA_UAU_EXT.1.1.

FTP_ITC.1.1

The TSF shall provide a communication channel between itself and that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure.

FTP_ITC.1.2

The TSF shall permit [the TSF, the authorized IT entities] to initiate communication via the trusted channel.

FTP_ITC.1.3

The TSF shall initiate communication via the trusted channel for [assignment: list of services for which the TSF is able to initiate communications].

Application Note: It is unclear what the inclusion criteria for this selection-based SFR are. The encoding of this SFR in the XML points to a dummy location in FIA_UAU_EXT.1 but is commented as being wrong. This SFR must be included in the SFR if TODO.

The intent of the above requirement is to use a cryptographic protocol to protect external communications with authorized IT entities that the TOE interacts with to perform its functions. While there are no requirements on the party initiating the communication, the ST author lists in the assignment for FTP_ITC.1.3 the services for which the TOE can initiate the communication with the authorized IT entity (it is acceptable to assign “no services” for FTP_ITC.1.3 if the TOE does not initiate any of the covered connections). Note that SSH is not included because this protocol is not used by the TSF to connect to other components. If the ST author selects SSH, the TSF shall be validated against the Functional Package for Secure Shell (SSH), version 2.0. If the ST author selects TLS, the TSF shall be validated against the Functional Package for Transport Layer Security (TLS), version 2.0.

The requirement implies that not only are communications protected when they are initially established, but also on resumption after an interruption. It may be the case that some part of the TOE setup involves manually setting up tunnels to protect other communication, and if after an interruption the TOE attempts to reestablish the communication automatically with (the necessary) manual intervention, there may be a window created where an attacker might be able to gain critical information or compromise a connection.

Evaluation Activities

FTP_ITC.1

TSS

The evaluator shall examine the TSS to determine that, for all communications with authorized IT entities identified in the requirement, each communications mechanism is identified in terms of the allowed protocols for that IT entity. The evaluator shall also confirm that all protocols listed in the TSS are specified and included in the requirements in the ST.

If an external cryptographic module is selected in FTP_ITC.1.1, the evaluator shall examine the TSS to ensure it describes how the external module is used for cryptographic operations versus how any locally provided cryptographic functionality is used.

Guidance

The evaluator shall examine the operational guidance to ensure it contains instructions for establishing the allowed protocols with each authorized IT entity, and that it contains recovery instructions should a connection be interrupted.

Tests

The evaluator shall perform the following tests:

Test FTP_ITC.1:1: The evaluator shall ensure that communications using each protocol with each authorized IT entity is tested during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring that communication is successful.
Test FTP_ITC.1:2: For each protocol that the TOE can initiate as defined in the requirement, the evaluator shall follow the operational guidance to ensure that in fact the communication channel can be initiated from the TOE.
Test FTP_ITC.1:3: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data is not sent in plaintext.
Test FTP_ITC.1:4: The evaluator shall, for each protocol associated with each authorized IT entity tested during test 1, cause an interruption to the connection. The evaluator shall ensure that when connectivity is restored, communications are appropriately protected.

Further assurance activities are associated with the specific protocols.

Equivalency Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

Appendix C - Extended Component Definitions

This appendix contains the definitions for all extended requirements specified in the PP.

C.1 Extended Components Table

All extended components specified in the PP are listed in this table:

**Table 9: Extended Component Definitions**
Functional Class	Functional Components
Class: Communications (FCO)	FCO_NRO_EXT Certificate-Based Proof of Origin FCO_NRR_EXT Certificate-Based Proof of Receipt
Class: Cryptographic Support (FCS)	FCS_CDP_EXT Cryptographic Dependencies FCS_CKM_EXT Cryptographic Key Management FCS_HTTPS_EXT HTTPS Protocol FCS_IPSEC_EXT IPsec Protocol FCS_KSH_EXT Key Sharing FCS_STG_EXT Cryptographic Key Storage
Class: Identification and Authentication (FIA)	FIA_CMCC_EXT Certificate Management over CMS Client FIA_CMCS_EXT Certificate Management over CMS Server FIA_ENR_EXT Certificate Enrollment FIA_ESTC_EXT Enrollment over Secure Transport Client FIA_ESTS_EXT Enrollment over Secure Transport Server FIA_PMG_EXT Password Management FIA_PSK_EXT Pre-Shared Key Composition FIA_UAU_EXT Authentication Mechanism FIA_UIA_EXT User Identification and Authentication
Class: Protection of the TSF (FPT)	FPT_APW_EXT Protection of User Password FPT_KST_EXT No Plaintext Key Export FPT_NPE_EXT NPE Constraints FPT_SKP_EXT Protection of Keys FPT_SKY_EXT Split Knowledge Procedures FPT_TST_EXT TOE Testing FPT_TUD_EXT Trusted Update
Class: Security Audit (FAU)	FAU_ADP_EXT Audit Dependencies FAU_GCR_EXT Generation of Certificate Repository FAU_SCR_EXT Certificate Repository Review
Class: TOE Access (FTA)	FTA_SSL_EXT TSF-Initiated Session Locking
Class: User Data Protection (FDP)	FDP_CER_EXT Certificate Generation FDP_CRL_EXT Certificate Revocation Lists FDP_CSI_EXT Certificate Status Information FDP_OCSPG_EXT OCSP Response Generation FDP_SDP_EXT Sensitive Data Protection FDP_STG_EXT Sensitive Data Storage

C.2 Extended Component Definitions

C.2.1 Class: Communications (FCO)

This PP defines the following extended components as part of the FCO class originally defined by CC Part 2:

C.2.1.1 FCO_NRO_EXT Certificate-Based Proof of Origin

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FCO_NRO_EXT.2, Certificate-Based Proof of Origin, requires a conformant TOE to TODO: QQQQQ

Management: FCO_NRO_EXT.2

TODO: QQQQQ

Audit: FCO_NRO_EXT.2

TODO: QQQQQ

FCO_NRO_EXT.2 Certificate-Based Proof of Origin

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FCO_NRO_EXT.2.1

The TSF shall provide proof of origin for certificates it issues in accordance with the digital signature requirements using a mechanism in accordance with RFC 5280 and FCS_COP.1/Sig.

FCO_NRO_EXT.2.2

FCO_NRO_EXT.2.3

FCO_NRO_EXT.2.4

FCO_NRO_EXT.2.5

The TSF shall [selection:

require and verify proof of origin for revocation requests it receives via [selection: CMC using mechanisms in accordance with FIA_CMCS_EXT.1, EST using optional “full CMC” functionality in accordance with FIA_ESTS_EXT.1]
[assignment: support manual processes for revocation requests and responses]

C.2.1.2 FCO_NRR_EXT Certificate-Based Proof of Receipt

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FCO_NRR_EXT.2, Certificate-Based Proof of Receipt, requires a conformant TOE to TODO: QQQQQ

Management: FCO_NRR_EXT.2

TODO: QQQQQ

Audit: FCO_NRR_EXT.2

TODO: QQQQQ

FCO_NRR_EXT.2 Certificate-Based Proof of Receipt

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FCO_NRR_EXT.2.1

The TSF shall provide proof of receipt for [selection: CMC, EST] by providing signed responses using mechanisms in accordance with [selection: FIA_CMCS_EXT.1, FIA_ESTS_EXT.1].

C.2.2 Class: Cryptographic Support (FCS)

This PP defines the following extended components as part of the FCS class originally defined by CC Part 2:

C.2.2.1 FCS_CDP_EXT Cryptographic Dependencies

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FCS_CDP_EXT.1, Cryptographic Dependencies, requires a conformant TOE to TODO: QQQQQ

Management: FCS_CDP_EXT.1

TODO: QQQQQ

Audit: FCS_CDP_EXT.1

TODO: QQQQQ

FCS_CDP_EXT.1 Cryptographic Dependencies

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FCS_CDP_EXT.1.1

C.2.2.2 FCS_CKM_EXT Cryptographic Key Management

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FCS_CKM_EXT.1, Symmetric Key Generation, requires a conformant TOE to TODO: QQQQQ

FCS_CKM_EXT.5, Public Key Integrity, requires a conformant TOE to TODO: QQQQQ

FCS_CKM_EXT.6, Key Archival, requires a conformant TOE to TODO: QQQQQ

FCS_CKM_EXT.7, Key Generation for KEKs, requires a conformant TOE to TODO: QQQQQ

Management: FCS_CKM_EXT.1

TODO: QQQQQ

Audit: FCS_CKM_EXT.1

TODO: QQQQQ

FCS_CKM_EXT.1 Symmetric Key Generation

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

Management: FCS_CKM_EXT.5

TODO: QQQQQ

Audit: FCS_CKM_EXT.5

TODO: QQQQQ

FCS_CKM_EXT.5 Public Key Integrity

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FCS_CKM_EXT.5.1

FCS_CKM_EXT.5.2

The [selection: digital signature, keyed hash] used to protect a public key shall be verified upon each access to the key.

Management: FCS_CKM_EXT.6

TODO: QQQQQ

Audit: FCS_CKM_EXT.6

TODO: QQQQQ

FCS_CKM_EXT.6 Key Archival

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FCS_CKM_EXT.6.1

FCS_CKM_EXT.6.2

The TSF shall [selection: be able to, invoke interfaces in the Operational Environment to be able to] export the protected keys (in FCS_CKM_EXT.6.1) for the purpose of archival in encrypted form.

FCS_CKM_EXT.6.3

FCS_CKM_EXT.6.4

FCS_CKM_EXT.6.5

Management: FCS_CKM_EXT.7

TODO: QQQQQ

Audit: FCS_CKM_EXT.7

TODO: QQQQQ

FCS_CKM_EXT.7 Key Generation for KEKs

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FCS_CKM_EXT.7.1

The [selection: TSF, Operational environment] shall support a hardware protected REK generated in accordance with FCS_CKM_EXT.1.1/KEK.

FCS_CKM_EXT.7.2

A REK shall not be able to be read from or exported from the hardware.

FCS_CKM_EXT.7.3

The TSF shall be able only to request encryption/decryption by the key and shall not be able to read, import, or export a REK.

FCS_CKM_EXT.7.4

A REK shall be generated [selection: by a RBG in accordance with FCS_RBG_EXT.1, according to FCS_CKM.1].

C.2.2.3 FCS_HTTPS_EXT HTTPS Protocol

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FCS_HTTPS_EXT.1, HTTPS Protocol, requires a conformant TOE to TODO: QQQQQ

Management: FCS_HTTPS_EXT.1

TODO: QQQQQ

Audit: FCS_HTTPS_EXT.1

TODO: QQQQQ

FCS_HTTPS_EXT.1 HTTPS Protocol

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FCS_HTTPS_EXT.1.1

The TSF shall implement the HTTPS protocol that complies with RFC 2818.

FCS_HTTPS_EXT.1.2

The TSF shall implement HTTPS using TLS.

C.2.2.4 FCS_IPSEC_EXT IPsec Protocol

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FCS_IPSEC_EXT.1, IPsec Protocol, requires a conformant TOE to TODO: QQQQQ

Management: FCS_IPSEC_EXT.1

TODO: QQQQQ

Audit: FCS_IPSEC_EXT.1

TODO: QQQQQ

FCS_IPSEC_EXT.1 IPsec Protocol

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FCS_IPSEC_EXT.1.1

The TSF shall implement IPsec to protect communication among TSF components and between TSF and OE components as specified in RFC 4301 and discard unauthorized communication.

FCS_IPSEC_EXT.1.2

The TSF shall have a nominal, final entry in the SPD that matches anything that is otherwise unmatched, and discards it.

FCS_IPSEC_EXT.1.3

The TSF shall implement transport mode and [selection: tunnel mode, no other mode].

FCS_IPSEC_EXT.1.4

FCS_IPSEC_EXT.1.5

FCS_IPSEC_EXT.1.6

The TSF shall ensure the encrypted payload in the IKEv2 protocol uses the cryptographic algorithms AES-GCM-256 as specified in RFC 5282.

FCS_IPSEC_EXT.1.7

The TSF shall ensure that IKEv2] SA lifetimes can be configured by an Administrator based on [selection:

number of packets/bytes;
length of time, where the time values can be configured within [assignment: integer range including 24] hours.

]

FCS_IPSEC_EXT.1.8

The TSF shall ensure that [IKEv2] Child SA lifetimes can be configured by an Administrator based on [selection:

number of packets/bytes;
length of time, where the time values can be configured within [assignment: integer range including 8] hours

FCS_IPSEC_EXT.1.9

FCS_IPSEC_EXT.1.10

The TSF shall generate nonce used in [IKEv2] exchanges of length [at least 128 bits in size and at least half the output size of the negotiated pseudorandom function (PRF) hash].

FCS_IPSEC_EXT.1.11

The TSF shall ensure that all IKE protocols implement [selection: DH Group 20 (384-bit Random ECP), no other DH groups].

FCS_IPSEC_EXT.1.12

FCS_IPSEC_EXT.1.13

FCS_IPSEC_EXT.1.14

FCS_IPSEC_EXT.1.15

The TSF shall not establish an SA if the presented identifier does not match the configured reference identifier of the peer.

C.2.2.5 FCS_KSH_EXT Key Sharing

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FCS_KSH_EXT.1, Key Sharing, requires a conformant TOE to TODO: QQQQQ

Management: FCS_KSH_EXT.1

TODO: QQQQQ

Audit: FCS_KSH_EXT.1

TODO: QQQQQ

FCS_KSH_EXT.1 Key Sharing

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FCS_KSH_EXT.1.1

C.2.2.6 FCS_STG_EXT Cryptographic Key Storage

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FCS_STG_EXT.1, Cryptographic Key Storage, requires a conformant TOE to TODO: QQQQQ

Management: FCS_STG_EXT.1

TODO: QQQQQ

Audit: FCS_STG_EXT.1

TODO: QQQQQ

FCS_STG_EXT.1 Cryptographic Key Storage

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FCS_STG_EXT.1.1

Persistent private and secret keys shall be stored within the [selection: TSF, Operational environment] [selection:

encrypted within a hardware rooted key hierarchy established in accordance with [selection: FCS_CKM_EXT.1/KEK, FCS_CKM_EXT.1/KEKT], FCS_CKM_EXT.7, and FCS_CKM_EXT.8
in a hardware cryptographic module

C.2.3 Class: Identification and Authentication (FIA)

This PP defines the following extended components as part of the FIA class originally defined by CC Part 2:

C.2.3.1 FIA_CMCC_EXT Certificate Management over CMS Client

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FIA_CMCC_EXT.1, Certificate Management over CMS (CMC) Client, requires a conformant TOE to TODO: QQQQQ

Management: FIA_CMCC_EXT.1

TODO: QQQQQ

Audit: FIA_CMCC_EXT.1

TODO: QQQQQ

FIA_CMCC_EXT.1 Certificate Management over CMS (CMC) Client

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FIA_CMCC_EXT.1.1

This SFR is defined in the X.509 FP. A review of these two versions of the SFRs is needed to determine the appropriate assignments/selections such that the configuration is comparable to its old definitions. Note that the X.509 version of this SFR lacks an explicit element to require the CA Operations Staff to export requests and import responses. The TSF shall be able to generate CMC full requests and [selection: simple requests, no other requests] and to accept and process CMC simple and CMC full responses in accordance with RFC 5272 as updated by RFC 6402, meeting the compliance requirements for a client and end-entity in accordance with RFC 5474 as updated by RFC 6402.

FIA_CMCC_EXT.1.2

The TSF shall export CMC requests and import CMC responses under the control of a privileged user under the CA Operations Staff role.

FIA_CMCC_EXT.1.3

C.2.3.2 FIA_CMCS_EXT Certificate Management over CMS Server

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FIA_CMCS_EXT.1, Certificate Management over CMS (CMC) Server, requires a conformant TOE to TODO: QQQQQ

Management: FIA_CMCS_EXT.1

TODO: QQQQQ

Audit: FIA_CMCS_EXT.1

TODO: QQQQQ

FIA_CMCS_EXT.1 Certificate Management over CMS (CMC) Server

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FIA_CMCS_EXT.1.1

This SFR is defined in the X.509 FP. A review of these two versions of the SFRs is needed to determine the appropriate assignments/selections such that the configuration is comparable to its old definitions. Note that the X.509 version of this SFR is more open-ended in several places compared to this SFR (e.g., cryptographic support required per FIA_CMCS_EXT.1.4). The TSF shall be able to accept and process CMC full requests and [selection: simple requests, no other requests].

FIA_CMCS_EXT.1.2

FIA_CMCS_EXT.1.3

FIA_CMCS_EXT.1.4

The TSF shall require CMC simple and full messages use cryptographic support in accordance with this profile. At a minimum the TSF shall ensure:

Signature generation and verification for SignedData are performed in accordance with FCS_COP.1/Sig
Encryption for EnvelopedData is performed in accordance with FCS_COP.1/SKC
PasswordRecipientInfo for EnvelopedData or AuthenticatedData is derived in accordance with FCS_COP.1/PBKDF
hashAlgId in Identity Proof Version 2 control, keyGenAlgorithm in Pop Link Witness Version 2 control, witnessAlgID in Encrypted POP and Decrypted POP controls, hashAlgorithm in Publish Trust Anchors control are in accordance with FCS_COP.1/Hash
macAlgId in Identity Proof Version 2 control, macAlgorithm in POP Link Witness Version 2 Control, and the POPAlgID in Encrypted POP and Decrypted POP controls, are in accordance with FCS_COP.1/KeyedHash
DHPOP mechanisms shall be as specified in RFC 6955 with cryptographic support in accordance with this Protection Profile

FIA_CMCS_EXT.1.5

The TSF shall accept, process and export CMC messages under the control of local privileged user sessions for privileged users with CA Operations Staff, [selection: RA Staff, no other] role.

C.2.3.3 FIA_ENR_EXT Certificate Enrollment

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FIA_ENR_EXT.1, Certificate Enrollment, requires a conformant TOE to TODO: QQQQQ

Management: FIA_ENR_EXT.1

TODO: QQQQQ

Audit: FIA_ENR_EXT.1

TODO: QQQQQ

FIA_ENR_EXT.1 Certificate Enrollment

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FIA_ENR_EXT.1.1

PKCS#10 in accordance with FIA_X509_EXT.3
Enrollment over Secure Transport (EST) in accordance with FIA_ESTC_EXT.1
Certificate Management over CMM in accordance with FIA_CMCC_EXT.1

]

C.2.3.4 FIA_ESTC_EXT Enrollment over Secure Transport Client

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FIA_ESTC_EXT.1, Enrollment over Secure Transport (EST) Client, requires a conformant TOE to TODO: QQQQQ

FIA_ESTC_EXT.2, EST Client use of TLS-unique value, requires a conformant TOE to TODO: QQQQQ

Management: FIA_ESTC_EXT.1

TODO: QQQQQ

Audit: FIA_ESTC_EXT.1

TODO: QQQQQ

FIA_ESTC_EXT.1 Enrollment over Secure Transport (EST) Client

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FIA_ESTC_EXT.1.1

This SFR is defined in the X.509 FP. A review of these two versions of the SFRs is needed to determine the appropriate assignments/selections such that the configuration is comparable to its old definitions. Note that the X.509 version of this SFR does not contain requirements to validate EST servers per FCS_TLSC_EXT.2 in FIA_ESTC_EXT.1.4. It additionally contains a requirement to be able to update its EST-specific Trust Anchor Database per a specific process in RFC 7030. The TSF shall use the Enrollment over Secure Transport (EST) as specified in RFC 7030 to obtain its CA certificate and [assignment: other certificates for the TOE] from an EST server associated to an external certification authority certification authority (external CA) to which a CA implemented by the TSF is subordinate.

FIA_ESTC_EXT.1.2

The TSF shall be able to obtain EST server and CA certificates for authorized EST services via [selection:

implicit TA database configured by an [selection: administrator, CA operations staff]
an explicit TA database populated via a TLS-authenticated EST CA certificate request in accordance with RFC 7030 section 4.1.2 and FCS_TLSC_EXT.2 (as defined in the Functional Package for Transport Layer Security (TLS), version 2.0)

FIA_ESTC_EXT.1.3

FIA_ESTC_EXT.1.4

HTTP basic authentication transported over TLS in accordance with RFC 7030 section 3.2.3 and FCS_TLSC_EXT.2 (as defined in the Functional Package for Transport Layer Security (TLS), version 2.0).
HTTP digest authentication using a cryptographic hash algorithm in accordance with FCS_COP.1/HASH, transported over TLS in accordance with RFC 7030 section 3.2.3 and FCS_TLSC_EXT.2 (as defined in the Functional Package for Transport Layer Security (TLS), version 2.0).
Certificate-based authentication in accordance with RFC 7030 section 3.3.2 and FCS_TLSC_EXT.2 (as defined in the Functional Package for Transport Layer Security (TLS), version 2.0) using [assignment: a pre-existing certificate authorized by the EST server]

FIA_ESTC_EXT.1.5

Management: FIA_ESTC_EXT.2

TODO: QQQQQ

Audit: FIA_ESTC_EXT.2

TODO: QQQQQ

FIA_ESTC_EXT.2 EST Client use of TLS-unique value

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FIA_ESTC_EXT.2.1

C.2.3.5 FIA_ESTS_EXT Enrollment over Secure Transport Server

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FIA_ESTS_EXT.1, Enrollment over Secure Transport (EST) Server, requires a conformant TOE to TODO: QQQQQ

FIA_ESTS_EXT.2, Enrollment over Secure Transport (EST) Server, requires a conformant TOE to TODO: QQQQQ

Management: FIA_ESTS_EXT.1

TODO: QQQQQ

Audit: FIA_ESTS_EXT.1

TODO: QQQQQ

FIA_ESTS_EXT.1 Enrollment over Secure Transport (EST) Server

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FIA_ESTS_EXT.1.1

FIA_ESTS_EXT.1.2

The TSF shall authenticate EST clients for initial enrollment and for supplemental authentication via [selection:

HTTP basic authentication in accordance with RFC7030 section 3.2.3;
HTTP digest authentication using a cryptographic hash algorithm in accordance with FCS_COP.1/Hash and RFC 7030 section 3.2.3;
TLS certificate-based mutual authentication in accordance with RFC 7030 section 3.3.2 and FCS_TLSS_EXT.1 (as defined in the Functional Package for Transport Layer Security (TLS), version 2.0).

FIA_ESTS_EXT.1.3

Management: FIA_ESTS_EXT.2

TODO: QQQQQ

Audit: FIA_ESTS_EXT.2

TODO: QQQQQ

FIA_ESTS_EXT.2 Enrollment over Secure Transport (EST) Server

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FIA_ESTS_EXT.2.1

C.2.3.6 FIA_PMG_EXT Password Management

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FIA_PMG_EXT.1, Password Management, requires a conformant TOE to TODO: QQQQQ

Management: FIA_PMG_EXT.1

TODO: QQQQQ

Audit: FIA_PMG_EXT.1

TODO: QQQQQ

FIA_PMG_EXT.1 Password Management

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FIA_PMG_EXT.1.1

The TSF shall provide the following password management capabilities for privileged passwords:

Passwords shall be able to be composed of any combination of upper and lower case letters, numbers, and the following special characters: [selection: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(”, “)”, [assignment: other characters]];
Minimum password length shall be settable by the Administrator, and support passwords of 14 characters or greater.

C.2.3.7 FIA_PSK_EXT Pre-Shared Key Composition

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FIA_PSK_EXT.1, Pre-Shared Key Composition, requires a conformant TOE to TODO: QQQQQ

Management: FIA_PSK_EXT.1

TODO: QQQQQ

Audit: FIA_PSK_EXT.1

TODO: QQQQQ

FIA_PSK_EXT.1 Pre-Shared Key Composition

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FIA_PSK_EXT.1.1

The TSF shall be able to use pre-shared keys for IPsec.

FIA_PSK_EXT.1.2

The TSF shall be able to accept text-based pre-shared keys that:

are 22 characters and [selection: [assignment: other supported lengths], no other lengths];
composed of any combination of upper and lower case letters, numbers, and special characters (that include: "!", "@", "#", "$", "%", "^", "&", "*", "(", and ")").

FIA_PSK_EXT.1.3

C.2.3.8 FIA_UAU_EXT Authentication Mechanism

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FIA_UAU_EXT.1, Authentication Mechanism, requires a conformant TOE to TODO: QQQQQ

Management: FIA_UAU_EXT.1

TODO: QQQQQ

Audit: FIA_UAU_EXT.1

TODO: QQQQQ

FIA_UAU_EXT.1 Authentication Mechanism

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FIA_UAU_EXT.1.1

C.2.3.9 FIA_UIA_EXT User Identification and Authentication

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FIA_UIA_EXT.1, User Identification and Authentication, requires a conformant TOE to TODO: QQQQQ

Management: FIA_UIA_EXT.1

TODO: QQQQQ

Audit: FIA_UIA_EXT.1

TODO: QQQQQ

FIA_UIA_EXT.1 User Identification and Authentication

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FIA_UIA_EXT.1.1

The TSF shall allow the following actions prior to requiring a non-TOE entity to initiate the identification and authentication process:

Display the warning banner in accordance with FTA_TAB.1;
Obtain certificate status information;
[selection: download certificate from repository, no other actions, [assignment: list of services or actions performed by the TSF in response to non-TOE entity request]]

FIA_UIA_EXT.1.2

FIA_UIA_EXT.1.3

C.2.4 Class: Protection of the TSF (FPT)

This PP defines the following extended components as part of the FPT class originally defined by CC Part 2:

C.2.4.1 FPT_APW_EXT Protection of User Password

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FPT_APW_EXT.1, Protection of Privileged User Password, requires a conformant TOE to TODO: QQQQQ

Management: FPT_APW_EXT.1

TODO: QQQQQ

Audit: FPT_APW_EXT.1

TODO: QQQQQ

FPT_APW_EXT.1 Protection of Privileged User Password

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FPT_APW_EXT.1.1

The TSF shall store passwords in non-plaintext form.

FPT_APW_EXT.1.2

The TSF shall prevent the reading of plaintext passwords.

C.2.4.2 FPT_KST_EXT No Plaintext Key Export

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FPT_KST_EXT.1, No Plaintext Key Export, requires a conformant TOE to TODO: QQQQQ

Management: FPT_KST_EXT.1

TODO: QQQQQ

Audit: FPT_KST_EXT.1

TODO: QQQQQ

FPT_KST_EXT.1 No Plaintext Key Export

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FPT_KST_EXT.1.1

The TSF and [selection: Operational Environment, no other component] shall prevent the plaintext export of [assignment: list of all keys used by the TSF].

C.2.4.3 FPT_NPE_EXT NPE Constraints

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FPT_NPE_EXT.1, NPE Constraints, requires a conformant TOE to TODO: QQQQQ

Management: FPT_NPE_EXT.1

TODO: QQQQQ

Audit: FPT_NPE_EXT.1

TODO: QQQQQ

FPT_NPE_EXT.1 NPE Constraints

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FPT_NPE_EXT.1.1

The TSF shall enforce an Administrator-configurable ruleset that specifies authorizations to submit NPE certificate requests.

FPT_NPE_EXT.1.2

C.2.4.4 FPT_SKP_EXT Protection of Keys

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FPT_SKP_EXT.1, Protection of Keys, requires a conformant TOE to TODO: QQQQQ

Management: FPT_SKP_EXT.1

TODO: QQQQQ

Audit: FPT_SKP_EXT.1

TODO: QQQQQ

FPT_SKP_EXT.1 Protection of Keys

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FPT_SKP_EXT.1.1

C.2.4.5 FPT_SKY_EXT Split Knowledge Procedures

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FPT_SKY_EXT.1, Split Knowledge Procedures, requires a conformant TOE to TODO: QQQQQ

FPT_SKY_EXT.2, Key Share Access, requires a conformant TOE to TODO: QQQQQ

Management: FPT_SKY_EXT.1

TODO: QQQQQ

Audit: FPT_SKY_EXT.1

TODO: QQQQQ

FPT_SKY_EXT.1 Split Knowledge Procedures

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

Management: FPT_SKY_EXT.2

TODO: QQQQQ

Audit: FPT_SKY_EXT.2

TODO: QQQQQ

FPT_SKY_EXT.2 Key Share Access

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FPT_SKY_EXT.2.1

C.2.4.6 FPT_TST_EXT TOE Testing

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FPT_TST_EXT.1, TOE Integrity Test, requires a conformant TOE to TODO: QQQQQ

FPT_TST_EXT.2, Integrity Test, requires a conformant TOE to TODO: QQQQQ

Management: FPT_TST_EXT.1

TODO: QQQQQ

Audit: FPT_TST_EXT.1

TODO: QQQQQ

FPT_TST_EXT.1 TOE Integrity Test

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FPT_TST_EXT.1.1

FPT_TST_EXT.1.2

The [selection: TSF, Operational Environment] shall verify the integrity of the TOE software and firmware [selection: at power-up, at initialization, on-demand by a privileged user].

Management: FPT_TST_EXT.2

TODO: QQQQQ

Audit: FPT_TST_EXT.2

TODO: QQQQQ

FPT_TST_EXT.2 Integrity Test

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FPT_TST_EXT.2.1

FPT_TST_EXT.2.2

Integrity shall be verified at [selection: power-up, initialization, on-demand by a privileged user].

C.2.4.7 FPT_TUD_EXT Trusted Update

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FPT_TUD_EXT.1, Trusted Update, requires a conformant TOE to TODO: QQQQQ

Management: FPT_TUD_EXT.1

TODO: QQQQQ

Audit: FPT_TUD_EXT.1

TODO: QQQQQ

FPT_TUD_EXT.1 Trusted Update

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FPT_TUD_EXT.1.1

The TSF shall [selection: implement, interface with the Operational Environment to implement] the ability to check for updates and patches to the TOE.

FPT_TUD_EXT.1.2

The TSF shall [selection: implement, interface with the Operational Environment to implement] the ability to provide Administrators the ability to initiate updates to TOE firmware/software.

FPT_TUD_EXT.1.3

FPT_TUD_EXT.1.4

C.2.5 Class: Security Audit (FAU)

This PP defines the following extended components as part of the FAU class originally defined by CC Part 2:

C.2.5.1 FAU_ADP_EXT Audit Dependencies

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FAU_ADP_EXT.1, Audit Dependencies, requires a conformant TOE to TODO: QQQQQ

Management: FAU_ADP_EXT.1

TODO: QQQQQ

Audit: FAU_ADP_EXT.1

TODO: QQQQQ

FAU_ADP_EXT.1 Audit Dependencies

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FAU_ADP_EXT.1.1

C.2.5.2 FAU_GCR_EXT Generation of Certificate Repository

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FAU_GCR_EXT.1, Generation of Certificate Repository, requires a conformant TOE to TODO: QQQQQ

Management: FAU_GCR_EXT.1

TODO: QQQQQ

Audit: FAU_GCR_EXT.1

TODO: QQQQQ

FAU_GCR_EXT.1 Generation of Certificate Repository

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FAU_GCR_EXT.1.1

The TSF shall [selection: store, invoke the Operational Environment to store] certificates and [selection: CRLs, no other information] issued by the TSF.

C.2.5.3 FAU_SCR_EXT Certificate Repository Review

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FAU_SCR_EXT.1, Certificate Repository Review, requires a conformant TOE to TODO: QQQQQ

Management: FAU_SCR_EXT.1

TODO: QQQQQ

Audit: FAU_SCR_EXT.1

TODO: QQQQQ

FAU_SCR_EXT.1 Certificate Repository Review

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FAU_SCR_EXT.1.1

subject name
individual components of subject alternative name
subject ID
issuer ID
algorithm ID
public key
key usage
extended key usage
serial number
[assignment: list of other certificate fields]

], returning all matching certificates and [assignment: object identifier(s) of matching certificate(s)].

C.2.6 Class: TOE Access (FTA)

This PP defines the following extended components as part of the FTA class originally defined by CC Part 2:

C.2.6.1 FTA_SSL_EXT TSF-Initiated Session Locking

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FTA_SSL_EXT.1, TSF-Initiated Session Locking, requires a conformant TOE to TODO: QQQQQ

Management: FTA_SSL_EXT.1

TODO: QQQQQ

Audit: FTA_SSL_EXT.1

TODO: QQQQQ

FTA_SSL_EXT.1 TSF-Initiated Session Locking

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FTA_SSL_EXT.1.1

The TSF shall, for local interactive sessions, [selection:

lock the session–- disable any activity of the user’s data access/display devices other than unlocking the session, and requiring that the privileged user reauthenticate to the TSF prior to unlocking the session;
terminate the session

] after an Administrator-configured time period of inactivity.

C.2.7 Class: User Data Protection (FDP)

This PP defines the following extended components as part of the FDP class originally defined by CC Part 2:

C.2.7.1 FDP_CER_EXT Certificate Generation

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FDP_CER_EXT.1, Certificate Profiles, requires a conformant TOE to TODO: QQQQQ

FDP_CER_EXT.2, Certificate Request Matching, requires a conformant TOE to TODO: QQQQQ

FDP_CER_EXT.3, Certificate Issuance Approval, requires a conformant TOE to TODO: QQQQQ

FDP_CER_EXT.4, Certificate Status Information, requires a conformant TOE to TODO: QQQQQ

Management: FDP_CER_EXT.1

TODO: QQQQQ

Audit: FDP_CER_EXT.1

TODO: QQQQQ

FDP_CER_EXT.1 Certificate Profiles

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FDP_CER_EXT.1.1

This SFR is defined in the X.509 FP. A review of these two versions of the SFRs is needed to determine the appropriate assignments/selections such that the configuration is comparable to its old definitions. The TSF shall implement a certificate profile function and shall ensure that issued certificates are consistent with configured profiles.

FDP_CER_EXT.1.2

The version field shall contain the integer 2.
The issuerUniqueID or subjectUniqueID fields are not populated.
The serialNumber shall be unique with respect to the issuing Certification Authority
The validity field shall specify a notBefore value that does not precede the current time and a notAfter value that does not precede the value specified in notBefore.
The issuer field is not empty.
The signature field and the algorithm in the subjectPublicKeyInfo field shall contain the OID for a signature algorithm specified in FCS_COP.1/Sig.
The following extensions are supported:
1. subjectKeyIdentifier
2. authorityKeyIdentifier
3. basicConstraints
4. keyUsage
5. extendedKeyUsage
6. certificatePolicy
A subject field containing a null Name (e.g., a sequence of zero relative distinguished names) is accompanied by a populated critical subjectAltName extension.
The subjectKeyIdentifier extension is populated with a value unique for each public key contained in a certificate issued by the TSF.
The authorityKeyIdentifier extension in any certificate issued by the TOE must be populated and must be the same as the subjectKeyIdentifier extension contained in the issuer’s signing certificate.
Populated keyUsage and extendedKeyUsage fields in the same certificate contain consistent values.

FDP_CER_EXT.1.3

Management: FDP_CER_EXT.2

TODO: QQQQQ

Audit: FDP_CER_EXT.2

TODO: QQQQQ

FDP_CER_EXT.2 Certificate Request Matching

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FDP_CER_EXT.2.1

This SFR is defined in the X.509 FP. A review of these two versions of the SFRs is needed to determine the appropriate assignments/selections such that the configuration is comparable to its old definitions. Note that the X.509 FP version of this SFR goes into substantially more detail than this version. The TSF shall establish a linkage from certificate requests to issued certificates.

Management: FDP_CER_EXT.3

TODO: QQQQQ

Audit: FDP_CER_EXT.3

TODO: QQQQQ

FDP_CER_EXT.3 Certificate Issuance Approval

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FDP_CER_EXT.3.1

The TSF shall support the approval of certificates by [selection: RA, AOR, CA, Operations Staff, rules] issued according to a configured certificate profile.

Management: FDP_CER_EXT.4

TODO: QQQQQ

Audit: FDP_CER_EXT.4

TODO: QQQQQ

FDP_CER_EXT.4 Certificate Status Information

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FDP_CER_EXT.4.1

For X.509 certificate formats other than v3, the TSF shall ensure that these certificate formats contain the following general characteristics:

Version (0 or 1);
Unique identifier of the issuer;
keyUsage;
Unique identifier of the certificate
Validity period
Signature field in accordance with FCS_COP.1/Sig

C.2.7.2 FDP_CRL_EXT Certificate Revocation Lists

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FDP_CRL_EXT.1, Certificate Revocation List Validation, requires a conformant TOE to TODO: QQQQQ

Management: FDP_CRL_EXT.1

TODO: QQQQQ

Audit: FDP_CRL_EXT.1

TODO: QQQQQ

FDP_CRL_EXT.1 Certificate Revocation List Validation

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FDP_CRL_EXT.1.1

If the version field is present, then it shall contain a 1.
If the CRL contains any critical extensions, then the version field shall be present and contain the integer 1.
If the issuer field contains a null Name (e.g., a sequence of zero relative distinguished names), then the CRL shall contain a critical issuerAltName extension.
The signature and signatureAlgorithm fields shall contain the OID for a digital signature algorithm in accordance with FCS_COP.1/Sig.
The thisUpdate field shall indicate the issue date of the CRL.
The time specified in the nextUpdate field (if populated) shall not precede the time specified in the thisUpdate field.

C.2.7.3 FDP_CSI_EXT Certificate Status Information

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FDP_CSI_EXT.1, Certificate Status Information, requires a conformant TOE to TODO: QQQQQ

Management: FDP_CSI_EXT.1

TODO: QQQQQ

Audit: FDP_CSI_EXT.1

TODO: QQQQQ

FDP_CSI_EXT.1 Certificate Status Information

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FDP_CSI_EXT.1.1

This SFR is defined in the X.509 FP. A review of these two versions of the SFRs is needed to determine the appropriate assignments/selections such that the configuration is comparable to its old definitions. Note that the X.509 FP version of this SFR contains an additional element compared to this version. The TSF shall provide certificate status information whose format complies with [selection:

ITU-T Recommendation X.509v1 CRL
ITU-T Recommendation X.509v2 CRL
the OCSP standard as defined by [selection: RFC 6960, other OCSP standard]

FDP_CSI_EXT.1.2

The TSF shall support the approval of changes to the status of a certificate by [selection: RA, CA operations staff, rules].

C.2.7.4 FDP_OCSPG_EXT OCSP Response Generation

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FDP_OCSPG_EXT.1, OCSP Basic Response Generation, requires a conformant TOE to TODO: QQQQQ

Management: FDP_OCSPG_EXT.1

TODO: QQQQQ

Audit: FDP_OCSPG_EXT.1

TODO: QQQQQ

FDP_OCSPG_EXT.1 OCSP Basic Response Generation

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FDP_OCSPG_EXT.1.1

The version field shall indicate a current version.
The signatureAlgorithm field shall contain the object identifier (OID) for a digital signature algorithm in accordance with FCS_COP.1/Sig.
The thisUpdate field shall indicate the time at which the status being indicated is known to be correct.
The producedAt field shall indicate the time at which the OCSP responder signed the response.
The time specified in the nextUpdate field (if populated) shall not precede the time specified in the thisUpdate field.

C.2.7.5 FDP_SDP_EXT Sensitive Data Protection

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FDP_SDP_EXT.1, User Sensitive Data Protection, requires a conformant TOE to TODO: QQQQQ

Management: FDP_SDP_EXT.1

TODO: QQQQQ

Audit: FDP_SDP_EXT.1

TODO: QQQQQ

FDP_SDP_EXT.1 User Sensitive Data Protection

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FDP_SDP_EXT.1.1

The TSF shall [selection: protect, invoke interfaces to the Operational Environment to protect] [selection:

subscriber identity information
subscriber contact information
photograph from official ID such as an organization ID badge, passport or driver’s license,
background check information
copies of legal documents
captured biometrics
[assignment: other personally identifiable information]

] through encryption in accordance with FCS_COP.1/SKC using a DEK.

FDP_SDP_EXT.1.2

by clearing the DEK encrypting the protected data,
in accordance with the following rules:

For volatile EEPROM the destruction shall be executed by a single direct overwrite consisting of [selection:
- a pseudo random pattern using the TSF’s RBG (as specified in FCS_RBG_EXT.1),
- zeroes
] followed by a read-verify.
h:br/> For volatile flash memory the destruction shall be executed by [selection:
- a single direct overwrite consisting of zeroes,
- a block erase
] followed by a read-verify.

]

C.2.7.6 FDP_STG_EXT Sensitive Data Storage

Family Behavior

Components in this family TODO: QQQQQ

Component Leveling

FDP_STG_EXT.1, User Sensitive Data Protection, requires a conformant TOE to TODO: QQQQQ

Management: FDP_STG_EXT.1

TODO: QQQQQ

Audit: FDP_STG_EXT.1

TODO: QQQQQ

FDP_STG_EXT.1 User Sensitive Data Protection

Hierarchical to:	No other components.
Dependencies to:	TODO: QQQQQ

FDP_STG_EXT.1.1

Appendix D - Entropy Documentation and Assessment

The documentation of the entropy source should be detailed enough that, after reading, the evaluator will thoroughly understand the entropy source and why it can be relied upon to provide entropy. This documentation should include multiple detailed sections: design description, entropy justification, operating conditions, and health testing. This documentation is not required to be part of the TSS.

Design Description

Documentation shall include the design of the entropy source as a whole, including the interaction of all entropy source components. It will describe the operation of the entropy source to include how it works, how entropy is produced, and how unprocessed (raw) data can be obtained from within the entropy source for testing purposes. The documentation should walk through the entropy source design indicating where the random comes from, where it is passed next, any post-processing of the raw outputs (hash, XOR, etc.), if/where it is stored, and finally, how it is output from the entropy source. Any conditions placed on the process (e.g., blocking) should also be described in the entropy source design. Diagrams and examples are encouraged.

This design must also include a description of the content of the security boundary of the entropy source and a description of how the security boundary ensures that an adversary outside the boundary cannot affect the entropy rate.

Entropy Justification

There should be a technical argument for where the unpredictability in the source comes from and why there is confidence in the entropy source exhibiting probabilistic behavior (an explanation of the probability distribution and justification for that distribution given the particular source is one way to describe this). This argument will include a description of the expected entropy rate and explain how you ensure that sufficient entropy is going into the TOE randomizer seeding process. This discussion will be part of a justification for why the entropy source can be relied upon to produce bits with entropy. Operating Conditions

Documentation will also include the range of operating conditions under which the entropy source is expected to generate random data. It will clearly describe the measures that have been taken in the system design to ensure the entropy source continues to operate under those conditions. Similarly, documentation shall describe the conditions under which the entropy source is known to malfunction or become inconsistent. Methods used to detect failure or degradation of the source shall be included.

Health testing

More specifically, all entropy source health tests and their rationale will be documented. This will include a description of the health tests, the rate and conditions under which each health test is performed (e.g., at startup, continuously, or on-demand), the expected results for each health test, and rationale indicating why each test is believed to be appropriate for detecting one or more failures in the entropy source.

Appendix E - Acronyms

Table 10: Acronyms
Acronym	Meaning
AES	Advanced Encryption Standard
AOR	Authorized Organizational Representative
API	Application Programming Interface
Base-PP	Base Protection Profile
CA	Certification Authority
CBC	Cipher Block Chaining
CC	Common Criteria
CC	Common Criteria
CCM	Counter with CBC-Message Authentication Code
CCMP	CCM Protocol
CCTL	Common Criteria Test Lab
CEM	Common Evaluation Methodology
CESG	Communications-Electronics Security Group
CMC	Certificate Management over CMS
CMS	Cryptographic Message Syntax
CN	Common Names
cPP	Collaborative Protection Profile
CRL	Certificate Revocation List
CSA	Computer Security Act
CSP	Critical Security Parameter
CSS	Certificate Status Server
DAR	Data At Rest
DEK	Data Encryption Key
DES	Data Encryption Standard
DH	Diffie-Hellman
DHE	Diffie-Hellman Key Exchange
DKM	Derived Keying Material
DNS	Domain Name System
DRBG	Deterministic Random Bit Generator
DSA	Digital Signature Algorithm
DSS	Digital Signature Standard
DT	Date/Time Vector
DTLS	Datagram Transport Layer Security
EAP	Extensible Authentication Protocol
ECC	Elliptic Curve Cryptography
ECDHE	Elliptic Curve Diffie-Hellman Ephemeral
ECDSA	Elliptic Curve Digital Signature Algorithm
EDC	Error detection code
EEPROM	Electrically Erasable Programmable Read-Only Memory
ESP	Encapsulating Security Payload (IPsec)
EST	Enrollment over Secure Transport
FFC	Finite-Field Cryptography
FIPS	Federal Information Processing Standards
FP	Functional Package
GCM	Galois/Counter Mode
HMAC	Hash-based Message Authentication Code
HSM	Hardware Security Module
HTTP	Hypertext Transfer Protocol
HTTPS	Hypertext Transfer Protocol Secure
I and A	Identification and Authentication
IETF	Internet Engineering Task Force
IKE	Internet key Exchange
IP	Internet Protocol
IPsec	Internet Protocol Security
ISO	International Organization for Standardization
IT	Information Technology
ITSEF	Information Technology Security Evaluation Facility
IUT	Implementation Under Test
IV	Initialization Vector
KAT	Known Answer Tests
KDF	Key Derivation Function
KEK	Key Encryption Key
KW	Key Wrap
KWP	Key Wrapping with Padding
MAC	Message Authentication Code
MODP	Modular Exponential
NAT	Network Address Translation
NIAP	National Information Assurance Partnership
NIST	National Institute of Standards and Technology
NPE	Non-person Entity
NTP	Network Time Protocol
OCSP	Online Certificate Status Protocol
OE	Operational Environment
OID	Object Identifier
OMB	Office of Management and Budget
PGP	Pretty Good Privacy
PKI	Public Key Infrastructure
PKV	Public Key Verification
PP	Protection Profile
PP	Protection Profile
PP-Configuration	Protection Profile Configuration
PP-Module	Protection Profile Module
RA	Registration Authority
RAM	Random Access Memory
RBG	Random Bit Generator
rDSA	RSA Digital Signature Algorithm
REK	Root Encryption Key
RFC	Request for Comment
RNG	Random Number Generator
RNGVS	Random Number Generator Validation System
RSA	Rivest Shamir Adleman
S/MIME	Secure/Multi-purpose Internet Mail Extensions
SA	Security Association (IPsec)
SAN	Subject Alternative Name
SAR	Security Assurance Requirement
SAR	Security Assurance Requirement
SFR	Security Functional Requirement
SFR	Security Functional Requirement
SHA	Secure Hash Algorithm
SIP	Session Initiation Protocol
SNMP	Simple Network Management Protocol
SSH	Secure Shell
SSL	Secure Sockets Layer
ST	Security Target
ST	Security Target
SWID	Software Identification
TLS	Transport Layer Security
TOE	Target of Evaluation
TOE	Target of Evaluation
TPM	Trusted Platform Module
TSF	TOE Security Function
TSF	TOE Security Functionality
TSFI	TSF Interface
TSS	TOE Summary Specification
TSS	TOE Summary Specification
URI	Uniform Resource Identifier
URL	Uniform Resource Locator
USB	Universal Serial Bus
XCCDF	eXtensible Configuration Checklist Description Format
XOR	Exclusive Or

Appendix F - Bibliography

Table 11: Bibliography
Identifier	Title
[CC]	Common Criteria for Information Technology Security Evaluation - Part 1: Introduction and general model, CCMB-2022-11-001, CC:2022, Revision 1, November 2022. Part 2: Security functional requirements, CCMB-2022-11-002, CC:2022, Revision 1, November 2022. Part 3: Security assurance requirements, CCMB-2022-11-003, CC:2022, Revision 1, November 2022. Part 4: Framework for the specification of evaluation methods and activities, CCMB-2022-11-004, CC:2022, Revision 1, November 2022. Part 5: Pre-defined packages of security requirements, CCMB-2022-11-005, CC:2022, Revision 1, November 2022.
[CEM]	Common Methodology for Information Technology Security Evaluation - Evaluation methodology, CCMB-2022-11-006, CC:2022, Revision 1, November 2022.
[IR7924]	Second Draft NIST IR 7924, Reference Certificate Policy, May 2014.

Protection Profile for Certification Authorities

Revision History

Contents

1 Introduction

1.1 Overview

1.2 Terms

1.2.1 Common Criteria Terms

1.2.2 Technical Terms

1.3 Compliant Targets of Evaluation

1.3.1 TOE Boundary

1.4 Use Cases

1.5 Product Features Mapped to Implementation-Dependent Requirements

1.5.1 TOE Responsible for Protecting Subscriber Information

1.5.2 TOE supports Audit Review

1.5.3 TSF Supports Audit Pre-Select

1.5.4 TSF Supports Storage of Audit Records

2 Conformance Claims

3 Security Problem Definition

3.1 Threats

3.2 Assumptions

3.3 Organizational Security Policies

4 Security Objectives

4.1 Security Objectives for the Operational Environment

4.2 Security Objectives Rationale

5 Security Requirements

5.1 Security Functional Requirements

5.1.1 Auditable Events for Mandatory SFRs

5.1.2 Class: Security Audit (FAU)

FAU_ADP_EXT.1 Audit Dependencies

FAU_GCR_EXT.1 Generation of Certificate Repository

FAU_GEN.1 Audit Data Generation

FAU_GEN.2 User Identity Association

FAU_STG.1 Audit Data Storage Location

FAU_STG.5 Prevention of Audit Data Loss

5.1.3 Class: Communications (FCO)

FCO_NRO_EXT.2 Certificate-Based Proof of Origin

5.1.4 Class: Cryptographic Support (FCS)

FCS_CDP_EXT.1 Cryptographic Dependencies

FCS_STG_EXT.1 Cryptographic Key Storage

5.1.5 Class: User Data Protection (FDP)

FDP_CER_EXT.1 Certificate Profiles

FDP_CER_EXT.2 Certificate Request Matching

FDP_CER_EXT.3 Certificate Issuance Approval

FDP_CSI_EXT.1 Certificate Status Information

FDP_RIP.1 Subset Residual Information Protection

5.1.6 Class: Identification and Authentication (FIA)

FIA_UAU_EXT.1 Authentication Mechanism

FIA_UIA_EXT.1 User Identification and Authentication

FIA_X509_EXT.1 Certificate Validation

FIA_X509_EXT.2 Certificate-based Authentication

5.1.7 Class: Security Management (FMT)

FMT_MOF.1/Admin Management of Security Functions Behavior (Administrator Functions)

FMT_MOF.1/Auditor Management of Security Functions Behavior (Auditor Functions)

FMT_MOF.1/CA Management of Security Functions Behavior (CA Operations Functions)

FMT_MOF.1/CO Management of Security Functions Behavior (Admin/Officer Functions)

FMT_MOF.1/RA Management of Security Functions Behavior (CA/RA Functions)

FMT_MTD.1 Management of TSF Data

FMT_SMF.1 Specification of Management Functions

FMT_SMR.2 Restrictions on Security Roles

5.1.8 Class: Protection of the TSF (FPT)

FPT_FLS.1 Failure with Preservation of Secure State

FPT_KST_EXT.1 No Plaintext Key Export

FPT_KST_EXT.2 Key Protection

FPT_RCV.1 Manual Trusted Recovery

FPT_SKP_EXT.1 Protection of Keys

FPT_STM.1 Reliable Time Stamps

FPT_TUD_EXT.1 Trusted Update

5.1.9 Class: TOE Access (FTA)

FTA_SSL.4 User-Initiated Termination

FTA_TAB.1 Default TOE Access Banners

5.1.10 Class: Trusted Path/Channels (FTP)

FTP_TRP.1 Trusted Path

5.1.11 TOE Security Functional Requirements Rationale

5.2 Security Assurance Requirements

5.2.1 Class ADV: Development

ADV_FSP.1 Basic Functional Specification (ADV_FSP.1)

Developer action elements:

Content and presentation elements:

Evaluator action elements:

5.2.2 Class AGD: Guidance Documentation