Protection Profile for Certification Authorities

Version: 2.1

2017-12-01

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

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 2Conformance Claims 3Security Problem Description 3.1Threats 3.2Assumptions 3.3Organizational Security Policies 4Security Objectives 4.1Security Objectives for the TOE 4.2Security Objectives for the Operational Environment 4.3Security 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.1 Strictly 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.2 Objective 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.4 Auditable Events for Implementation-Dependent Requirements A.4.1TOE Responsible for Protecting Subscriber Information A.4.1.1Class: Cryptographic Support (FCS)A.4.2TOE supports Audit Review A.4.2.1Class: Security Audit (FAU)A.4.3TSF Supports Audit Pre-Select A.4.3.1Class: Security Audit (FAU)A.4.4TSF Supports Storage of Audit Records A.4.4.1Class: Security Audit (FAU)Appendix B - Selection-Based Requirements B.1 Audit 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 - Entropy Documentation and Assessment Appendix D - References Appendix E - Acronyms

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.
Common Criteria (CC)	Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408).
Common Criteria Testing Laboratory	Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility, accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations.
Common Evaluation Methodology (CEM)	Common Evaluation Methodology for Information Technology Security Evaluation.
Distributed TOE	A TOE composed of multiple components operating as a logical whole.
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 Protection Profiles.
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.
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.
Target of Evaluation (TOE)	The product under evaluation.

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.

2 Conformance Claims

Conformance Statement: An ST must claim exact conformance to this PP, as defined in the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional SFRs (dated May 2017).
CC Conformance Claims: This PP is conformant to Parts 2 (extended) and 3 (conformant) of Common Criteria Version 3.1, Revision 5.
PP Claim: This PP does not claim conformance to any Protection Profile.
Package Claim: This PP is Network Encryption (TLS) Package, Version 1.1 Conformant and Secure Shell (SSH) Package, Version 1.0 Conformant .

3 Security Problem Description

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 TOE

In some cases, an objective is addressed only by requirements that are either selection-based or optional. In these cases, if none of those requirements are included in the ST, the ST author does not include that objective in the ST.

O.AUDIT_LOSS_RESPONSE: The TOE will respond to possible loss of audit records when audit trail storage is full or nearly full by restricting auditable events.
O.AUDIT_PROTECTION: The TOE will protect audit records against unauthorized access, modification, or deletion to ensure accountability of user actions.
O.CERTIFICATES: The TSF must ensure that certificates, certificate revocation lists, and certificate status information are valid.
O.CONFIGURATION_MANAGEMENT: The TOE will conduct configuration management to assure identification of system connectivity (software, hardware, and firmware), and components (software, hardware, and firmware), auditing of configuration data, and controlling changes to configuration items.
O.DISPLAY_BANNER: The TOE will display an advisory warning regarding use of the TOE.
O.INTEGRITY_PROTECTION: The TOE will provide appropriate integrity protection for TSF data and software and any user data stored by the TOE.
O.NON_REPUDIATION: The TOE will prevent a subscriber from avoiding accountability for sending a message by providing evidence that the subscriber sent the message; and control communications from unknown source.
O.PROTECTED_COMMUNICATIONS: The TOE will provide protected communication channels for administrators, other parts of a distributed TOE, and authorized IT entities. The TOE will protect data assets when they are being transmitted to and from the TOE, including through intervening untrusted components.
O.RECOVERY: The TOE will have the capability to store and recover to a previous state at the direction of the administrator (e.g., provide support for archival and recovery capabilities).
O.RESIDUAL_INFORMATION_CLEARING: The TOE will ensure that any data contained in a protected resource is not available when the resource is reallocated.
O.SESSION_LOCK: The TOE will provide mechanisms that mitigate the risk of unattended sessions being hijacked.
O.SYSTEM_MONITORING: The TOE will provide the capability to generate audit data. The TOE will record in audit records: date and time of action and the entity responsible for the action.
O.TOE_ADMINISTRATION: The TOE will provide mechanisms to ensure that only privileged users are able to log in and configure the TOE, and provide protections for logged-in users. The TOE will ensure that administrative responsibilities are separated across different roles in order to mitigate the impact of improper administrative activities or unauthorized administrative access.
O.TSF_SELF_TEST: The TOE will provide integrity protection to detect modifications to firmware, software, and archived data. If this SFR is not claimed by the TOE, this functionality is expected to be satisfied by the environmental objective OE.TRUSTED_PLATFORM.
O.VERIFIABLE_UPDATES: The TOE will provide the capability to help ensure that any updates to the TOE can be verified by the administrator to be unaltered and from a trusted source.

4.2 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: The Operational Environment provides a certificate repository for storage of certificates (and optionally CRLs) issued by the TSF.
OE.CERT_REPOSITORY_SEARCH: 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: The Operational Environment provides a mechanism for the generation of portions of the audit data.
OE.AUDIT_RETENTION: The Operational Environment provides mechanisms for retention of audit records for both normal and extended retention periods.
OE.AUDIT_REVIEW: The Operational Environment provides a mechanism for the review of specified audit data.
OE.AUDIT_STORAGE: The Operational Environment provides a mechanism for the storage of specified audit data.
OE.CRYPTOGRAPHY: The Operational Environment provides cryptographic services that can be invoked by the TSF in order to perform security functionality.
OE.KEY_ARCHIVAL: The Operational Environment provides the ability to use split knowledge procedures to enforce twoparty 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: The Operational Environment provides protection for specified public keys associated with CA functions.
OE.SESSION_PROTECTION_LOCAL: The Operational Environment provides the ability to lock or terminate local administrative sessions.
OE.SESSION_PROTECTION_REMOTE: The Operational Environment provides the ability to lock or terminate remote administrative sessions.
OE.TOE_ADMINISTRATION: 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: The operating system on which the TOE has been installed is securely configured, regularly patched, and not subject to unauthorized access.

4.3 Security Objectives Rationale

This section describes how the assumptions, threats, and organization security policies map to the security objectives.

Threat, Assumption, or OSP	Security Objectives	Rationale
T.PRIVILEGED_USER_ERROR	O.AUDIT_LOSS_RESPONSE	The TOE will respond to possible loss of audit records when audit trail storage is full or nearly full by restricting auditable events.
	O.AUDIT_PROTECTION	The TOE will protect audit records against unauthorized access, modification, or deletion to ensure accountability of user actions.
	O.SESSION_LOCK	The TOE will provide mechanisms that mitigate the risk of unattended sessions being hijacked.
	O.TOE_ADMINISTRATION	The TOE will provide mechanisms to ensure that only privileged users are able to log in and configure the TOE, and provide protections for logged-in users. The TOE will ensure that administrative responsibilities are separated across different roles in order to mitigate the impact of improper administrative activities or unauthorized administrative access.
T.TSF_FAILURE	O.TSF_SELF_TEST	The TOE will provide the capability to test some subset of its security functionality to ensure it is operating properly. The TOE will provide integrity protection to detect modifications to firmware, software, and archived data.
T.UNAUTHENTICATED_TRANSACTIONS	O.CERTIFICATES	The TSF must ensure that certificates, certificate revocation lists, and certificate status information are valid.
	O.CONFIGURATION_MANAGEMENT	The TOE will conduct configuration management to assure identification of system connectivity (software, hardware, and firmware), and components (software, hardware, and firmware), auditing of configuration data, and controlling changes to configuration items.
	O.INTEGRITY_PROTECTION	The TOE will provide appropriate integrity protection for TSF data and software and any user data stored by the TOE.
	O.NON_REPUDIATION	The TOE will prevent a subscriber from avoiding accountability for sending a message by providing evidence that the subscriber sent the message; and control communications from unknown source.
T.UNAUTHORIZED_ACCESS	O.PROTECTED_COMMUNICATIONS	The TOE will provide protected communication channels for administrators, other parts of a distributed TOE, and authorized IT entities. The TOE will protect data assets when they are being transmitted to and from the TOE, including through intervening untrusted components.
	O.SESSION_LOCK	The TOE will provide mechanisms that mitigate the risk of unattended sessions being hijacked.
	O.TOE_ADMINISTRATION	The TOE will provide mechanisms to ensure that only privileged users are able to log in and configure the TOE, and provide protections for logged-in users. The TOE will ensure that administrative responsibilities are separated across different roles in order to mitigate the impact of improper administrative activities or unauthorized administrative access.
T.UNAUTHORIZED_UPDATE	O.VERIFIABLE_UPDATES	The TOE will provide the capability to help ensure that any updates to the TOE can be verified by the administrator to be unaltered and from a trusted source.
T.UNDETECTED_ACTIONS	O.AUDIT_LOSS_RESPONSE	The TOE will respond to possible loss of audit records when audit trail storage is full or nearly full by restricting auditable events
	O.AUDIT_PROTECTION	The TOE will protect audit records against unauthorized access, modification, or deletion to ensure accountability of user actions.
	O.SYSTEM_MONITORING	The TOE will provide the capability to generate audit data and send those data to an external IT entity. The TOE will record in audit records: date and time of action and the entity responsible for the action.
T.USER_DATA_REUSE	O.RESIDUAL_INFORMATION_CLEARING	The TOE will ensure that any data contained in a protected resource is not available when the resource is reallocated.
T.WEAK_CRYPTO	O.PROTECTED_COMMUNICATIONS	The TOE will provide protected communication channels for administrators, other parts of a distributed TOE, and authorized IT entities. The TOE will protect data assets when they are being transmitted to and from the TOE, including through intervening untrusted components.
T.WEAK_CRYPTO	O.VERIFIABLE_UPDATES	The TOE will provide the capability to help ensure that any updates to the TOE can be verified by the administrator to be unaltered and from a trusted source.
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 (including replacing an assignment with a more restrictive selection) 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 Security Functional Requirements (SFRs) included in this section are derived from Part 2 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 4, with additional extended functional components. 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, and also used to specify whether the TSF or OE is responsible for actions pertaining to a particular audit event associated with the SFRs (this is done in FAU_ADP_EXT.1 below). 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. The ST author should refer to the right-most column of Table 4 through Table 6 and complete these fields accordingly.

