CAs Inside the FBCA
No.	Section Reference	Requirement Description	Test Description	Completed	Not Completed	Comments
1	FBCA CP Sections 6.1.9, 7.1 FBCA Interoperability Guidelines	Generate X.509 v 3 certificates in compliance with attached certificate profile
2	FBCA Inter- operability Guidelines	Assert, in the certificatePolicies extension field, up to all four FBCA Certificate Policy OIDs within a single X.509 cross-certificate
3	FBCA Inter- operability Guidelines	Map agency-specific levels of assurance to the levels of assurance present in the certificatePolicies extension field; that mapping will be expressed in the policyMappings extension of the FBCA cross-certificates
4	FBCA Inter- operability Guidelines	Export, at a minimum, the reverse element [cross-certificates it has signed/issued] in DER encoding
5	FBCA CP Section 7.2; FBCA Inter- operability Guidelines	Generate x.509v2 CARL/CRL in compliance with attached profile
6	FBCA CP Sections 1.1.1.3; 2.1.5; 4.4.1.2; 4.4.3.1; 4.5.1; 6.1.4 FBCA Interoperability Guidelines	Support off-line posting to an X.500 LDAP v2 or better directory: Self-signed certificates [Export self-signed certificates to a file as a DER-encoded object or in an LDIF file.] [PeerLogic i500 ]{Export self-signed certificates in such manner that they can be imported into the Peerlogic i500 directory
7	FBCA CP Sections 1.1.1.3; 2.1.5; 4.4.1.2; 4.4.3.1; 4.5.1; 6.1.4, FBCA Interoperability Guidelines	Support off-line posting to an X.500 LDAP v2 or better directory: All cross certificate pairs generated [Export cross certificate pairs to files as DER-encoded objects or as an LDIF file.] [PeerLogic i500]
8	FBCA CP Sections 1.1.1.3; 2.1.5; 4.4.1.2; 4.4.3.1; 4.5.1; 6.1.4, FBCA Interoperability Guidelines	Support off-line posting to an X.500 LDAP v2 or better directory: An Authority Revocation List (ARL) or Certificate Revocation Lists (CRLs) covering certificates revoked.[Export Authority Revocation Lists (ARL) or Certificate Revocation Lists (CRLs) as DER-encoded objects or as an LDIF file. ] [PeerLogic i500]
9	FBCA Inter- operability Guidelines	Generate and sign certificates contain X.500 DN [ where the issuer DN consists of the following X.520 naming elements: C; O; and OU.]
10	FBCA CP Section 3.1.1	Generate and sign certificates contain X.500 DCN elements [where the subject DN contains X.520 naming elements (at least C, O, and OU), the domain component naming element (dc), or a combination of the two.]
11	FBCA CP Section 3.1.1	Generate and sign certificates that have name constraints asserted
12a	FBCA CP Section 3.2.1, 4.7, 6.3.2	Support key rollover by generating a self-issued certificate signed by the old private key whose subjectPublicKeyInfo field contains the  new public key.
12	FBCA CP Sections 3.2.1, 4.7, 6.3.2	Support key rollover by generating a self-issued certificate signed by the new private key whose subjectPublicKeyInfo field contains the  old public key.
13	FBCA CP Section 3.2.1	Generate a certificate  that has the same characteristics and level as the old one, except that the new certificate has a new, different public key (corresponding to a new, different private key) and a different serial number and a different validity period
14	FBCA CP Section 3.2.2	Generate a new certificate with the same name, key, and other information as the old one, but a new, extended validity period and a new serial number
15	FBCA CP Section 3.2.3	Generate a new certificate that has the same or a different key and a different serial number, and that it differs in one or more other fields, from the old certificate
16	FBCA CP Sections 4.1, 4.2	Manually check a new certificate to ensure each field and extension is properly populated with the correct information
17	FBCA CP Section 4.2.1	Hardware tokens containing the private signature keys may be backed-up in accordance with security audit requirements defined Section 4.5.1
18	FBCA CP Sections 4.4.1, 4.4.1.2	Revoke a certificate by placing its serial number and reason for revocation on a CARL/CRL .  Revoked certificates shall be included on all new publications of the certificate status information until the certificates expire
18a	FBCA CP Sections 4.4.1, 4.4.1.2	After key rollover, the CA must be able to publish certificate status information in one of the following two manners: 1. the CA generates two CRLs, one with each key pair, that cover all unexpired certificates issued by the CA (regardless of key pair) 2. the CA generates two or more CRLs distinguished by the IDP extension; each CRL IDP covers all unexpired certificates that contain the corresponding CDP extension (for Microsoft compatibility, the CRL should be signed with the same key pair as the certificates)
19	FBCA CP Section 4.4.3	Check the contents of CARLs and CRLs before issuance to ensure that all information is correct
20	FBCA CP Sections 4.4.3.1, 4.4.7	Manually issue a new CARL/CRL to support required generation in the event of Agency CA key loss or compromise
21	FBCA CP Section 4.5.1	At a minimum, each audit record shall include the following (either recorded automatically or manually for each auditable event): the type of event
22	FBCA CP Section 4.5.1	At a minimum, each audit record shall include the following (either recorded automatically or manually for each auditable event): the date and time the event occurred
23	FBCA CP Section 4.5.1	At a minimum, each audit record shall include the following (either recorded automatically or manually for each auditable event): a success or failure indicator when executing the FBCA signing process
24	FBCA CP Section 4.5.1	At a minimum, each audit record shall include the following (either recorded automatically or manually for each auditable event): a success or failure indicator when performing certificate revocation
25	FBCA CP Section 4.5.1	At a minimum, each audit record shall include the following (either recorded automatically or manually for each auditable event): the identity of the entity and/or operator that caused the event
26	FBCA CP Sections 4.5.1, 6.5.1	Auditable events for purposes of this test, are as follows:
27	FBCA CP Sections 4.5.1, 6.5.1	Any changes to the Audit parameters, e.g., audit frequency, type of event audited
28	FBCA CP Sections 4.5.1, 6.5.1	Any attempt to delete or modify the Audit logs
29	FBCA CP Sections 4.5.1, 6.5.1	Successful and unsuccessful attempts to assume a role
30	FBCA CP Sections 4.5.1, 6.5.1	Change in the value of maximum authentication attempts
31	FBCA CP Sections 4.5.1, 6.5.1	Maximum number of unsuccessful authentication attempts during user login
32	FBCA CP Sections 4.5.1, 6.5.1	An Administrator unlocks an account that has been locked as a result of unsuccessful authentication attempts
33	FBCA CP Sections 4.5.1, 6.5.1	An Administrator changes the type of authenticaton, e.g., from password to biometrics
34	FBCA CP Sections 4.5.1, 6.5.1	Whenever the FBCA generates a key. (Not mandatory for single session or one-time use symmetric keys)
35	FBCA CP Sections 4.5.1, 6.5.1	The loading of Component private keys
36	FBCA CP Sections 4.5.1, 6.5.1	All access to certificate subject private keys retained within the FBCA  for key recovery purposes (if key recovery is supported)
37	FBCA CP Sections 4.5.1, 6.5.1	All changes to the trusted public keys, including additions and deletions
38	FBCA CP Sections 4.5.1, 6.5.1	The export of private keys (keys used for a single session or message are excluded)
39	FBCA CP Sections 4.5.1, 6.5.1	All certificate requests
40	FBCA CP Sections 4.5.1, 6.5.1	All certificate revocation requests
41	FBCA CP Sections 4.5.1, 6.5.1	The approval or rejection of a certificate status change request
42	FBCA CP Sections 4.5.1, 6.5.1	Any security-relevant changes to the configuration of the FBCA
43	FBCA CP Sections 4.5.1, 6.5.1	Roles and users are added or deleted
44	FBCA CP Sections 4.5.1, 6.5.1	The access control privileges of a user account or a role are modified
45	FBCA CP Sections 4.5.1, 6.5.1	All changes to the certificate profile
46	FBCA CP Sections 4.5.1, 6.5.1	All changes to the revocation profile
47	FBCA CP Sections 4.5.1, 6.5.1	All changes to the certificate revocation list profile
48	FBCA CP Sections 4.5.1, 6.5.1	Installation of the Operating System
49	FBCA CP Sections 4.5.1, 6.5.1	Installation of the FBCA CA
50	FBCA CP Sections 4.5.1, 6.5.1	Installing hardware cryptographic modules
51	FBCA CP Sections 4.5.1, 6.5.1	Removing hardware cryptographic modules
52	FBCA CP Sections 4.5.1, 6.5.1	Destruction of cryptographic modules
53	FBCA CP Sections 4.5.1, 6.5.1	System Startup
54	FBCA CP Sections 4.5.1, 6.5.1	Logon Attempts to FBCA  Apps
55	FBCA CP Sections 4.5.1, 6.5.1	Receipt of Hardware / Software
56	FBCA CP Sections 4.5.1, 6.5.1	Attempts to set passwords
57	FBCA CP Sections 4.5.1, 6.5.1	Attempts to modify passwords
58	FBCA CP Sections 4.5.1, 6.5.1	Backing up FBCA internal database
59	FBCA CP Sections 4.5.1, 6.5.1	Restoring FBCA internal database
60	FBCA CP Sections 4.5.1, 6.5.1	File manipulation (e.g., creation, renaming, moving)
61	FBCA CP Sections 4.5.1, 6.5.1	Posting of any material to a repository
62	FBCA CP Sections 4.5.1, 6.5.1	Access to FBCA internal database
63	FBCA CP Sections 4.5.1, 6.5.1	All certificate compromise notification requests
64	FBCA CP Sections 4.5.1, 6.5.1	Loading tokens with certificates
65	FBCA CP Sections 4.5.1, 6.5.1	Shipment of Tokens
66	FBCA CP Sections 4.5.1, 6.5.1	Zeroizing tokens
67	FBCA CP Sections 4.5.1, 6.5.1	Rekey of the FBCA or Agency CA
68	FBCA CP Sections 4.5.1, 6.5.1	Configuration changes to the CA server involving
69	FBCA CP Sections 4.5.1, 6.5.1	Hardware
70	FBCA CP Sections 4.5.1, 6.5.1	Software
71	FBCA CP Sections 4.5.1, 6.5.1	Operating System
72	FBCA CP Sections 4.5.1, 6.5.1	Patches
73	FBCA CP Sections 4.5.1, 6.5.1	Security Profiles
74	FBCA CP Sections 4.5.1, 6.5.1	Access to the FBCA server
75	FBCA CP Sections 4.5.1, 6.5.1	Known or suspected violations of physical security
76	FBCA CP Sections 4.5.1, 6.5.1	Software Error conditions
77	FBCA CP Sections 4.5.1, 6.5.1	Software check integrity failures
78	FBCA CP Sections 4.5.1, 6.5.1	Receipt of improper messages
79	FBCA CP Sections 4.5.1, 6.5.1	Misrouted messages
80	FBCA CP Sections 4.5.1, 6.5.1	Network attacks (suspected or confirmed)
81	FBCA CP Sections 4.5.1, 6.5.1	Equipment failure
82	FBCA CP Sections 4.5.1, 6.5.1	Electrical power outages
83	FBCA CP Sections 4.5.1, 6.5.1	Uninterruptible Power Supply (UPS) failure
84	FBCA CP Sections 4.5.1, 6.5.1	Obvious and significant network service or access failures
85	FBCA CP Sections 4.5.1, 6.5.1	Resetting Operating System clock
86	FBCA CP Section 4.5.2	All significant events shall be explained in an audit log summary, including statistically significant set of security audit data generated since the last review (where the confidence intervals for each category of security audit data are determined by the security ramifications of the category and the availability of tools to perform such a review), as well as a reasonable search for any evidence of malicious activity
87	FBCA CP Section 4.5.4	For security audit data, the FBCA system configuration and procedures must be implemented to ensure that  only authorized people have read access to the logs (non FBCA OA)
88	FBCA CP Section 4.5.4	For security audit data, the FBCA system configuration and procedures must be implemented to ensure that only authorized people may archive or delete audit logs(non FBCA OA)
89	FBCA CP Section 4.5.4	For security audit data, the FBCA system configuration and procedures must be implemented to ensure that audit logs are not modified
90	FBCA CP Section 4.5.5	For security audit data, the FBCA system configuration and procedures must be implemented to provide ackup of audit logs and audit summaries
91	FBCA CP Section 5.1.2	Inactivate removable cryptographic modules prior to storage
92	FBCA CP Sections 5.2.1, 6.5.1	Support for four, somewhat abstract, roles:  Administrator, authorized to install, configure, and maintain the CA; establish and maintain user accounts; configure profiles and audit parameters; and generate component keys. Admiistrators do not issue certificates to subscribers
93	FBCA CP Section 5.2.1	Support for four, somewhat abstract, roles:  Officer - – authorized to request or approve certificates or certificate revocations.  Officer issues certificates
94	FBCA CP Section 5.2.1	Support for four, somewhat abstract, roles:  Auditor - authorized to view and maintain audit logs.
95	FBCA CP Section 5.2.1	Support for four, somewhat abstract, roles:  Operator - authorized to perform system backup and recovery
96	FBCA CP Sections 5.2.4, 6.5.1	An individual shall identify and authenticate him/herself before being permitted to perform any actions set forth above for that role or identity.
97	FBCA CP Sections 6.1.1, 6.2.1, 6.2.6; FBCA Inter- operability Guidelines	Cryptographic keying material for certificates issued by the FBCA  shall be generated in FIPS 140 validated cryptographic modules that meet or exceed Security Level 3.
98	FBCA CP Section 6.1.4	The FBCA shall transport its public key to the Agency Principal CA in a secure, out-of-band fashion to effect certificate issuance
99	FBCA Inter- operability Guidelines	Exchange PKCS7/10 certificate request/response messaging formats: generate  PKCS7/10 certificate requests and responses and export them to other CAs as files; and import and process PKCS7/10 certificate requests and responses received as files from other CAs
100	FBCA CP Section 6.1.5	All certificates issued by the FBCA shall use at least 1024 bit RSA or DSA, with Secure Hash Algorithm version 1 (SHA-1) (or better), in accordance with FIPS 186	RSA with SHA-1 required for initial test
101	FBCA CP Section 6.1.6	Public key parameters prescribed in the Digital Signature Standard (DSS) shall be generated in accordance with FIPS 186	Not required for initial test
102	FBCA CP Section 6.1.7	Parameter quality checking (including primarily testing for prime numbers) shall be performed in accordance with FIPS 186	Not required for initial test
103	FBCA CP Section 6.2.2	Use of the FBCA private signing key shall require action by multiple persons as set forth in Section 5
104	FBCA CP Section 6.2.4.1	The FBCA  private signature keys shall be backed up under the same multi-person control as the original signature key
105	FBCA CP Section 6.2.8	After use, the cryptographic module shall be deactivated, e.g., via a manual logout procedure, or automatically after a period of inactivity
106	FBCA CP Section 6.4	The activation data used to unlock FBCA, private key  shall either entail the use of biometric data or satisfy the policy enforced at/by the cryptographic module. Where passwords are used as activation data, the passwords shall be generated in conformance with FIPS-112.
107	FBCA CP Section 6.4.2	Data used to unlock private keys shall be protected from disclosure by a combination of cryptographic and physical access control mechanisms
108	FBCA CP Section 6.4.2	The protection mechanism shall include a facility to temporarily lock the account, or terminate the application, after a predetermined number of failed login attempts
109	FBCA CP Section 6.5.1	The FBCA and its ancillary parts shall include the following functionality:
110	FBCA CP Section 6.5.1	Prohibit object re-use or require separation for FBCA random access memory
111	FBCA CP Section 6.5.1	Use of cryptography for session communication and database security
112	FBCA CP Section 6.5.1	Self-test security related FBCA services
113	FBCA CP Section 6.5.1	Trusted path for identification of PKI roles and associated identities
114	FBCA CP Section 6.5.1	Recovery mechanisms for keys and the FBCA system
115	FBCA CP Section 6.5.1	Enforce domain integrity boundaries for security critical processes
116	FBCA CP Section 6.6.1	Hardware and software updates shall be developed in the same manner as original	Provide documentation
117	FBCA CP Section 6.6.2	There shall be a mechanism for detecting unauthorized modification to the FBCA software or configuration