5.1.1 Auditable Events for Mandatory SFRs

Table 1: Auditable Events for Mandatory SFRs

Requirement	Auditable Events	Additional Audit Record Contents
FAU_ADP_EXT.1	No events specified
FAU_GCR_EXT.1	No events specified
FAU_GEN.1	No events specified
FAU_GEN.2	No events specified
FAU_STG.4	No events specified
FAU_STG_EXT.1	No events specified
FCO_NRO_EXT.2	No events specified
FCS_CDP_EXT.1	No events specified
FCS_STG_EXT.1	No events specified
FDP_CER_EXT.1	Certificate generation: Success.	Certificate value or object identifier.
FDP_CER_EXT.2	Linking of certificate to certificate request: Success	Certificate value or object identifier Certificate request or link to certificate request object identifier
FDP_CER_EXT.2	Linking of certificate to certificate request: Failure	Reason for failure Certificate request or link to certificate request object identifier
FDP_CER_EXT.3	Failed certificate approvals	Reason for failure Certificate request or link to certificate request object identifier
FDP_CSI_EXT.1	No events specified
FDP_RIP.1	No events specified
FIA_UAU_EXT.1	All uses of the authentication mechanism used for access to TOE related functions	Origin of the attempt (e.g., IP address)
FIA_UIA_EXT.1	All use of the identification and authentication mechanism used for TOE-related roles	Provided user identity. Origin of the attempt (e.g., IP address)
FIA_X509_EXT.1	Failed certificate validations
FIA_X509_EXT.2	Failed authentications
FMT_MOF.1/1	No events specified
FMT_MOF.1/2	No events specified
FMT_MOF.1/3	No events specified
FMT_MOF.1/4	No events specified
FMT_MOF.1/5	No events specified
FMT_MTD.1	No events specified
FMT_SMF.1	No events specified
FMT_SMR.2	Modifications to the group of users that are part of a role	Modifications to the group of users that are part of the role
FPT_FLS.1	Invocation of failures under the requirement	Indication that the TSF has failed with the type of failure that occurred
FPT_KST_EXT.1	No events specified
FPT_KST_EXT.2	All unauthorized attempts to use the TOE secret abnd private keys.	Identifier of user or process that attempted access.
FPT_RCV.1	The fact that a faiure of service discontinuity occurred.
FPT_RCV.1	Resumption of the regular operation.	TSF failure types that are available on recovery.
FPT_SKP_EXT.1	No events specified
FPT_STM.1	Changes to the time	The new and old values for the time.
FPT_TUD_EXT.1	Initiation of update.	Version number
FTA_SSL.4	The termination of an interactive section.
FTA_TAB.1	No events specified
FTP_TRP.1	Initiation of the trusted channel.	Identification of the claimed user identity
FTP_TRP.1	Termination of the trusted channel.	Identification of the claimed user identity
FTP_TRP.1	Failures of the trusted path functions.	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.1(2) 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

Refinement:The TSF shall generate an audit record of the following auditable events:

Start-up of the TSF audit functions
All auditable events for the not specified level of audit; and
All administrative actions invoked through the TSF interface;
Specifically defined auditable events listed in Table 4 through Table 6
Specifically defined auditable events listed in Table atref-mandatory-ss
Specifically defined auditable events listed in Table 2
Specifically defined auditable events listed in Table 5
Specifically defined auditable events listed in Table 4

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

Refinement:The TSF shall within each audit record at least the following information:

Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; and
For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, information specified in column three of Table 4 through Table 6.

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 or listed in the last column in table 4.

Evaluation Activity

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.

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 selectionbased 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

Refinement: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.4 Prevention of Audit Data Loss

FAU_STG.4.1

Refinement:The TSF shall and [assignment: other actions to be taken in case of audit storage failure] if the audit trail cannot be written to.

Application Note: This requirement applies to the TOE regardless of whether the audit trail is stored within the TOE boundary (e.g. the audit trail is full) or on an external system in the Operational Environment (e.g. the connection to a remote audit repository is broken). In either case, the ST author is expected to describe how the TSF is made aware of any such failures and how it behaves in response.

FAU_STG_EXT.1 External Audit Trail Storage

FAU_STG_EXT.1.1

The TSF shall maintain availability and integrity of audit data by storing it [selection: locally on the TOE, locally on the TOE platform, on an external IT entity using a trusted channel protocol defined in FTP_ITC.1].

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 Activity

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 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 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.

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(2).

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(2).

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(2) 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(2) is implemented by the OE, then FCO_NRO_EXT.2.1 and FCO_NRO_EXT.2.2 are in accordance with FCS_COP.1(2) if they interface with the OE to invoke the signature algorithms indicated in FCS_COP.1(2).

Evaluation Activity

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(2).

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 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 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 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 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 5: For each supported request using password based authentication, the evaluator shall use invalid passwords and verify that the TSF rejects the requests.

Test 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 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 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(1), FCS_CKM_EXT.1(2), FCS_CKM_EXT.1(3), FCS_CKM_EXT.1(4), FCS_CKM_EXT.4, FCS_CKM_EXT.5, FCS_CKM_EXT.6, FCS_CKM_EXT.7, FCS_CKM_EXT.8, FCS_COP.1(1), FCS_COP.1(2), FCS_COP.1(3), FCS_COP.1(4), 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(2), FCS_CKM_EXT.1(3)], 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

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(2).
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 Activity

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 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 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 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 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 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

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 Activity

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.
Tests
The evaluator shall perform the following test:

Test 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.
If ‘rules’ is selected in FDP_CER_EXT.3.1 to allow automatic approval, the evaluator shall follow operational guidance to configure the certificate issuance approval function to follow a rule for automatic approval, and perform the following tests:
Test 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 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

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 Activity

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 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 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 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 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 Activity

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 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 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 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 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 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

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 authorshall 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 Activity

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 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 2: The evaluator shall demonstrate that validating an expired certificate anywhere in a certificate path results in the function failing.

Test 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 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 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 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 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

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 Extended Package for Secure Shell.

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 Activity

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 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 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 administratorconfigurable 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/1 Management of Security Functions Behavior (Administrator Functions)

FMT_MOF.1.1/1

The shall restrict the abiulity to 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.

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

FMT_MOF.1.1/2

The shall restrict the ability to

to

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

FMT_MOF.1.1/3

The shall restict the ability to to .

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

FMT_MOF.1.1/4

The shall restrict the ability to to .

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/5 Management of Security Functions Behavior (Autitor Functions)

FMT_MOF.1.1/5

The shall restrict the ability to to [auditors].

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 specificallyidentified 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: DRBG 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 [selection: provide, interface with the Operational Environment to provide] 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(2).

Evaluation Activity

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 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 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 3: The evaluator shall obtain or produce an update with an invalid signature, and shall attempt to install it on the TOE. The evaluatorshall verify that the TOE rejects the update and performs any other actions specified in the TSS.

Test 4: 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 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 TSF shall display advisory warning message regarding unauthorized use of the TOE.

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 communication path between itself and 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 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 security objective for the TOE, showing that the SFRs are suitable to meet and achieve the security objectives:

OBJECTIVE	ADDRESSED BY	RATIONALE
O.AUDIT_LOSS_RESPONSE	FAU_ADP_EXT.1	Requires the TSF to implement or support audit functionality.
O.AUDIT_LOSS_RESPONSE	FAU_STG.4	Prevents audited events if the audit trail cannot be written to.
O.AUDIT_PROTECTION	FAU_ADP_EXT.1	Requires the TSF to implement or support audit functionality.
	FAU_STG.1(1)	Requires the TSF protect audit records from unauthorized deletion.
	FAU_STG.1(2)	Requires that audit records with retentaion requirements be retained for the appropriate period.
	FAU_STG_EXT.2	Specifies rules for the retention of audit data.
O.CERTIFICATES	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_CER_EXT.4	(Optional) Requires that non-v3 certificates have certain characteristics.
	FDP_CRL_EXT.1	Specifies contents for certificate revocation lists.
	FDP_CSI_EXT.1	Requires that the TSF provide formatted certificatee status information.
	FDP_OCSPG_EXT.1	Specifies the contents of OCSP response messages.
	FDP_SDP_EXT.1	(Optional) Requires that the TSF protect certain information through encryption.
	FDP_STG_EXT.1	(OPtional) Requires that the TSF protect trusted public keys and certificates.
	FIA_CMCS_EXT.1	Defines the types of CMC reuests handled by the TSF.
	FIA_ESTS_EXT.1	Specifies requirements for EST enrollment requests.
	FIA_X509_EXT.1	Requires the TSF support validation of cerficates according to a set of rules.
	FIA_X509_EXT.2	Requires that the TOE use X.509 certificates for code signing and other purposes.
	FPT_NPE_EXT.1	(Optional) Requires the TSF enforce rules for submitting NPE certificate requests.
O.CONFIGURATION_MANAGEMENT	FDP_CER_EXT.1	Requires that the TSF support configured certifcate profiles.
	FDP_CER_EXT.4	(Optional) Requires that non-v3 certificates have certain characteristics.
	FDP_CRL_EXT.1	Specifies contents for certificate revocation lists.
	FDP_OCSPG_EXT.1	Specifies the contents of OCSP response messages.
	FMT_MOF.1(1)	Defines management functions to be performed exclusively by Administrators.
	FMT_MOF.1(2)	Defines management functions to be performed by CA or RA Staff.
	FMT_MOF.1(3)	Defines management functions to be performed by CA Staff.
	FMT_MOF.1(4)	Defines management functions to be performed by Administrators, Auditr, or CA Staff.
	FMT_MOF.1(5)	Defines management functions to be performed by auditors.
	FMT_MTD.1	Requires that only priviledged users manage TSF data.
	FPT_NPE_EXT.1	(Optional) Requires the TSF enforce rules for submitting NPE certificate requests.
O.DISPLAY_BANNER	FTA_TAB.1	Requires display of a consent banner prior to establishment of a user session.
O.INTEGRITY_PROTECTION	FCS_CDP_EXT.1	Requires that the TSF implements or invokes cryptographic functionality.
	FCS_CKM_EXT.5	Requires that the TSF protect public keys from modification.
	FDP_ITT.1	Requires that the TSF protect user data during transmission between physically separate parts of the TOE.
	FPT_ITT.1	Requires that the TSF protect data transmissed between different parts of the TOE.
	FPT_TST_EXT.1	(Optional) Requires the TSF ensure the integrity of TOE software and firmware.
	FPT_TST_EXT.2	(Optional) Requires the TSF ensure the integrity of certain data relevant to TOE security.
O.NON_REPUDIATION	FCO_NRO_EXT.2	Requires that the TSF provide proof of origin for certificates it issues.
	FCO_NRR_EXT.2	Requires that the TSF provide certificate-based proof of receipt.
	FIA_CMCC_EXT.1	Specifies requirements for CMC requests and responses.
	FIA_ESTC_EXT.1	Specifies requirements for client-side EST enrollment requests.
O.PROTECTED_COMMUNICATIONS	FCS_CDP_EXT.1	Requires that the TSF implements or invokes cryptographic functionality.
	FCS_CKM.1	Specifies allowable algorithms for generation of assymmetric keys.
	FCS_CKM.2	Specifies allowable algorithms for key establishment.
	FCS_CKM_EXT.1(1)	Specifies requirements for assymmetric key generation.
	FCS_CKM_EXT.1(2)	Specifies requirements for generation of KEKs.
	FCS_CKM_EXT.1(3)	Specifies requirements for assymmetric KEKs.
	FCS_CKM_EXT.1(4)	Specifies requirements for key shares.
	FCS_CKM_EXT.4	Specifies requirements for cryptographic key destruction.
	FCS_CKM_EXT.7	Requires support for a hardware-protected REK.
	FCS_CKM_EXT.8	Requires that the TSF provide a traceable hierarchy of keys.
	FCS_COP.1(1)	Defines permissible AES encryption algorithms and key sizes.
	FCS_COP.1(2)	Defines permissible cryptographic signature algorithms.
	FCS_COP.1(3)	Defines permissible cryptographic hash algorthms and sizes.
	FCS_COP.1(4)	Defines permissible keyed-hash message authentication algorithms.
	FCS_COP.1(5)	(Optional) Requires the TSF to support password-based key derivation.
	FCS_HTTPS_EXT.1	Requires that the TSF implement HTTPS over TLS.
	FCS_IPSEC_EXT.1	Specifies requirements for the TSF implementation of IPsec.
	FCS_RBG_EXT.1	Requires that the TSF have access to DRBG services.
	FCS_STG_EXT.1	Requires secure storage of private and secret keys.
	FCS_TLSC_EXT.1	Specifies requirements for the client-side implementation of TLS.
	FCS_TLSS_EXT.1	Specifies requirements for the server-side implementation of TLS.
	FDP_ITT.1	Requires that the TSF protect user data during transmission between physically separate parts of the TOE.
	FIA_PSK_EXT.1	Defines requiremetns for pre-shared keys used by the TSF.
	FPT_ITT.1	Requires that the TSF protect data transmissed between different parts of the TOE.
	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 provate and secret keys.
	FPT_SKP_EXT.1	Requires that the TSF be able to prevent reading of pre-shared, private and secret keys.
	FPT_SKY_EXT.1	(Optional) Requires two-party control for certain specified actions.
	FPT_SKY_EXT.2	Requires that key shares be accessible only by priviledged users.
	FTP_ITC.1	Requires secure communications between the TOE and external IT entities.
	FTP_TRP.1	Requires the TSF to provide a trusted path to remote entities.
O.RECOVERY	FCS_CDP_EXT.1	Requires that the TSF implements or invokes cryptographic functionality.
	FCS_CKM_EXT.6	Requires that the TSF protect keys needed for continuity of operations.
	FPT_FLS.1	Requires that the TSF preserve a secure state on failure.
	FPT_RCV.1	Requires that the TSF enter maintenance mode on certain failures.
O.RESIDUAL_INFORMATION_CLEARING	FDP_RIP.1	Requires that the TSF ensure that residual information is not perpetuated.
O.SESSION_LOCK	FTA_SSL_EXT.1	(Optional) Requires an inactivity timeout on local user sessions.
O.SYSTEM_MONITORING	FAU_ADP_EXT.1	Requires the TSF to implement or support audit functionality.
	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_SAR.1	Requires that auditors be able to read all audit records.
	FAU_SAR.3	Requires support for searches of audit data based on certificate identifier.
	FAU_GCR_EXT.1	Requires that the TSF store certificates that it issues.
	FAU_SCR_EXT.1	Requires the TSF support review of certificates in a repository.
	FAU_SEL.1	Requires support for selelection of audit events based on specified attributes.
	FAU_STG_EXT.1	Requires that the TSF ensure the integrity of audit data.
	FIA_UIA_EXT.1	Defines the actions permitted prior to authentication of a user.
	FPT_STM.1	Requires thet the TSF provide or support reliable time stamps.
O.TOE_ADMINISTRATION	FIA_AFL.1	Requires that the TSF detect exceessive unsuccessful login attempts from a remote user.
	FIA_PMG_EXT.1	Specifies password composition rules.
	FIA_UAU.7	Defines feedback permitted to the user during authentication.
	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(1)	Defines management functions to be performed exclusively by Administrators.
	FMT_MOF.1(2)	Defines management functions to be performed by CA or RA Staff.
	FMT_MOF.1(3)	Defines management functions to be performed by CA Staff.
	FMT_MOF.1(4)	Defines management functions to be performed by Administrators, Auditr, or CA Staff.
	FMT_MOF.1(5)	Defines management functions to be performed by auditors.
	FMT_MTD.1	Requires that only priviledged 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_APW_EXT.1	Defines protections for plaintext passwords.
	FTA_SSL_EXT.1	(Optional) Requires an inactivity timeout on local user sessions.
	FTA_SSL.3	(Optional) Requires an inactivity timeout on remote user sessions.
	FTA_SSL.4	Requires that the TSF support user-initiated termination of their own SSL sessions.
O.TSF_SELF_TEST	FPT_TST_EXT.1	(Optional) Requires the TSF ensure the integrity of TOE software and firmware.
O.TSF_SELF_TEST	FPT_TST_EXT.2	(Optional) Requires the TSF ensure the integrity of certain data relevant to TOE security.
O.VERIFIABLE_UPDATES	FCS_CDP_EXT.1	Requires that the TSF implements or invokes cryptographic functionality.
	FCS_COP.1(2)	Defines permissible cryptographic signature algorithms.
	FIA_X509_EXT.3	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.

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 defined in this section identify the management and evaluative activities required to address the threats identified in Section 3.1 of this PP.

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.3C

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

ADV_FSP.1.4C

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

ADV_FSP.1.5C

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

ADV_FSP.1.6C

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

Evaluator action elements:

ADV_FSP.1.7E

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

ADV_FSP.1.8E

The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs. There are no specific assurance activities associated with these SARs, except ensuring the information is provided. The functional specification documentation is provided to support the evaluation activities described in Section 5.1 Security Functional Requirements, and other activities described for AGD, ATE, and AVA SARs. The requirements on the content of the functional specification information is implicitly assessed by virtue of the other assurance activities being performed; if the evaluator is unable to perform an activity because there is insufficient interface information, then an adequate functional specification has not been provided.

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.2C

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.3C

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.4C

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.5C

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.6C

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.7C

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.8C

The operational user guidance shall be clear and reasonable.

Evaluator action elements:

AGD_OPE.1.9E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Some of the contents of the operational guidance will be verified by the assurance activities in Section 5.1 and evaluation of the TOE according to the CEM. The following additional information is also required.

The operational guidance shall at a minimum list the processes that comprise the TOE in its evaluated configuration.

The operational guidance shall contain instructions for configuring the Operational Environment to support the functions of the TOE. These instructions shall include configuration of the cryptographic engine associated with the evaluated configuration of the TOE as well as configuration of the underlying platform. It shall provide a warning to the administrator that use of other cryptographic engines or platforms was not evaluated nor tested during the CC evaluation of the TOE. The documentation must describe the process for installing updates to the TOE. The evaluator shall verify that this process includes the following steps:

Instructions for obtaining the update. This should include instructions for making the update accessible to the TOE (e.g., placement in a specific directory).

Instructions for initiating the update process, as well as discerning whether the process was successful or unsuccessful.

The TOE will likely contain security functionality that does not fall in the scope of evaluation under this PP. The operational guidance shall make it clear to an administrator which security functionality is covered by the evaluation activities.

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.2C

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.3C

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.4E

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

AGD_PRE.1.5E

The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation. As indicated in the introduction above, there are significant expectations with respect to the documentation—especially when configuring the operational environment to support TOE functional requirements. The evaluator shall check to ensure that the guidance provided for the TOE adequately addresses all platforms claimed for the TOE in the ST.

The evaluator shall check to ensure that the following guidance is provided:

As indicated in the introductory material, administration of the TOE is performed by one or more administrators that are a subset of the group of all users of the TOE. While it must be the case that the overall system (TOE plus Operational Environment [Operational Environment]) provide this capability, the responsibility for the implementation of the functionality can vary from totally the Operational Environment’s responsibility to totally the TOE’s responsibility. At a high level, the guidance must contain the appropriate instructions so that the Operational Environment is configured so that it provides the portion of the capability for which it is responsible.
Many of the cryptographic requirements in the PP can be met by the TOE, the Operational Environment, or a combination of the two. The Operational Environment may provide the necessary functionality via use of an external cryptographic module such as a HSM. The guidance must contain the appropriate instructions so that the TOE or Operational Environment is configured to provide the portion of the capability for which it is responsible.

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-uservisible 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.2C

The TOE shall be labeled with its unique reference.

Evaluator action elements:

ALC_CMC.1.3E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check the ST to ensure that it contains an identifier (such as a product name/version number) that specifically identifies the version that meets the requirements of the ST. Further, the evaluator shall check the AGD guidance and TOE samples received for testing to ensure that the version number is consistent with that in the ST. If the vendor maintains a web site advertising the TOE, the evaluator shall examine the information on the web site to ensure that the information in the ST is sufficient to distinguish the product.

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.2C

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

ALC_CMS.1.3C

The configuration list shall uniquely identify the configuration items.

Evaluator action elements:

ALC_CMS.1.4E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The “evaluation evidence required by the SARs” in this PP is limited to the information in the ST coupled with the guidance provided to administrators and users under the AGD requirements. By ensuring that the TOE is specifically identified and that this identification is consistent in the ST and in the AGD guidance (as done in the assurance activity for ALC_CMC.1), the evaluator implicitly confirms the information required by this component.

5.2.4 Class ASE: Security Target Evaluation

As per ASE activities defined in [CEM].

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.2C

The TOE shall be suitable for testing.

Evaluator action elements:

ATE_IND.1.3E

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

ATE_IND.1.4E

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 Extended Package for Secure Shell

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.2C

The TOE shall be suitable for testing.

Evaluator action elements:

AVA_VAN.1.3E

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

AVA_VAN.1.4E

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

AVA_VAN.1.5E

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. As with ATE_IND, the evaluator shall generate a report to document their findings with respect to this requirement. This report could physically be part of the overall test report mentioned in ATE_IND, or a separate document. The evaluator performs a search of public information to determine the vulnerabilities that have been found in certification authority products, the communications and enrollment protocols used, as well as those that pertain to the particular TOE. The evaluator documents the sources consulted and the vulnerabilities found in the report. For each vulnerability found, the evaluator either provides a rationale with respect to its non-applicability, or the evaluator formulates a test (using the guidelines provided in ATE_IND) to confirm the vulnerability, if suitable. Suitability is determined by assessing the attack vector needed to take advantage of the vulnerability. For example, if the vulnerability can be detected by pressing a key combination on boot-up, a test would be suitable at the assurance level of this PP. If exploiting the vulnerability requires expert skills and an electron microscope, for instance, then a test would not be suitable and an appropriate justification would be formulated.

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 that may be included in the ST, but are not required in order to conform to this PP. However, applied modules, packages and/or use cases may refine specific requirements as mandatory.

The first type ( A.1 Strictly Optional Requirements) are strictly optional requirements that are independent of the TOE implementing any function. If the TOE fulfills any of these requirements or supports a certain functionality, the vendor is encouraged to included the SFRs in the ST, but are not required in order to conform to this PP.

The second type ( A.2 Objective Requirements) are objective requirements that describe security functionality not yet widely available in commercial technology. The requirements are not currently mandated in the body of this PP, but will be included in the baseline requirements in future versions of this PP. Adoption by vendors is encouraged and expected as soon as possible.

The third type ( A.3 Implementation-Dependent Requirements) are dependent on the TOE implementing a particular function. If the TOE fulfills any of these requirements, the vendor must either add the related SFR or disable the functionality for the evaluated configuration.

A.1 Strictly Optional Requirements

A.1.1 Auditable Events for Strictly Optional Requirements

Table 2: Auditable Events for Strictly Optional Requirements

Requirement	Auditable Events	Additional Audit Record Contents
FCS_COP.1/5	No events specified
FDP_CER_EXT.4	Certificate generation	Name/identifier of the certificate. Value of the certificate generated
FDP_SDP_EXT.1	No events specified
FDP_STG_EXT.1	Changes to the trusted public keys and certificates relevant to TOE functions, including additions and deletions.	The public key and all context information associated with the key.
FPT_NPE_EXT.1	All changes to NPE rule sets and NPE.	The changes made to the NPE rule sets and associations
FPT_SKY_EXT.1	No events specified
FPT_TST_EXT.1	Execution of this set of TSF integrity tests
FPT_TST_EXT.1	Detected integrity violations	The identity of the object that caused the integrity violation
FPT_TST_EXT.2	Execution of this set of TSF integrity tests
FPT_TST_EXT.2	Detected integrity violations	The identity of the object that caused the integrity violation
FTA_SSL.3	The termination of a remote session by the session termination mechanism
FTA_SSL_EXT.1	Any attempts at unlocking or termination of an interactive session.

A.1.2 Class: Cryptographic Support (FCS)

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

FCS_COP.1.1/5

The TSF shall [Password-based Key Derivation Functions] in accordance with a specified cryptographic algorithm and cryptographic key sizes [selection: 128-bit, 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 ST author selects the appropriate hash algorithm used in the second selection.

The cryptographic key sizes in the third selection should be made to correspond to the KEK key sizes selected in FCS_CKM_EXT.1(3). 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(2)

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(1) 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(1).

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 Activity

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 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 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 Contraints

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 Activity

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 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 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 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 Split Knowledge Procedures

FPT_SKY_EXT.1.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 and [selection: no other data, user private keys, [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(3), FCS_CKM_EXT.1(4), 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.

The ST author includes this SFR in the ST when the TOE is used to enforce split knowledge procedures, either directly or via interfaces with the OE. If enforcement of split knowledge procedures 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 Activity

TSS
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. FCS_CKM_EXT.1(3) specifies how the key shares generated in accordance with FCS_CKM_EXT.1(4) 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.

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. The evaluator shall attempt to devise tests to validate that the TSF implements the described mechanism. The evaluator shall review the AGD to ensure it contains clear instructions to privileged users on how to conduct the procedures.

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. The evaluator shall also 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.

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(4), digital signature algorithm according to FCS_COP.1(2)] to the TOE software and firmware.

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(4), or FCS_COP.1(2) 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(4), digital signature algorithm according to FCS_COP.1(2)] to the [selection: Trust Anchor Database element(s), TSF keys used to manage certificates, certificate database, [assignment: other data relevant to TSF security]].

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: time interval of session 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 3: Auditable Events for Objective Requirements

Requirement	Auditable Events	Additional Audit Record Contents
FCS_KSH_EXT.1	No events specified
FIA_ENR_EXT.1	No events specified
FIA_ESTC_EXT.2	No events specified
FIA_ESTS_EXT.2	No events specified

A.2.2 Class: Cryptographic Support (FCS)

FCS_KSH_EXT.1 Key Sharing

FCS_KSH_EXT.1.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(3), FCS_CKM_EXT.1.2(3), FCS_CKM_EXT.7.1 and FPT_SKY_EXT.1.1(2).

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 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

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 Cient use of TLS-unique value

FIA_ESTC_EXT.2.1

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 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.4 Auditable Events for Implementation-Dependent Requirements

Table 4: Auditable Events for Implementation-Dependent Requirements

Requirement	Auditable Events	Additional Audit Record Contents
FAU_SAR.1	No events specified
FAU_SAR.3	No events specified
FAU_SEL.1	All modifications to the audit configuration that occur while the audit collection functions are operating.
FAU_STG.1/1	No events specified
FAU_STG.1/2	No events specified
FCS_CKM_EXT.1/1	No events specified

A.4.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.

FCS_CKM_EXT.1/1

A.4.1.1 Class: Cryptographic Support (FCS)

FCS_CKM_EXT.1/1 Symmetric Key Generation for DEKs

This is an implementation-based component. Its inclusion depends on whether the TOE implements one or more of the following features:
TOE Responsible for Protecting Subscriber Information

FCS_CKM_EXT.1.1/1

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(1) 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(2)) 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 thisthird item is selected (TSF combining KEKs to produce the DEK), then FCS_CKM_EXT.1(2) (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(1) will be included in the ST and the appropriate key wrap method will be chosen in the fifth selection.

A.4.2 TOE supports Audit Review

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

FAU_SAR.1
FAU_SAR.3

A.4.2.1 Class: Security Audit (FAU)

FAU_SAR.1 Audit Review

This is an implementation-based component. Its inclusion depends on whether the TOE implements one or more 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 records.

FAU_SAR.1.2

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

FAU_SAR.3 Selectable Audit Review

This is an implementation-based component. Its inclusion depends on whether the TOE implements one or more 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.

A.4.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 muct be included:

FAU_SEL.1

A.4.3.1 Class: Security Audit (FAU)

FAU_SEL.1 Selective Audit

This is an implementation-based component. Its inclusion depends on whether the TOE implements one or more 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 by 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.

A.4.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:

FAU_STG.1/1
FAU_STG.1/2

A.4.4.1 Class: Security Audit (FAU)

FAU_STG.1/1 Selective Audit

This is an implementation-based component. Its inclusion depends on whether the TOE implements one or more of the following features:
TSF Supports Storage of Audit Records

FAU_STG.1.1/1

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

FAU_STG.1.2/1

The TSF shall be able to [prevent] unauthorized modifications to the stored audit records 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.

FAU_STG.1/2 Selective Audit

This is an implementation-based component. Its inclusion depends on whether the TOE implements one or more of the following features:
TSF Supports Storage of Audit Records

FAU_STG.1.1/2

The TSF shall protect the stored audit records in the audit trail from deletion prior to their retention period by an auditor.

FAU_STG.1.2/2

The TSF shall be able to [prevent] modifications to the stored audit records 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 Activity

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.1(1).

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

Test 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 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.

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 Audit Events for Selection-Based Requirements

Table 5: Auditable Events for Selection-Based Requirements

Requirement	Auditable Events	Additional Audit Record Contents
FAU_SCR_EXT.1	No events specified
FAU_STG_EXT.2	No events specified
FCO_NRR_EXT.2	No events specified
FCS_CKM.1	Generation of non-ephemeral key for TOE-related funtions.	Public key generated if successful
FCS_CKM.1	[selection: Generation of ephemeral key for TOE-related functions., None]	Public key generated if successful.
FCS_CKM.2	Establishment of non-ephemeral key for TOE-related funtions.	Key established if successful
FCS_CKM.2	[selection: Establishment of ephemeral key for TOE-related functions., None]	Key established if successful.
FCS_CKM_EXT.1/2	No events specified
FCS_CKM_EXT.1/3	No events specified
FCS_CKM_EXT.1/4	No events specified
FCS_CKM_EXT.4	Failure of the key destruction process for TOE keys	Identity of object or entity being cleared.
FCS_CKM_EXT.5	Failure of the key destruction process for TOE related keys.
FCS_CKM_EXT.6	All key archival actions.
FCS_CKM_EXT.7	No events specified
FCS_CKM_EXT.8	No events specified
FCS_COP.1/1	No events specified
FCS_COP.1/2	All occurrences of signature generation using a CA signing key.	Name/identifier of object being signed. Identifier of key used for signing.
FCS_COP.1/2	Failure in signature generation.
FCS_COP.1/3	No events specified
FCS_COP.1/4	No events specified
FCS_HTTPS_EXT.1	Failure to establish an HTTPS session.	Reason for failure. Non-TOE endpoint of attempted connection (IP address).
FCS_HTTPS_EXT.1	Establishment/Termination of an HTTPS session.	Non-TOE enpoint of connection (IP address).
FCS_IPSEC_EXT.1	Failure to establish an IPsec SA.	Reason for failure. Non-TOE endpoint of connection attempt (IP address).
FCS_IPSEC_EXT.1	Establishment/Termination of an IPsec SA.	Non-TOE endpoint of connection attempt (IP address).
FCS_RBG_EXT.1	No events specified
FCS_TLSC_EXT.1	Failure establish a TLS session.	Reason for failure.
FCS_TLSC_EXT.1	Establishment/Termination of a TLS session.
FCS_TLSS_EXT.1	Failure to establish a TLS session.	Reason for failure.
FCS_TLSS_EXT.1	Establishment/termination of a TLS session.
FDP_CRL_EXT.1	Failure to generate CRL.
FDP_ITT.1	No events specified
FDP_OCSPG_EXT.1	Failure to generate cerficate statuws information.
FIA_AFL.1	The reaching of the threshold for the unsuccessful authentication attempts.
FIA_AFL.1	The action taken.
FIA_AFL.1	The reenablement of disabled nonadministrative accounts.
FIA_CMCC_EXT.1	CMC requests (generated or received) containing certificate requests or revocation requests.	Identifiers for all entities authenticating the request, including the entity providing client authentication for the CMC transport (if any). The submitted request
FIA_CMCC_EXT.1	CMC responses issued.	Any signed response.
FIA_CMCS_EXT.1	CMC requests (generated or received) containing certificate requests or revocation requests.	Identifiers for all entities authenticating the request, including the entity providing client authentication for the CMC transport (if any). The submitted request
FIA_CMCS_EXT.1	CMC responses issued.	Any signed response.
FIA_ESTC_EXT.1	EST requests (generated or received) containing certificate requests or revocation requests.	Identifiers for all entities authenticating the request, including the entity providing client authentication for the EST transport (if any). The submitted request.
FIA_ESTC_EXT.1	EST responses issued.	Any signed response.
FIA_ESTS_EXT.1	EST requests (generated or received) containing certificate requests or revocation requests.	Identifiers for all entities authenticating the request, including the entity providing client authentication for the EST transport (if any). The submitted request.
FIA_ESTS_EXT.1	EST responses issued.	Any signed response.
FIA_PMG_EXT.1	No events specified
FIA_PSK_EXT.1	No events specified
FIA_UAU.7	No events specified
FIA_X509_EXT.3	No events specified
FPT_ITT.1	No events specified
FPT_SKY_EXT.1	Access control violations for users involved in key share establishment or control.
FTP_ITC.1	Initiation of the trusted channel.
FTP_ITC.1	Termination of the trusted channel.
FTP_ITC.1	Failure of the trusted channel functions.	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

This is a selection-based component. Its inclusion depends upon selection from 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.2 Audit Data Retention

This is a selection-based component. Its inclusion depends upon selection from FAU_STG_EXT.1.1.

FAU_STG_EXT.2.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

This is a selection-based component. Its inclusion depends upon selection from 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

This is a selection-based component. Its inclusion depends upon selection from FCS_CDP_EXT.1.1.

FCS_CKM.1.1

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

RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3;,
ECC schemes using “NIST curves” [selection: P-256, P-384, P-521] that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4;,
FFC schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.1

] 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. If multiple schemes are supported, then the ST author should iterate this requirement to capture this capability. The scheme used will be chosen by the ST author from the 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 2048-bit DSA and 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 Activity

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-4 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

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.

Key Generation for Elliptic Curve Cryptography (ECC)

FIPS 186-4 ECC Key Generation Test
For each supported NIST curve, i.e., P-256, P-384 and P-521, 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-4 Public Key Verification (PKV) Test
For each supported NIST curve, i.e., P-256, 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.
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.

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

This is a selection-based component. Its inclusion depends upon selection from FCS_CDP_EXT.1.1.

FCS_CKM.2.1

The TSF shall in accordance with a specified cryptographic key algorithm ~~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 RSA-based key establishment schemes are described in Section 9 of NIST SP 800-56B Revision 1; however, Section 9 relies on implementation of other sections in SP 800-56B Revision 1.

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 Activity

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.

SP800-56B Key Establishment Schemes
If the TOE acts as a sender, the following assurance activity shall be performed to ensure the proper operation of every TOE supported combination of RSAbased key establishment scheme:

To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each combination of supported key establishment scheme and its options (with or without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTSOAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA public key, the plaintext keying material, any additional input parameters if applicable, the MacKey and MacTag if key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform a key establishment encryption operation on the TOE with the same inputs (in cases where key confirmation is incorporated, the test shall use the MacKey from the test vector instead of the randomly generated MacKey used in normal operation) and ensure that the outputted ciphertext is equivalent to the ciphertext in the test vector.
If the TOE acts as a receiver, the following assurance activities shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme:
To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each combination of supported key establishment scheme and its options (with our without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTSOAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA private key, the plaintext keying material (KeyData), any additional input parameters if applicable, the MacTag in cases where key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform the key establishment decryption operation on the TOE and ensure that the outputted plaintext keying material (KeyData) is equivalent to the plaintext keying material in the test vector. In cases where key confirmation is incorporated, the evaluator shall perform the key confirmation steps and ensure that the outputted MacTag is equivalent to the MacTag in the test vector.

The evaluator shall ensure that the TSS describes how the TOE handles decryption errors. In accordance with NIST Special Publication 800- 56B, the TOE must not reveal the particular error that occurred, either through the contents of any outputted or logged error message or through timing variations. If KTS-OAEP is supported, the evaluator shall create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800-56B section 7.2.2.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each. If KTS-KEMKWS is supported, the evaluator shall create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800- 56B section 7.2.3.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each.

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/Admin, FTP_TRP.1/Join, 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_EXT.1/2 Key Generation Key Encryption Keys

This is a selection-based component. Its inclusion depends upon selection from FCS_CDP_EXT.1.1.

FCS_CKM_EXT.1.1/2

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(1) 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 ...TODO

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(3), FCS_CKM_EXT.1(4), 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(1) will be included in the ST and the appropriate key wrap method will be chosen in the sixth selection.

FCS_CKM_EXT.1/3 Key Generation for Key Encryption Keys (TOE Key Archival)

This is a selection-based component. Its inclusion depends upon selection from FCS_CDP_EXT.1.1.

FCS_CKM_EXT.1.1/3

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 [selection: 128-bit, 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 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 is generated from two or more shares. The generation of the shares themselves is specified in FCS_CKM_EXT.1(4), 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.

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 preservations.

FCS_CKM_EXT.1/4 Generation of Key Shares

This is a selection-based component. Its inclusion depends upon selection from FCS_CDP_EXT.1.1.

FCS_CKM_EXT.1.1/4

The TSF shall be able to [selection: generate, invoke interfaces provided by the Operational Environment to generate] key shares of strength [greater than or equal to the security strength of the KEK defined in FCS_CKM_EXT.1(3)] for the key sharing mechanism indicated in FCS_CKM_EXT.1(3).

FCS_CKM_EXT.4 Cryptographic Key Destruction

This is a selection-based component. Its inclusion depends upon selection from FCS_CDP_EXT.1.1.

FCS_CKM_EXT.4.1

The TSF shall [selection: destroy, invoke interfaces provided by the Operational Environment to destroy] all cryptographic keys and critical security parameters which are not permanently protected from export by hardware when no longer required, in accordance with the 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
]

]

FCS_CKM_EXT.4.2

The TSF shall [selection: destroy, invoke interfaces provided by the Operational Environment to destroy] all plaintext keying material 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.

Evaluation Activity

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_EXT.4.1), the evaluator shall attempt to perform the following tests:

Test 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:

Load the instrumented TOE build in a debugger.

Record the value of the key in the TOE subject to clearing.

Cause the TOE to perform a normal cryptographic processing with the key from #1.

Cause the TOE to clear the key.

Cause the TOE to stop the execution but not exit.

Cause the TOE to dump the entire memory footprint of the TOE into a binary file.

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 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.5 Public Key Integrity

This is a selection-based component. Its inclusion depends upon selection from 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(2)), keyed hashes (in accordance with FCS_COP.1(4))].

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

This is a selection-based component. Its inclusion depends upon selection from 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(1), FCS_CKM.1] using the KEK generated in accordance with FCS_CKM_EXT.1(3).

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(1), FCS_CKM.1] using the KEK generated in accordance with FCS_CKM_EXT.1(3).

Application Note: This requirement is required when ‘key sharing mechanisms…’ is selected in FPT_SKY_EXT.1., 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(3).

FCS_CKM_EXT.7 Key Generation for KEKs

This is a selection-based component. Its inclusion depends upon selection from FCS_CDP_EXT.1.1.

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(2).

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..TODO.

Either asymmetric or symmetric keys are allowed; the ST author makes the selection appropriate for the device. Symmetric keys must be of size 128 or 256 bits in order to correspond with FCS_COP.1(1). 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(2) 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

This is a selection-based component. Its inclusion depends upon selection from FCS_CDP_EXT.1.1.

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 is included whenever both FCS_CKM_EXT.1(2) and FCS_CKM_EXT.7 are included in the ST. TODO TODO !!!!

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/1 Cryptographic Operation (AES Encryption/Decryption)

This is a selection-based component. Its inclusion depends upon selection from FCS_CDP_EXT.1.1.

FCS_COP.1.1/1

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

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

Application Note: For the third selection of FCS_COP.1.1(1), the ST author should choose the mode or modes in which AES operates. For the fourth selection, the ST author should choose the key sizes besides 128-bit that are supported by this functionality.

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 selectionbased cryptographic protocols (e.g. if FCS_IPSEC_EXT.1 is selected, CBC and/or GCM must be selected depending on the selections made in FCS_IPSEC_EXT.1.4).

Evaluation Activity

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:

Eash 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 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 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 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 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/2 Cryptographic Operation (Cryptographic Signature)

This is a selection-based component. Its inclusion depends upon selection from FCS_CDP_EXT.1.1.

FCS_COP.1.1/2

The TSF shall [cryptographic signature services] in accordance with the following specified cryptographic algorithms ~~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 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 Activity

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 and 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.

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-4 ECDSA Key Generation Test

For each supported NIST curve, i.e., P-256, P-384 and P-521, 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-4 Public Key Verification (PKV) Test

For each supported NIST curve, i.e., P-256, 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-4 Signature Generation Test

For each supported NIST curve (i.e., P-256, P-384 and P-521) 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.

ECDSA FIPS 186-4 Signature Verification Test

For each supported NIST curve (i.e., P-256, 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 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.

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/3 Cryptographic Operation (Cryptographic Hashing)

This is a selection-based component. Its inclusion depends upon selection from FCS_CDP_EXT.1.1.

FCS_COP.1.1/3

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

Application Note: In future versions of this document, SHA-1 may be removed as an option. SHA-1 for generating digital signatures was disallowed after December 2013, and SHA1 for verification of digital signatures is strongly discouraged as there may be risk in accepting these signatures.

The selection of the hashing algorithm must correspond to the selection of the message digest size; for example, if SHA-1 is chosen, then the only valid message digest size selection would be 160 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 Activity

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/4 Cryptographic Operation (Keyed-Hash Message Authentication)

This is a selection-based component. Its inclusion depends upon selection from FCS_CDP_EXT.1.1.

FCS_COP.1.1/4

The TSF shall [keyed hash message authentication] in accordance with a specified cryptographic algorithm 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(1).

In future versions of this document, SHA-1 may be removed as an option. SHA-1 for generating digital signatures was disallowed after December 2013, and SHA1 for verification of digital signatures is strongly discouraged as there may be risk in accepting these signatures.

FCS_HTTPS_EXT.1 HTTPS Protocol

This is a selection-based component. Its inclusion depends upon selection from 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

This is a selection-based component. Its inclusion depends upon selection from 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.

Evaluation Activity

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.
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.
Tests
The evaluator uses the operational guidance to configure the TOE to carry out the following tests:

Test 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 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.

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-CBC-128, AES-CBC-256 (both specified by RFC 3602) and [selection: AES-GCM-128 (specified in RFC 4106), AES-GCM-256 (specified in RFC 4106), no other algorithms] together with a Secure Hash Algorithm (SHA)-based HMAC.

FCS_IPSEC_EXT.1.5

The TSF shall implement the protocol: [selection:

IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFCs 2407, 2408, 2409, RFC 4109, [selection: no other RFCs for extended sequence numbers, RFC 4304 for extended sequence numbers], and [selection: no other RFCs for hash functions, RFC 4868 for hash functions]; ,
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 for IKEv1 or IKEv2, the ST author shall select RFC 4868. If the ST author selects IKEv1, FCS_IPSEC_EXT.1.15 must also be included in the ST.

FCS_IPSEC_EXT.1.6

The TSF shall ensure the encrypted payload in the [selection: IKEv1, IKEv2] protocol uses the cryptographic algorithms AES-CBC-128, AES-CBC-256 as specified in RFC 3602 and [selection: AES-GCM-128, AES-GCM-256 as specified in RFC 5282, no other algorithm].

Application Note: AES-GCM-128 and AES-GCM-256 may only be selected if IKEv2 is also selected, as there is no RFC defining AES-GCM for IKEv1.

FCS_IPSEC_EXT.1.7

The TSF shall ensure that [selection:

IKEv1 Phase 1 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
] ,
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 the IKEv1 requirements or IKEv2 requirements (or both, depending on the selection in FCS_IPSEC_EXT.1.5). 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.

Evaluation Activity

Guidance
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.
Tests
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 for each version of IKE selected in the FCS_IPSEC_EXT.1.5 protocol selection:

Test 1: (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 2: (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.

FCS_IPSEC_EXT.1.8

The TSF shall ensure that [selection:

IKEv1 Phase 2 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
] ,
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
]

Evaluation Activity

Guidance
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.
Tests
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 for each version of IKE selected in the FCS_IPSEC_EXT.1.5 protocol selection:

Test 1: (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 2: (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.

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_EXT.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 [selection: IKEv1, IKEv2]] exchanges of length [selection:

[assignment: security strength associated with the negotiated Diffie-Hellman group],
at least 128 bits in size and at least half the output size of the negotiated pseudorandom function (PRF) hash

];

Application Note: The ST author must select the second option for nonce lengths if IKEv2 is also selected (as this is mandated in RFC 5996). The ST author may select either option for IKEv1.

For the first option for nonce lengths, 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. 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.

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 14 (2048-bit MODP), DH Group 19 (256-bit Random ECP), DH Group 24 (2048-bit MODP with 256-bit POS), DH Group 20 (384-bit Random ECP), no other DH groups].

Application Note: The selection is used to specify additional DH groups supported. This applies to IKEv1 and IKEv2 exchanges. 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 [selection: IKEv1 Phase 1, 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 [selection: IKEv1 Phase 2, IKEv2 CHILD_SA] connection.

Application Note: The ST author chooses either or both of the IKE selections based on what is implemented by the TOE. Obviously, the IKE version(s) chosen should be consistent not only in this element, but with other choices for other elements in this component. 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).

Evaluation Activity

TSS
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(2) 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.
Guidance
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”.
Tests
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 1: 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 2: [conditional] The evaluator shall generate a pre-shared key offTOE and use it, as indicated in the operational guidance, to establish an IPsec connection with the peer.

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].

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 Activity

TSS
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 ensure that the operational guidance includes the configuration of the reference identifier(s) for the peer.
Tests
For each supported identifier type (excluding DNs), the evaluator shall repeat the following tests:

Test 1: 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 2: 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 3: (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 4: (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 5: (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 6: (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_EXT.1 Cryptographic Random Bit Generation

This is a selection-based component. Its inclusion depends upon selection from FCS_CDP_EXT.1.1.

FCS_RBG_EXT.1.1

The TSF shall [selection: perform, invoke interfaces in the operational environment to perform] all deterministic random bit generation (RBG) services in accordance with NIST Special Publication 800-90A using [selection: Hash_DRBG (any), HMAC_DRBG (any), CTR_DRBG (AES)].

FCS_RBG_EXT.1.2

The deterministic RBG shall be seeded by an entropy source that accumulates entropy from [selection: a software-based noise source, TSF hardware-based noise source, an Operational Environment-based noise source] with a minimum of [selection: 128 bits, 256 bits] of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and authorization factors that it will generate.

Application Note: 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 must also ensure that any underlying functions are included in the baseline requirements for the TOE.

For the selection in FCS_RBG_EXT.1.2, the ST author selects the appropriate number of bits of entropy that corresponds to the greatest security strength of the algorithms included in the ST. Security strength is defined in Tables 2 and 3 of NIST SP 800-57A. For example, if the implementation includes 2048-bit RSA (security strength of 112 bits), AES 128 (security strength 128 bits), and HMAC-SHA-256 (security strength 256 bits), then the ST author would select 256 bits.

The ST author may select either software or hardware noise sources for a TOEimplemented noise source, or an Operational Environment noise source. A hardware noise source is a component that produces data that cannot be explained by a deterministic rule, due to its physical nature. In other words, a hardware based noise source generates sequences of random numbers from a physical process that cannot be predicted. For example, a sampled ring oscillator consists of an odd number of inverter gates chained into a loop, with an electrical pulse traveling from inverter to inverter around the loop. The inverters are not clocked, so the precise time required for a complete circuit around the loop varies slightly as various physical effects modify the small delay time at each inverter on the line to the next inverter. This variance results in an approximate natural frequency that contains drift and jitter over time. The output of the ring oscillator consists of the oscillating binary value sampled at a constant rate from one of the inverters – a rate that is significantly slower than the oscillator’s natural frequency.

Evaluation Activity

TSS
The evaluator shall examine the TSS to ensure it describes the deterministic random bit generation services provided by either the TSF or the Operational Environment, including a description of the entropy source.
Guidance
If any part of the deterministic RBG services is configurable, the evaluator shall ensure that the operational guidance provides clear instructions for how to configure them, including those that pertain to the Operational Environment, if applicable.
Tests
Documentation shall be produced—and the evaluator shall perform the activities—in accordance with Annex D, Entropy Documentation and Assessment, regardless of whether the entropy source is implemented by the TOE or the Operational Environment. Note that this is only applicable if the TOE implements or directly invokes the DRBG. If this is not the case, then FCS_RBG_EXT.1 should not be included in the ST, as outlined in the application note for FCS_CDP_EXT.1.

For RBG implementations in the TSF, the evaluator shall also perform the following tests, depending on the standard to which the RBG conforms.

Implementations Conforming to NIST Special Publication 800-90A

The evaluator shall perform 15 trials for the RBG implementation. If the RBG 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 RBG functionality.

If the RBG has prediction resistance enabled, each trial consists of

instantiate DRBG,

generate the first block of random bits,

generate a second block of random bits,

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 RBG does not have prediction resistance, each trial consists of

instantiate DRBG,

generate the first block of random bits,

reseed,

generate a second block of random bits,

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 paragraphs contain 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 df 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 <= 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.

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_TLSC_EXT.1 TLS Client Protocol

This is a selection-based component. Its inclusion depends upon selection from FTP_ITC.1.1, FTP_TRP.1.1.

FCS_TLSC_EXT.1.1

The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] supporting the following ciphersuites: [selection:

TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268,
TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492,
TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246,
TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246,
TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246,
TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289

] and no other ciphersuite.

Application Note: The ciphersuites to be tested in the evaluated configuration are limited by this requirement. The ST author should select the ciphersuites that are supported. It is necessary to limit the ciphersuites that can be used in an evaluated configuration administratively on the server in the test environment. The Suite B algorithms listed above (RFC 6460) are the preferred algorithms for implementation.

These requirements will be revisited as new TLS versions are standardized by the IETF.

If any ciphersuites are selected using ECDHE, then FCS_TLSC_EXT.1.5 is required.

In a future version of this PP TLS v1.2 will be required for all TOEs.

It is recognized that RFC 5246 mandates the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA, but use of SHA-1 for digital signature generation is no longer recommended (see NIST SP 800-131A rev-1 and SP 800- 78-4). Subsequent revisions of the PP will not include SHA-1.

Evaluation Activity

TSS
The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the ciphersuites supported are specified. The evaluator shall check the TSS to ensure that the ciphersuites specified include those listed for this component.
Tests

Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites specified by the requirement. This connection may be established as part of the establishment of a higher-level protocol, e.g., as part of an EAP session. It is sufficient to observe the successful negotiation of a ciphersuite to satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic in an attempt to discern the ciphersuite being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES).

Test 2: The evaluator shall attempt to establish the connection using a server with a server certificate that contains the Server Authentication purpose in the extendedKeyUsage field and verify that a connection is established. The evaluator will then verify that the client rejects an otherwise valid server certificate that lacks the Server Authentication purpose in the extendedKeyUsage field and a connection is not established. Ideally, the two certificates should be identical except for the extendedKeyUsage field.

Test 3: The evaluator shall send a server certificate in the TLS connection that the does not match the server-selected ciphersuite (for example, send a ECDSA certificate while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite or send a RSA certificate while using one of the ECDSA ciphersuites.) The evaluator shall verify that the TOE disconnects after receiving the server’s Certificate handshake message.

Test 4: The evaluator performs the following modifications to the traffic:

Change the TLS version selected by the server in the Server Hello to a non-supported TLS version (for example 1.3 represented by the two bytes 03 04) and verify that the client rejects the connection.

Modify at least one byte in the server’s nonce in the Server Hello handshake message, and verify that the client rejects the Server Key Exchange handshake message (if using a DHE or ECDHE ciphersuite) or that the server denies the client’s Finished handshake message.

Modify the server’s selected ciphersuite in the Server Hello handshake message to be a ciphersuite not presented in the Client Hello handshake message. The evaluator shall verify that the client rejects the connection after receiving the Server Hello.

[conditional] If an ECDHE or DHE ciphersuite is selected, modify the signature block in the Server’s Key Exchange handshake message, and verify that the client rejects the connection after receiving the Server Key Exchange message.

Modify a byte in the Server Finished handshake message, and verify that the client sends a fatal alert upon receipt and does not send any application data.

Send a garbled message from the Server after the Server has issued the ChangeCipherSpec message and verify that the client denies the connection.

FCS_TLSC_EXT.1.2

The TSF shall verify that the presented identifier matches the reference identifier according to RFC 6125.

Application Note: The rules for verification of identity are described in Section 6 of RFC 6125. The reference identifier is established by an authorized user, by configuration (e.g., configuring the name of an authentication server), or by an application (e.g., a parameter of an API) as described in the TSS. . Based on a singular reference identifier’s source domain and application service type (e.g., HTTP, SIP, LDAP), the client establishes all reference identifiers which are acceptable, such as a Common Name for the Subject Name field of the certificate and a (case-insensitive) DNS name, URI name, and Service Name for the Subject Alternative Name field. The client then compares this list of all acceptable reference identifiers to the presented identifiers in the TLS server’s certificate.

The preferred method for verification is the Subject Alternative Name using DNS names, URI names, or Service Names. Verification using the Common Name is required for the purposes of backwards compatibility. Additionally, support for use of IP addresses in the Subject Name or Subject Alternative name is discouraged as against best practices but may be implemented. Finally, the client should avoid constructing reference identifiers using wildcards. However, if the presented identifiers include wildcards, the client must follow the best practices regarding matching; these best practices are captured in the assurance activity.

Evaluation Activity

TSS
The evaluator shall ensure that the TSS describes the client’s method of establishing all reference identifiers from the administrator/applicationconfigured reference identifier, including which types of reference identifiers are supported (e.g., Common Name, DNS Name, URI Name, Service Name, or other application-specific Subject Alternative Names) and whether IP addresses and wildcards are supported. The evaluator shall ensure that this description identifies whether and the manner in which certificate pinning is supported or used by the TOE.
Tests
The evaluator shall configure the reference identifier according to the AGD guidance and perform the following tests during a TLS connection:

Test 1: The evaluator shall present a server certificate that does not contain an identifier in either the Subject Alternative Name (SAN) or Common Name (CN) that matches the reference identifier. The evaluator shall verify that the connection fails.

Test 2: The evaluator shall present a server certificate that contains a CN that matches the reference identifier, contains the SAN extension, but does not contain an identifier in the SAN that matches the reference identifier. The evaluator shall verify that the connection fails. The evaluator shall repeat this test for each supported SAN type.

Test 3: The evaluator shall present a server certificate that contains a CN that matches the reference identifier and does not contain the SAN extension. The evaluator shall verify that the connection succeeds.

Test 4: The evaluator shall present a server certificate that contains a CN that does not match the reference identifier but does contain an identifier in the SAN that matches. The evaluator shall verify that the connection succeeds.

Test 5: The evaluator shall perform the following wildcard tests with each supported type of reference identifier:

The evaluator shall present a server certificate containing a wildcard that is not in the left-most label of the presented identifier (e.g., foo.*.example.com) and verify that the connection fails.

The evaluator shall present a server certificate containing a wildcard in the left-most label (e.g., *.example.com). The evaluator shall configure the reference identifier with a single left-most label (e.g., foo.example.com) and verify that the connection succeeds. The evaluator shall configure the reference identifier without a left-most label as in the certificate (e.g., example.com) and verify that the connection fails. The evaluator shall configure the reference identifier with two left-most labels (e.g., bar.foo.example.come) and verify that the connection fails.

Test 6: [conditional] If URI or Service name reference identifiers are supported, the evaluator shall configure the DNS name and the service identifier. The evaluator shall present a server certificate containing the correct DNS name and service identifier in the URIName or SRVName fields of the SAN and verify that the connection succeeds. The evaluator shall repeat this test with the wrong service identifier (but correct DNS name) and verify that the connection fails.

Test 7: [conditional] If pinned certificates are supported the evaluator shall present a certificate that does not match the pinned certificate and verify that the connection fails.

FCS_TLSC_EXT.1.3

The TSF shall establish a trusted channel only if the peer certificate is valid.

Application Note: Validity is determined by the identifier verification, certificate path, the expiration date, and the revocation status in accordance with RFC 5280. Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1.

FCS_TLSC_EXT.1.4

The TSF shall present the Supported Elliptic Curves Extension in the Client Hello with the following NIST curves: [selection: secp256r1, secp384r1, secp521r1] and no other curves.

Application Note: If ciphersuites with elliptic curves were selected in FCS_TLSC_EXT.1.1, this component is required.

This requirement limits the elliptic curves allowed for authentication and key agreement to the NIST curves from FCS_COP.1(2) and FCS_CKM.1 and FCS_CKM.2. This extension is required for clients supporting Elliptic Curve ciphersuites.

FCS_TLSS_EXT.1 TLS Server Protocol

This is a selection-based component. Its inclusion depends upon selection from FTP_ITC.1.1, FTP_TRP.1.1, FCO_NRR_EXT.2.1.

FCS_TLSS_EXT.1.1

The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] supporting the following ciphersuites: [selection:

TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268,
TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492,
TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246,
TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246,
TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246,
TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289

] and no other ciphersuite.

Application Note: The ciphersuites to be tested in the evaluated configuration are limited by this requirement. The ST author should select the ciphersuites that are supported. It is necessary to limit the ciphersuites that can be used in an evaluated configuration administratively on the server in the test environment. The Suite B algorithms listed above (RFC 6460) are the preferred algorithms for implementation.

These requirements will be revisited as new TLS versions are standardized by the IETF.

It is recognized that RFC 5246 mandates the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA, but use of SHA-1 for digital signature generation is no longer recommended (see NIST SP 800-131A rev-1 and SP 800- 78-4). Subsequent revisions of the PP will not include SHA-1.

Evaluation Activity

TSS
The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the ciphersuites supported are specified. The evaluator shall check the TSS to ensure that the ciphersuites specified are identical to those listed for this component.
Guidance
The evaluator shall also check the operational guidance to ensure that it contains instructions on configuring the TOE so that TLS conforms to the description in the TSS (for instance, the set of ciphersuites advertised by the TOE may have to be restricted to meet the requirements).
Tests

Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites specified by the requirement. This connection may be established as part of the establishment of a higher-level protocol, e.g., as part of an EAP session. It is sufficient to observe the successful negotiation of a ciphersuite to satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic in an attempt to discern the ciphersuite being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES).

Test 2: The evaluator shall send a Client Hello to the server with a list of ciphersuites that does not contain any of the ciphersuites in the server’s ST and verify that the server denies the connection. Additionally, the evaluator shall send a Client Hello to the server containing only the TLS_NULL_WITH_NULL_NULL ciphersuite and verify that the server denies the connection.

Test 3: The evaluator shall use a client to send a key exchange message in the TLS connection that the does not match the server-selected ciphersuite (for example, send an ECDHE key exchange while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite or send a RSA key exchange while using one of the ECDSA ciphersuites.) The evaluator shall verify that the TOE disconnects after the receiving the key exchange message.

Test 4: The evaluator shall perform the following modifications to the traffic:

Modify at a byte in the client’s nonce in the Client Hello handshake message, and verify that the server rejects the client’s Certificate Verify handshake message (if using mutual authentication) or that the server denies the client’s Finished handshake message.

[conditional] If an ECDHE or DHE ciphersuite is selected, modify the signature block in the Client’s Key Exchange handshake message, and verify that the server rejects the client’s Certificate Verify handshake message (if using mutual authentication) or that the server denies the client’s Finished handshake message.

Modify a byte in the Client Finished handshake message, and verify that the server rejects the connection and does not send any application data.

After generating a fatal alert by sending a Finished message from the client before the client sends a ChangeCipherSpec message, send a Client Hello with the session identifier from the previous test, and verify that the server denies the connection.

Send a garbled message from the client after the client has issued the ChangeCipherSpec message and verify that the Server denies the connection.

FCS_TLSS_EXT.1.2

The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS 1.0 and [selection: TLS 1.1, TLS 1.2, no other TLS versions].

Application Note: All SSL versions and TLS v1.0 are denied. Any TLS versions not selected in FCS_TLSS_EXT.1.1 should be selected here.

FCS_TLSS_EXT.1.3

The TSF shall generate key agreement parameters using RSA with key size 2048 bits and [selection: 3072 bits, 4096 bits, no other size] and [selection:

over NIST curves [selection: secp256r1, secp384r1, secp521r1] and no other curves,
DiffieHellman parameters of size 2048 bits and [selection: 3072 bits, no other size],
no other

Application Note: If the ST lists a DHE or ECDHE ciphersuite in FCS_TLSS_EXT.1.1, the ST must include the Diffie-Hellman or NIST curves selection in the requirement. FMT_SMF.1 requires the configuration of the key agreement parameters in order to establish the security strength of the TLS connection.

FCS_TLSS_EXT.1.4

The TSF shall present the Supported Elliptic Curves Extension in the Client Hello with the following NIST curves: [selection: secp256r1, secp384r1, secp521r1] and no other curves.

Application Note: If ciphersuites with elliptic curves were selected in FCS_TLSS_EXT.1.1, this component is required. This requirement limits the elliptic curves allowed for authentication and key agreement to the NIST curves from FCS_COP.1(2), FCS_CKM.1, and FCS_CKM.2. This extension is required for clients supporting Elliptic Curve ciphersuites.

B.5 Class: User Data Protection (FDP)

FDP_CRL_EXT.1 Certificate Revocation List Validation

This is a selection-based component. Its inclusion depends upon selection from FIA_UAU_EXT.1.1.

FDP_CRL_EXT.1.1

A TSF that issues CRLs shall verify that all mandatory fields in any CRL issued contain values in accordance with ITU-T Recommendation X.509. At a minimum, the following items shall be validated:

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(2).
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

This is a selection-based component. Its inclusion depends upon selection from 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: 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 Extended Package for Secure Shell.

FDP_OCSPG_EXT.1 OCSP Basic Response Generation

This is a selection-based component. Its inclusion depends upon selection from FIA_UAU_EXT.1.1.

FDP_OCSPG_EXT.1.1

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(2).
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.

B.6 Class: Identification and Authentication (FIA)

FIA_AFL.1 Authentication Failure Handling

This is a selection-based component. Its inclusion depends upon selection from 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: choose one of: 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 Activity

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 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 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

This is a selection-based component. Its inclusion depends upon selection from FCO_NRR_EXT.2.1.

FIA_CMCC_EXT.1.1

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 Activity

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

This is a selection-based component. Its inclusion depends upon selection from FCO_NRR_EXT.2.1.

FIA_CMCS_EXT.1.1

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(2)
Encryption for EnvelopedData is performed in accordance with FCS_COP.1(1)
PasswordRecipientInfo for EnvelopedData or AuthenticatedData is derived in accordance with FCS_COP.1(5)
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(3)
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(4)
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 Activity

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 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 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 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 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 1:

[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 2:

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 3: 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 4: 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 1: The evaluator shall configure the CA-1 TSF to use a certificate profile requiring extensions not used in Test Groups A or B.

Test 2: 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 3: 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 4: 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 1: 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 1: 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

This is a selection-based component. Its inclusion depends upon selection from FCO_NRR_EXT.2.1.

FIA_ESTC_EXT.1.1

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 TLSauthenticated EST CA certificate request in accordance with RFC 7030 section 4.1.2 and FCS_TLSC_EXT.2

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., 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., Certificate-based authentication in accordance with RFC 7030 section 3.3.2 and FCS_TSL_EXT.2 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 Activity

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 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 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 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 4: The evaluator shall generate a re-enrollement 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 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

This is a selection-based component. Its inclusion depends upon selection from FCO_NRR_EXT.2.1.

FIA_ESTS_EXT.1.1

The TSF shall use the Enrollment over Secure Transport (EST) protocol as specified in RFC 7030 to receive, process, and respond to certificate simple enrollment requests from authorized clients.

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(3) 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].

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.

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(3) 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 Activity

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 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 enrolment 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 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 enrolment 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 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 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 5: The evaluator shall modify the EST client or setup a man-inthe-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

This is a selection-based component. Its inclusion depends upon selection from 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

This is a selection-based component. Its inclusion depends upon selection from .

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 preshared 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 Activity

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 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 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 3: [conditional]: If the TOE supports bit-based pre-shared keys but does not generate such keys, the evaluator shall obtain a bitbased 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 4: [conditional]: If the TOE supports bit-based pre-shared keys and does generate such keys, the evaluator shall generate a bitbased 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

This is a selection-based component. Its inclusion depends upon selection from FIA_UAU_EXT.1.1.

FIA_UAU.7.1

The TSF shall provide only to the user while the authentication is in progress.

FIA_X509_EXT.3 X509 Certificate Request

This is a selection-based component. Its inclusion depends upon selection from FIA_UAU_EXT.1.1.

FIA_X509_EXT.3.1

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

This is a selection-based component. Its inclusion depends upon selection from 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_COPbased 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

This is a selection-based component. Its inclusion depends upon selection from 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: 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 Extended Package for Secure Shell.

FPT_SKY_EXT.1 Key Share Access

This is a selection-based component. Its inclusion depends upon selection from FIA_UAU_EXT.1.1.

FPT_SKY_EXT.1.1

The [selection: TSF, Operational Environment] shall ensure that key shares generated in accordance with FCS_CKM_EXT.1(4) 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(3), FCS_CKM_EXT.1(4), FCS_CKM_EXT.6, and FPT_SKY_EXT.2” is selected in FPT_SKY_EXT.1.1. It should be noted that this protection can be accomplished via FCS_COP.1(5); if it is, then that SFR should be included in the ST.

B.8 Class: Trusted Path/Channels (FTP)

FTP_ITC.1 Inter-TSF Trusted Channel

This is a selection-based component. Its inclusion depends upon selection from FIA_UAU_EXT.1.1.

FTP_ITC.1.1

The TSF shall to 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: 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 Extended Package for Secure Shell.

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 Activity

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 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 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 3: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data is not sent in plaintext.

Test 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 - 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 D - References

Identifier	Title
[CC]	Common Criteria for Information Technology Security Evaluation - Part 1: Introduction and General Model, CCMB-2017-04-001, Version 3.1, Revision 5, April 2017. Part 2: Security Functional Components, CCMB-2017-04-002, Version 3.1, Revision 5, April 2017. Part 3: Security Assurance Components, CCMB-2017-04-003, Version 3.1, Revision 5, April 2017.
[CC]	Common Criteria for Information Technology Security Evaluation - Part 1: Introduction and General Model, CCMB-2012-09-001, Version 3.1 Revision 5, April 2017. Part 2: Security Functional Components, CCMB-2012-09-002, Version 3.1 Revision 5, April 2017. Part 3: Security Assurance Components, CCMB-2012-09-003, Version 3.1 Revision 5, April 2017.
[CEM]	Common Evaluation Methodology for Information Technology Security - Evaluation Methodology, CCMB-2012-09-004, Version 3.1, Revision 5, April 2017.
[IR7924]	Second Draft NIST IR 7924, Reference Certificate Policy, May 2014.

Appendix E - 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
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
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
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
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
rDSA	RSA Digital Signature Algorithm

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

2 Conformance Claims

3 Security Problem Description

3.1 Threats

3.2 Assumptions

3.3 Organizational Security Policies

4 Security Objectives

4.1 Security Objectives for the TOE

4.2 Security Objectives for the Operational Environment

4.3 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.4 Prevention of Audit Data Loss

FAU_STG_EXT.1 External Audit Trail Storage

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/1 Management of Security Functions Behavior (Administrator Functions)

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

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

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

FMT_MOF.1/5 Management of Security Functions Behavior (Autitor 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

AGD_OPE.1 Operational User Guidance (AGD_OPE.1)

Developer action elements:

Content and presentation elements:

Evaluator action elements: