1. Introduction

(New location of Section 1 in 2527 format.)

This document defines a suite of policies that apply to the management of the E-Governance Certification Authorities.

This suite of policies incorporates three specific certificate policies recognizing Credential Service Providers (CSPs) that have been certified as meeting E-Authentication assurance requirements at Level 1 or 2, as defined in [M-04-04], and agency application servers participating in the E-Authentication program (http://www.cio.gov/eauthentication/). In these policies, certificates either: • identify a Level 1 CSP (as a network device) named in the certificate and binds that CSP to a particular public/private key pair, • identify a Level 2 CSP (as a network device) named in the certificate and binds that CSP to a particular public/private key pair, or • identify a federal agency server (a network device) supporting one or more E- Authentication applications, and binds that server to a particular public/private key pair. Unless otherwise noted, stipulations in this document (henceforth referred to as “this CP”) apply to all three policies. As specified in this CP, the E-Governance CAs will provide the following security management services: • CA key generation/storage • Certificate generation, update, renewal, rekey, and distribution • Certificate revocation list (CRL) generation and distribution • Directory management of certificate related items • System management functions (e.g., security audit, configuration management, archive.) This policy requires use of FIPS 140 validated cryptographic modules for cryptographic operations and the protection of trusted public keys by both the E-Governance CAs and their subscribers. Under this policy, the E-Governance CAs will not issue certificates to other CAs. Self-issued certificates to manage transitions (e.g., to new CA key pairs) are permitted. Only the E- Governance CAs are permitted to assert these policies in certificates. This policy also establishes requirements for the secure distribution of the E-Governance CAs’ self-signed certificates. This CP is consistent with the Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (IETF PKIX) request for comments (RFC) 2527, CP and Certification Practice Statement Framework.

Page 8

(Old location of Section 1.1 in 2527 format) (Old location of Section 1.2 in 2527 format) (Old location of Section 1.3 in 2527 format) (Old location of Section 1.4 in 2527 format)

1.1 Overview

(New location of Section 1.1 in 2527 format.) (Old location of Section 1.1.1 in 2527 format) (Old location of Section 1.1.2 in 2527 format) (Old location of Section 1.1.3 in 2527 format)

1.2 Document name and identification

(New location of Section 1.2 in 2527 format.)

This CP provides substantial assurance concerning identity of certificate subjects. Certificates issued in accordance with this CP shall assert at least one of the following OIDs in the certificate policy extension: id-eGov-Level1 ::= {2 16 840 1 101 3 2 1 3 9} id-eGov-Level2 ::= {2 16 840 1 101 3 2 1 3 10} id-eGov-Applications ::= {2 16 840 1 101 3 2 1 3 11} Certificates issued to CSPs under this policy shall contain either the id-eGov-Level1 OID or the id-eGov-Level2 OID. Certificates issued to agency application servers under this policy shall contain the id-eGov- Applications OID.

1.3 PKI participants

(New location of Section 1.3 in 2527 format.)

Certificates issued under this policy are solely to support distribution of authentication information to Federal Government relying parties. Use of these certificates for other purposes, while not prohibited, is outside the scope of this policy.

(Old location of Section 1.3.1 in 2527 format) (Old location of Section 1.3.2 in 2527 format) (Old location of Section 1.3.3 in 2527 format)

1.3.1 Certification authorities

(New location of Section 1.3.1 in 2527 format.)

The Federal PKI Policy Authority (PA) is comprised of U.S. Federal Government Agencies (including cabinet-level Departments) participating in the Federal PKI and was established by the Federal CIO Council. The PA is responsible for maintaining this policy, approving the CPS for each CA that issues certificates under this policy, approving the compliance audit report for

Page 9

each CA issuing certificates under this policy, and is a key component of the E-Authentication Technical Architecture. The PA is also responsible for identifying one or more E-Authentication Authorizing Officials (see 1.3.1.4 and 2.1.4).

The CA is the collection of hardware, software and operating personnel that create, sign, and issue public key certificates to subscribers. The CA is responsible for the issuing and managing certificates including— • The certificate manufacturing process • Publication of certificates • Revocation of certificates • Generation and destruction of CA signing keys • Ensuring that all aspects of the CA services, operations, and infrastructure related to certificates issued under this CP are performed in accordance with the requirements, representations, and warranties of this CP.

The registration authority (RA) is the entity that collects and verifies each subscriber’s identity and information that are to be entered into the subscriber’s public key certificate. The RA performs its function in accordance with a CPS approved by the PA. The RA is responsible for— • Control over the registration process • The identification and authentication process RA duties are performed by the E-Authentication Authorizing Officials (see 1.3.1.4) and may also be performed as an additional duty by CA personnel.

The E-Authentication Authorizing Official (EAO) is responsible for the decision to issue a certificate to a particular CSP or a federal agency application server.

The CAs and RAs operating under this CP may require the services of other security, community, and application authorities, such as compliance auditors and attribute authorities. The CPS will identify the parties responsible for providing such services, and the mechanisms used to support these services.

1.3.2 Registration authorities

(New location of Section 1.3.2 in 2527 format.)

A subscriber is the entity whose name appears as the subject in a certificate. For this policy, subscribers are limited to CSPs and agency application servers. CSPs provide SAML assertions 3

Page 10

to agency application servers. Subscribers will use these certificates to establish mutually authenticated TLS connections to provide authentication, integrity, and confidentiality to the transmission of these SAML assertions.

A relying party is the entity that relies on the validity of the binding of the subscriber’s name to a public key. For this certificate policy, the relying party may be any entity that wishes to validate the binding of a public key to a CSP or agency application server.

1.3.3 Subscribers

(New location of Section 1.3.3 in 2527 format.)

Certificates issued under these policies may be used to establish mutually authenticated TLS connections to provide authentication, integrity, and confidentiality to the transmission of SAML assertions.

1.3.4 Relying parties

(New location of Section 1.3.3 in 2527 format.)

1.3.5 Other participants

1.4 Certificate usage

1.4.1 Appropriate certificate uses

1.4.2 Prohibited certificate uses

1.5 Policy administration

(New location of Section 1.4 in 2527 format.) (Old location of Section 1.4.1 in 2527 format) (Old location of Section 1.4.2 in 2527 format) (Old location of Section 1.4.3 in 2527 format)

1.5.1 Organization administering the document

(New location of Section 1.4.1 in 2527 format.)

The PA is responsible for all aspects of this CP.

1.5.2 Contact person

(New location of Section 1.4.2 in 2527 format.)

Questions regarding this CP shall be directed to the Chair of the Federal PKI Policy Authority, whose address can be found athttp://www.cio.gov/fpkipa.

1.5.3 Person determining CPS suitability for the policy

(New location of Section 1.4.3 in 2527 format.)

The PA shall approve the CPS for each CA that issues certificates under this policy. Reference Section 8.3.

Page 11

1.5.4 CPS approval procedures

(New location of Section 8.3 in 2527 format.)

The PA shall make the determination that a CPS complies with this policy. The CA and RA must meet all requirements of an approved CPS before commencing operations. In some cases, the PA may require the additional approval of an authorized agency. The PA will make this determination based on the nature of the system function, the type of communications, or the operating environment.

1.6 Definitions and acronyms

2. Publication and Repository Responsibilities

(New location of Section 2.1.5 in 2527 format.)

Subscribers shall— • Accurately represent themselves in all communications with the PKI authorities and other subscribers. • Protect their private keys at all times, in accordance with this policy, as stipulated in their certificate acceptance agreements and local procedures. • Notify, in a timely manner, the CA that issued their certificates of suspicion that their private keys are compromised or lost. Such notification shall be made directly, or indirectly through mechanisms consistent with the CA’s CPS. • Abide by all the terms, conditions, and restrictions levied on the use of their private keys and certificates.

(New location of Section 2.6 in 2527 format.) (Old location of Section 2.6.1 in 2527 format) (Old location of Section 2.6.2 in 2527 format) (Old location of Section 2.6.3 in 2527 format) (Old location of Section 2.6.4 in 2527 format) (New location of Section 2 in 2527 format.) (Old location of Section 2.1 in 2527 format) (Old location of Section 2.2 in 2527 format) (Old location of Section 2.3 in 2527 format) (Old location of Section 2.4 in 2527 format) (Old location of Section 2.5 in 2527 format) (Old location of Section 2.6 in 2527 format) (Old location of Section 2.7 in 2527 format) (Old location of Section 2.8 in 2527 format) (Old location of Section 2.9 in 2527 format)

2.1 Repositories

(New location of Section 2.6.4 in 2527 format.)

See Section 2.1.7.

2.2 Publication of certification information

(New location of Section 2.6.1 in 2527 format.)

Certificates and CRLs shall be published as specified in Section 2.1.7. No stipulation regarding publication of additional CA information.

(New location of Section 8.2 in 2527 format.)

This CP and any subsequent changes shall be made publicly available within 1 week of approval.

2.3 Time or frequency of publication

(New location of Section 2.6.2 in 2527 format.)

Certificates are published following subscriber acceptance as specified in Section 4.3 and proof of possession of private key as specified in Section 3.1.7. The CRL is published as specified in Section 4.4.3.1. All information to be published in the repository shall be published promptly 7

Page 14

after such information becomes available to the CA. The CA shall specify in its CPS time limits within which it will publish various types of information.

(New location of Section 8.2 in 2527 format.)

This CP and any subsequent changes shall be made publicly available within 1 week of approval.

2.4 Access controls on repositories

(New location of Section 2.6.3 in 2527 format.)

The CA shall protect information not intended for public dissemination or modification. CA certificates and CRLs in the repository shall be publicly available through the Internet. Access to other information in the CA repositories shall be determined by agencies pursuant to their authorizing and controlling statutes. The CPS shall detail what information in the repository shall be exempt from automatic availability and to whom, and under which conditions, the restricted information may be made available.

3. Identification and Authentication

(New location of Section 3 in 2527 format.) (Old location of Section 3.1 in 2527 format) (Old location of Section 3.2 in 2527 format) (Old location of Section 3.3 in 2527 format) (Old location of Section 3.4 in 2527 format)

3.1 Naming

(New location of Section 3.1 in 2527 format.) (Old location of Section 3.1.1 in 2527 format) (Old location of Section 3.1.2 in 2527 format) (Old location of Section 3.1.3 in 2527 format) (Old location of Section 3.1.4 in 2527 format) (Old location of Section 3.1.5 in 2527 format) (Old location of Section 3.1.6 in 2527 format) (Old location of Section 3.1.7 in 2527 format) (Old location of Section 3.1.8 in 2527 format) (Old location of Section 3.1.9 in 2527 format)

3.1.1 Types of names

(New location of Section 3.1.1 in 2527 format.)

Names assigned to E-Governance CAs shall be in the following form: •C=US, o=U.S. Government, ou=GSA, ou=e-Gov, cn=CAname

The common name should be descriptive and must include the authentication level supported by the CA. CSP subscriber names assigned by E-Governance CAs shall be in the following form: •C=US, o=Organization, [ou=major unit], [ou=minor unit], cn=CSP name

The ou attributes are optional. The common name may be descriptive, or may be the Internet domain name of the CSP. That is, the common name may be “Acme Corporation” or “csp1.acme.com”. The naming attributes identified in [RFC 3280] may also be included in CSP subscriber distinguished names. CSP subscriber certificates shall also include the CSP’s Internet domain name in the subject alternative name extension and an email address for a human point of contact. Agency application server subscriber names assigned by the e-Governance CAs shall be in the following form: •C=US, o=U.S. Government, [ou=department], [ou=agency], cn=Agency Server name

The organizational units department and agency appear when applicable and are used to specify the federal entity that employs the subscriber. At least one organizational unit must appear in the DN. The common name may be descriptive, or may be the Internet domain name of the server supporting the application. That is, the common name may be “Big Agency Grants Server” or “grants1.bigagency.gov”. The naming attributes identified in [RFC 3280] may also be included in agency application server subscriber distinguished names. Agency application server certificates shall also include the server’s Internet domain name in the subject alternative name extension and may include an email address for a human point of contact.

3.1.2 Need for names to be meaningful

(New location of Section 3.1.2 in 2527 format.)

The subscriber certificates issued pursuant to this CP are meaningful only if the names that appear in the certificates can be understood and used by relying parties. Names used in the certificates must identify in a meaningful way the subscriber to which they are assigned.

3.1.3 Anonymity or pseudonymity of subscribers

(New location of Section 3.1.2 in 2527 format.)

3.1.4 Rules for interpreting various name forms

(New location of Section 3.1.3 in 2527 format.)

Rules for interpreting name forms are specified in [USGold]. 10

Page 17

3.1.5 Uniqueness of names

(New location of Section 3.1.4 in 2527 format.)

The EAO is responsible for name space control procedures. The EAO will establish name space control procedures for names assigned to subscriber CSPs to ensure name collisions do not occur. The EAO will establish name space control procedures based on [US Gold] for names assigned to Agency application server subscribers. This policy depends upon established name space control procedures for Internet Domain Names to avoid name collisions in the subject alternative name extension or the common name attribute.

3.1.6 Recognition, authentication, and role of trademarks

(New location of Section 3.1.6 in 2527 format.)

No stipulation.

(New location of Section 3.1.5 in 2527 format.)

The EAO shall resolve any name collisions brought to its attention.

3.2 Initial identity validation

3.2.1 Method to prove possession of private key

(New location of Section 3.1.7 in 2527 format.)

The subscriber shall be required to prove possession of the private key that corresponds to the public key in the certificate request. This may be done by the entity using its private key to sign the public key in a certificate request. The PA may allow other mechanisms that are at least as secure as those cited here.

3.2.2 Authentication of organization identity

(New location of Section 3.1.8 in 2527 format.)

The issuing CA shall verify the identity information, in addition to the authenticity of the requester. The CA shall verify that the requester is listed as a POC on the CSP’sE-Governance Certificate Issuance Authorization Letter. The requester’s identity shall be verified through either digitally signed messages or other secure means (e.g., in person or out-of-band mechanisms.) Requests for CSP certificates shall include: • Equipment identification (i.e., DNS name) • Equipment public keys

3.2.3 Authentication of individual identity

(New location of Section 3.1.9 in 2527 format.)

The issuing CA shall verify the identity information, in addition to the authenticity of the requester. The CA shall verify that the requester is listed as a POC on the Agency Application’s E-Governance Certificate Issuance Authorization Letter. The requester’s identity shall be verified through either digitally signed messages or other secure means (e.g., in person or out-of- band mechanisms.) Requests for Agency application server certificates shall include: • Equipment identification (i.e., DNS name)

Page 18

• Equipment public keys

3.2.4 Non-verified subscriber information

3.2.5 Validation of authority

3.2.6 Criteria for interoperation

3.3 Identification and authentication for re-key requests

3.3.1 Identification and authentication for routine re-key

(New location of Section 3.2 in 2527 format.)

The procedures for accomplishing the Certificate Renewal, Update, and Routine Re-Key specified in this CP will be detailed in the CA’s CPS.

(Old location of Section 3.2.1 in 2527 format) (Old location of Section 3.2.2 in 2527 format) (Old location of Section 3.2.3 in 2527 format)

3.3.2 Identification and authentication for re-key after revocation

(New location of Section 3.3 in 2527 format.)

In the event of certificate revocation, issuance of a new certificate shall always require that the party go through the initial registration process per Section 3.1 above.

3.4 Identification and authentication for revocation request

(New location of Section 3.4 in 2527 format.)

Revocation requests must be authenticated. Requests to revoke a certificate may be authenticated using that certificate’s associated private key, regardless of whether or not the private key has been compromised.

4. Certificate Life-Cycle Operational Requirements

(New location of Section 4 in 2527 format.) (Old location of Section 4.1 in 2527 format) (Old location of Section 4.2 in 2527 format) (Old location of Section 4.3 in 2527 format) (Old location of Section 4.4 in 2527 format) (Old location of Section 4.5 in 2527 format) (Old location of Section 4.6 in 2527 format) (Old location of Section 4.7 in 2527 format) (Old location of Section 4.8 in 2527 format) (Old location of Section 4.9 in 2527 format)

4.1 Certificate Application

(New location of Section 4.1 in 2527 format.)

Application for certificates shall be made to the E-Authentication Authorizing Official (EAO).

(Old location of Section 4.1.1 in 2527 format)

4.1.1 Who can submit a certificate application

4.1.2 Enrollment process and responsibilities

(New location of Section 2.1.3 in 2527 format.)

An RA who performs registration functions as described in this policy shall comply with the stipulations of this policy, and comply with a CPS approved by the PA for use with this policy. An RA who is found to have acted in a manner inconsistent with these obligations is subject to revocation of RA responsibilities. An RA supporting this policy shall conform to the stipulations of this document, including— • Maintaining its operations in conformance to the stipulations of the approved CPS.

Page 12

• Including only valid and appropriate information in certificate requests, and maintaining evidence that due diligence was exercised in validating the information contained in the certificate. • Ensuring that obligations are imposed on subscribers in accordance with Section 2.1.5, and that subscribers are informed of the consequences of not complying with those obligations.

4.2 Certificate application processing

(New location of Section 4.2 in 2527 format.)

This policy allows a certificate to be issued only to a single subscriber. Certificates shall not be issued that contain a public key whose associated private key is shared by multiple subscribers. [Practice Note: Where multiple devices assert the same DNS name, (e.g., load balanced authentication servers), they are considered a single subscriber and may share the private key corresponding to a certificate issued under this policy.] Upon receiving the request, the CAs/RAs will— • Verify the identity of the requestor • Verify the authority of the requestor and the integrity of the information in the certificate request • Build and sign a certificate if all certificate requirements have been met (in the case of an RA, have the CA sign the certificate) • Make the certificate available to the subscriber.

Page 20

The certificate request may already contain a certificate built by either the RA or the subscriber. This certificate will not be signed until all verifications and modifications, if any, have been completed to the CA’s satisfaction. All authorization and other attribute information received from a prospective subscriber shall be verified against theE-Governance Certificate Issuance Authorization Letterbefore inclusion in a certificate. The EAO is responsible for verifying prospective subscriber data before issuing the authorization letter.

(Old location of Section 4.2.1 in 2527 format) (Old location of Section 4.2.2 in 2527 format) (New location of Section 4.1 in 2527 format.)

Application for certificates shall be made to the E-Authentication Authorizing Official (EAO).

(Old location of Section 4.1.1 in 2527 format)

4.2.1 Performing identification and authentication functions

4.2.2 Approval or rejection of certificate applications

4.2.3 Time to process certificate applications

4.3 Certificate issuance

(New location of Section 4.2 in 2527 format.)

Page 20

(Old location of Section 4.2.1 in 2527 format) (Old location of Section 4.2.2 in 2527 format)

4.3.1 CA actions during certificate issuance

4.3.2 Notification to subscriber by the CA of issuance of certificate

(New location of Section 4.3 in 2527 format.)

Before a subscriber can make effective use of its private key, the EAO shall— • Explain to the CSP or agency application server POC its responsibilities as defined in Section 2.1.5 • Inform the CSP or agency application server POC of the creation of a certificate and the contents of the certificate.

4.4 Certificate acceptance

(New location of Section 2.1.3 in 2527 format.)

Page 12

(New location of Section 4.3 in 2527 format.)

4.4.1 Conduct constituting certificate acceptance

4.4.2 Publication of the certificate by the CA

(New location of Section 2.6.1 in 2527 format.)

Certificates and CRLs shall be published as specified in Section 2.1.7. No stipulation regarding publication of additional CA information.

(New location of Section 2.1.5 in 2527 format.)

4.4.3 Notification of certificate issuance by the CA to other entities

(New location of Section 2.6.1 in 2527 format.)

Certificates and CRLs shall be published as specified in Section 2.1.7. No stipulation regarding publication of additional CA information.

(New location of Section 2.1.5 in 2527 format.)

(New location of Section 4.2 in 2527 format.)

Page 20

(Old location of Section 4.2.1 in 2527 format) (Old location of Section 4.2.2 in 2527 format)

4.5 Key pair and certificate usage

(New location of Section 2.1.4 in 2527 format.)

The E-Authentication Authorizing Official (EAO) shall— • Authorize issuance of certificates to CSPs and determine the appropriate E-Authentication Level for that certificate. • Authorize issuance of certificates to Federal Agency application servers.

(New location of Section 2.1.3 in 2527 format.)

Page 12

4.5.1 Subscriber private key and certificate usage

(New location of Section 2.1.3 in 2527 format.)

Page 12

4.5.2 Relying party public key and certificate usage

(New location of Section 2.1.4 in 2527 format.)

4.6 Certificate renewal

(New location of Section 4.3 in 2527 format.)

(New location of Section 4.2 in 2527 format.)

Page 20

(Old location of Section 4.2.1 in 2527 format) (Old location of Section 4.2.2 in 2527 format) (New location of Section 4.1 in 2527 format.)

Application for certificates shall be made to the E-Authentication Authorizing Official (EAO).

(Old location of Section 4.1.1 in 2527 format) (New location of Section 3.2 in 2527 format.)

The procedures for accomplishing the Certificate Renewal, Update, and Routine Re-Key specified in this CP will be detailed in the CA’s CPS.

(Old location of Section 3.2.1 in 2527 format) (Old location of Section 3.2.2 in 2527 format) (Old location of Section 3.2.3 in 2527 format)

4.6.1 Circumstance for certificate renewal

4.6.2 Who may request renewal

4.6.3 Processing certificate renewal requests

4.6.4 Notification of new certificate issuance to subscriber

4.6.5 Conduct constituting acceptance of a renewal certificate

(New location of Section 2.1.3 in 2527 format.)

Page 12

4.6.6 Publication of the renewal certificate by the CA

(New location of Section 2.6.1 in 2527 format.)

Certificates and CRLs shall be published as specified in Section 2.1.7. No stipulation regarding publication of additional CA information.

(New location of Section 2.1.5 in 2527 format.)

4.6.7 Notification of certificate issuance by the CA to other entities

(New location of Section 2.6.1 in 2527 format.)

Certificates and CRLs shall be published as specified in Section 2.1.7. No stipulation regarding publication of additional CA information.

(New location of Section 2.1.5 in 2527 format.)

4.7 Certificate re-key

(New location of Section 4.3 in 2527 format.)

(New location of Section 4.2 in 2527 format.)

Page 20

(Old location of Section 4.2.1 in 2527 format) (Old location of Section 4.2.2 in 2527 format) (New location of Section 4.1 in 2527 format.)

Application for certificates shall be made to the E-Authentication Authorizing Official (EAO).

(Old location of Section 4.1.1 in 2527 format) (New location of Section 3.2 in 2527 format.)

The procedures for accomplishing the Certificate Renewal, Update, and Routine Re-Key specified in this CP will be detailed in the CA’s CPS.

(Old location of Section 3.2.1 in 2527 format) (Old location of Section 3.2.2 in 2527 format) (Old location of Section 3.2.3 in 2527 format)

4.7.1 Circumstance for certificate re-key

4.7.2 Who may request certification of a new public key

4.7.3 Processing certificate re-keying requests

4.7.4 Notification of new certificate issuance to subscriber

4.7.5 Conduct constituting acceptance of a re-keyed certificate

(New location of Section 2.1.3 in 2527 format.)

Page 12

4.7.6 Publication of the re-keyed certificate by the CA

(New location of Section 2.6.1 in 2527 format.)

Certificates and CRLs shall be published as specified in Section 2.1.7. No stipulation regarding publication of additional CA information.

(New location of Section 2.1.5 in 2527 format.)

4.7.7 Notification of certificate issuance by the CA to other entities

(New location of Section 2.6.1 in 2527 format.)

Certificates and CRLs shall be published as specified in Section 2.1.7. No stipulation regarding publication of additional CA information.

(New location of Section 2.1.5 in 2527 format.)

4.8 Certificate modification

(New location of Section 4.4 in 2527 format.) (Old location of Section 4.4.1 in 2527 format) (Old location of Section 4.4.2 in 2527 format) (Old location of Section 4.4.3 in 2527 format) (Old location of Section 4.4.4 in 2527 format) (Old location of Section 4.4.5 in 2527 format) (Old location of Section 4.4.6 in 2527 format) (Old location of Section 4.4.7 in 2527 format)

4.8.1 Circumstance for certificate modification

(New location of Section 4.4.1 in 2527 format.)

A certificate shall be revoked when the binding between the subject and the subject’s public key defined within a certificate is no longer considered valid. Examples of circumstances that invalidate the binding are— • Identifying information or affiliation components of any names in the certificate becomes invalid. • Privilege attributes asserted in the subscriber’s certificate are reduced. • The subscriber can be shown to have violated the stipulations of its subscriber agreement. • There is reason to believe the private key has been compromised. • The subscriber or other authorized party (as defined in the CPS) asks for his/her certificate to be revoked. Whenever any of the above circumstances occur, the associated certificate shall be revoked and placed on the CRL. Revoked certificates shall be included on all new publications of the certificate status information until the certificates expire. Re-issuance of certificates, as specified in Section 3.1, shall be performed as quickly as possible except where it would adversely affect the integrity and trust of the system.

A CA may summarily revoke certificates it issued to maintain the integrity of the system. A written notice and brief explanation for the revocation shall subsequently be provided to the subscriber. The RA or EAO can request the revocation of a subscriber’s certificate on behalf of any authorized party as specified in the CPS. A subscriber may request that its own certificate be revoked. Other authorized agency officials may request revocation as described in the CPS.

A request to revoke a certificate shall identify the certificate to be revoked, explain the reason for revocation, and allow the request to be authenticated (e.g., digitally or manually signed). The steps involved in the process of requesting a certification revocation are detailed in the CPS. 15

Page 22

There is no grace period for revocation under this policy; CAs will revoke certificates as quickly as practical upon receipt of a proper revocation request. Revocation requests shall be processed before the next CRL is published, excepting those requests received within two hours of CRL issuance. Revocation requests received within two hours of CRL issuance that are not processed before the next CRL is published shall be processed before the following CRL is published.

(New location of Section 2.1.3 in 2527 format.)

Page 12

4.8.2 Who may request certificate modification

(New location of Section 4.4.2 in 2527 format.)

Certificate suspension is not allowed by this policy.

4.8.3 Processing certificate modification requests

4.8.4 Notification of new certificate issuance to subscriber

(New location of Section 4.2 in 2527 format.)

Page 20

(Old location of Section 4.2.1 in 2527 format) (Old location of Section 4.2.2 in 2527 format)

4.8.5 Conduct constituting acceptance of modified certificate

(New location of Section 2.1.3 in 2527 format.)

Page 12

4.8.6 Publication of the modified certificate by the CA

(New location of Section 2.6.1 in 2527 format.)

Certificates and CRLs shall be published as specified in Section 2.1.7. No stipulation regarding publication of additional CA information.

(New location of Section 2.1.5 in 2527 format.)

(New location of Section 4.2 in 2527 format.)

Page 20

(Old location of Section 4.2.1 in 2527 format) (Old location of Section 4.2.2 in 2527 format)

4.8.7 Notification of certificate issuance by the CA to other entities

(New location of Section 2.6.1 in 2527 format.)

Certificates and CRLs shall be published as specified in Section 2.1.7. No stipulation regarding publication of additional CA information.

(New location of Section 2.1.5 in 2527 format.)

(New location of Section 4.2 in 2527 format.)

Page 20

(Old location of Section 4.2.1 in 2527 format) (Old location of Section 4.2.2 in 2527 format)

4.9 Certificate revocation and suspension

4.9.1 Circumstances for revocation

(New location of Section 4.4.1 in 2527 format.)

Page 22

(New location of Section 2.1.3 in 2527 format.)

Page 12

4.9.2 Who can request revocation

(New location of Section 4.4.2 in 2527 format.)

Certificate suspension is not allowed by this policy.

(New location of Section 2.1.3 in 2527 format.)

Page 12

4.9.3 Procedure for revocation request

(New location of Section 4.4.3 in 2527 format.)

CAs shall issue CRLs covering all unexpired certificates issued under this policy.

CRLs shall be issued at least once every 18 hours.

4.9.4 Revocation request grace period

(New location of Section 4.4.4 in 2527 format.)

No stipulation.

4.9.5 Time within which CA must process the revocation request

4.9.6 Revocation checking requirement for relying parties

(New location of Section 2.1.4 in 2527 format.)

4.9.7 CRL issuance frequency (if applicable

(New location of Section 4.8.2 in 2527 format.)

If the CA cannot issue a CRL within 72 hours after the time specified in the next update field of its currently valid CRL, the PA shall be informed.

4.9.8 Maximum latency for CRLs (if applicable)

4.9.9 On-line revocation/status checking availability

(New location of Section 4.8.2 in 2527 format.)

If the CA cannot issue a CRL within 72 hours after the time specified in the next update field of its currently valid CRL, the PA shall be informed.

4.9.10 On-line revocation checking requirements

4.9.11 Other forms of revocation advertisements available

(New location of Section 4.8.2 in 2527 format.)

If the CA cannot issue a CRL within 72 hours after the time specified in the next update field of its currently valid CRL, the PA shall be informed.

4.9.12 Special requirements re key compromise

4.9.13 Circumstances for suspension

(New location of Section 4.4.5 in 2527 format.)

None.

(New location of Section 2.1.3 in 2527 format.)

Page 12

4.9.14 Who can request suspension

(New location of Section 4.4.6 in 2527 format.)

None.

4.9.15 Procedure for suspension request

(New location of Section 4.4.7 in 2527 format.)

In the event of a CA private key compromise, the following operations must be performed. If the CA distributed the public key in a Trusted Certificate, the CA shall perform the following operations: • Generate a new signing key pair and corresponding Trusted Certificate; • Initiate procedures to notify subscribers of the compromise; and • Securely distribute the Trusted Certificate. • Optionally, the CA may renew current certificates under the new signing key. (see 3.2.1)

(New location of Section 2.1.3 in 2527 format.)

Page 12

4.9.16 Limits on suspension period

4.10 Certificate status services

4.10.1 Operational characteristics

4.10.2 Service availability

4.10.3 Optional features

4.11 End of subscription

4.12 Key escrow and recovery

4.12.1 Key escrow and recovery policy and practices

4.12.2 Session key encapsulation and recovery policy and practices

5. Facility, Management, and Operational Controls

(New location of Section 2.1.4 in 2527 format.)

(New location of Section 2.1.3 in 2527 format.)

Page 12

(New location of Section 5 in 2527 format.) (Old location of Section 5.1 in 2527 format) (Old location of Section 5.2 in 2527 format) (Old location of Section 5.3 in 2527 format) (New location of Section 4 in 2527 format.) (Old location of Section 4.1 in 2527 format) (Old location of Section 4.2 in 2527 format) (Old location of Section 4.3 in 2527 format) (Old location of Section 4.4 in 2527 format) (Old location of Section 4.5 in 2527 format) (Old location of Section 4.6 in 2527 format) (Old location of Section 4.7 in 2527 format) (Old location of Section 4.8 in 2527 format) (Old location of Section 4.9 in 2527 format)

5.1 Physical controls

(New location of Section 5.1 in 2527 format.)

CA equipment shall be protected from unauthorized access while the cryptographic module is installed and activated. The CA shall implement physical access controls to reduce the risk of equipment tampering even when the cryptographic module is not installed and activated. CA cryptographic tokens shall be protected against theft, loss, and unauthorized use.

(Old location of Section 5.1.1 in 2527 format) (Old location of Section 5.1.2 in 2527 format) (Old location of Section 5.1.3 in 2527 format) (Old location of Section 5.1.4 in 2527 format) (Old location of Section 5.1.5 in 2527 format) (Old location of Section 5.1.6 in 2527 format) (Old location of Section 5.1.7 in 2527 format) (Old location of Section 5.1.8 in 2527 format)

5.1.1 Site location and construction

(New location of Section 5.1.1 in 2527 format.)

The location and construction of the facility housing the CA equipment shall be consistent with facilities used to house high-value, sensitive information. The site location and construction, when combined with other physical security protection mechanisms such as guards and intrusion sensors, shall provide robust protection against unauthorized access to the CA equipment and records.

5.1.2 Physical access

(New location of Section 5.1.2 in 2527 format.)

At a minimum, the physical access controls should— • Ensure that no unauthorized access to the hardware is permitted • Ensure that all removable media and paper containing sensitive plain-text information is stored in secure containers. • Be manually or electronically monitored for unauthorized intrusion at all times • Ensure an access log is maintained and inspected periodically • Require two-person physical access control to both the cryptographic module and computer system Removable cryptographic modules shall be inactivated before storage. When not in use, removable cryptographic modules, activation information used to access or enable cryptographic modules, and CA equipment shall be placed in secure containers. Activation data shall be either memorized or recorded and stored in a manner commensurate with the security afforded the cryptographic module, and it shall not be stored with the cryptographic module. A security check of the facility housing the CA equipment shall occur if the facility is to be left unattended. At a minimum, the check shall verify the following: • The equipment is in a state appropriate to the current mode of operation (e.g., that cryptographic modules are in place when “open,” and secured when “closed,” and for the CA, that all equipment other than the repository is shut down)

Page 30

• Any security containers are properly secured • Physical security systems (e.g., door locks, vent covers) are functioning properly • The area is secured against unauthorized access. A person or group of persons shall be made explicitly responsible for making such checks. When a group of persons is responsible, a log identifying the person performing a check at each instance shall be maintained. If the facility is not continuously attended, the last person to depart shall initial a sign-out sheet that indicates the date and time and asserts that all necessary physical protection mechanisms are in place and activated.

5.1.3 Power and air conditioning

(New location of Section 5.1.3 in 2527 format.)

The CA shall have backup capability sufficient to automatically lock out input, finish any pending actions, and record the state of the equipment before lack of power or air conditioning causes a shutdown. The directories (containing CA-issued certificates and CRLs) shall be provided with uninterrupted power sufficient for a minimum of 6 hours operation in the absence of commercial power, to maintain availability and avoid denial of service.

5.1.4 Water exposures

(New location of Section 5.1.4 in 2527 format.)

CA equipment shall be installed such that it is not in danger of exposure to water (e.g., on tables or elevated floors).

5.1.5 Fire prevention and protection

(New location of Section 5.1.5 in 2527 format.)

No stipulation.

5.1.6 Media storage

(New location of Section 5.1.6 in 2527 format.)

Media shall be stored so as to protect them from accidental damage (e.g., water, fire, or electromagnetic). Media that contain audit, archive, or backup information shall be duplicated and stored in locations separate from the CAs.

5.1.7 Waste disposal

(New location of Section 5.1.7 in 2527 format.)

Sensitive media and documentation that are no longer needed for operations shall be destroyed in the disposal process. For example, sensitive paper documentation shall be shredded, burned, or other wise rendered unrecoverable.

5.1.8 Off-site backup

(New location of Section 5.1.8 in 2527 format.)

Full system backups, sufficient to recover from system failure, shall be made on a periodic schedule, described in a CA’s CPS. Backups are to be performed and stored offsite not less than once per week. At least one full backup copy shall be stored at an offsite location (separate from CA equipment). Only the latest full backup need be retained. The backup shall be stored at a site with physical and procedural controls commensurate to that of the operational CA.

Page 31

5.2 Procedural controls

(New location of Section 5.2 in 2527 format.) (Old location of Section 5.2.1 in 2527 format) (Old location of Section 5.2.2 in 2527 format) (Old location of Section 5.2.3 in 2527 format)

5.2.1 Trusted roles

(New location of Section 5.2.1 in 2527 format.)

A trusted role is one whose incumbent performs functions that can introduce security problems if not carried out properly, whether accidentally or maliciously. The people selected to fill these roles must be extraordinarily responsible, or the integrity of the CA will be weakened. The functions performed in these roles form the basis of trust for the entire PKI. Two approaches are taken to increase the likelihood that these roles can be successfully carried out. The first ensures that the person filling the role is trustworthy and properly trained. The second distributes the functions among more than one person, so that any malicious activity would require collusion. The primary trusted roles defined this policy are Administrator, Officer, Auditor, and Operator. These roles will be employed at both CA and RA locations as appropriate.

The administrator role is responsible for— • Installation, configuration, and maintenance of the CA hardware and software • Establishing and maintaining CA system accounts • Configuring certificate profiles or templates and audit parameters • Generating and backing up CA keys. Administrators do not issue certificates to subscribers.

The officer’s role and the corresponding procedures shall be defined in a CA’s CPS. The officer’s responsibility is to ensure the following functions occur according to the stipulations of this policy, that is— • Registering new subscribers and requesting the issuance of certificates • Verifying the identity of subscribers and the accuracy of information included in certificates • Approving and executing the issuance of certificates • Requesting, approving, and executing the revocation of certificates.

The auditor role is responsible for— • Reviewing, maintaining, and archiving audit logs • Performing or overseeing internal compliance audits to ensure that the CA and associated RAs are operating in accordance with its CPS.

Page 32

The operator role is responsible for the routine operation of the CA equipment and operations such as system backups and recovery, or changing recording media.

5.2.2 Number of persons required per task

(New location of Section 5.2.2 in 2527 format.)

Individual CA personnel shall be specifically designated to the four roles defined in Section 5.2.1 above. Individuals may only assume one of the Officer, Administrator, and Auditor roles, but any individual may assume the Operator role. The CA software and hardware shall identify and authenticate its users and shall ensure that no user identity can assume both an Administrator and an Officer role, assume both the Administrator and Auditor roles, and assume both the Auditor and Officer roles. No individual shall have more than one identity.

5.2.3 Identification and authentication for each role

(New location of Section 5.2.3 in 2527 format.)

An individual shall identify and authenticate him/herself before being permitted to perform any actions set forth above for that role or identity.

5.2.4 Roles requiring separation of duties

(New location of Section 5.2.2 in 2527 format.)

(New location of Section 5.2.1 in 2527 format.)

Page 32

The operator role is responsible for the routine operation of the CA equipment and operations such as system backups and recovery, or changing recording media.

5.3 Personnel controls

(New location of Section 5.3 in 2527 format.) (Old location of Section 5.3.1 in 2527 format) (Old location of Section 5.3.2 in 2527 format) (Old location of Section 5.3.3 in 2527 format) (Old location of Section 5.3.4 in 2527 format) (Old location of Section 5.3.5 in 2527 format) (Old location of Section 5.3.6 in 2527 format) (Old location of Section 5.3.7 in 2527 format) (Old location of Section 5.3.8 in 2527 format)

5.3.1 Qualifications, experience, and clearance requirements

(New location of Section 5.3.1 in 2527 format.)

All persons filling trusted roles shall be selected on the basis of loyalty, trustworthiness, and integrity, and must be U.S. citizens. The requirements governing the qualifications, selection and oversight of individuals who operate, manage, oversee, and audit the CA shall be set forth in the CA’s CPS.

5.3.2 Background check procedures

(New location of Section 5.3.2 in 2527 format.)

Background check procedures shall be described in a CA’s CPS and shall demonstrate that requirements set forth in Section 5.3.1 are met.

5.3.3 Training requirements

(New location of Section 5.3.3 in 2527 format.)

All personnel performing duties with respect to the operation of the CA shall receive comprehensive training. Training shall be conducted in the following areas: • CA (or RA) security principles and mechanisms • All PKI software versions in use on the CA (or RA) system • All PKI duties they are expected to perform • Disaster recovery and business continuity procedures • Stipulations of this policy.

5.3.4 Retraining frequency and requirements

(New location of Section 5.3.4 in 2527 format.)

All individuals responsible for PKI roles shall be made aware of changes in the CA operation. Any significant change to the operations shall have a training (awareness) plan, and the execution of such plan shall be documented. Examples of such changes are CA software or hardware upgrade, changes in automated security systems, and relocation of equipment

Page 33

5.3.5 Job rotation frequency and sequence

(New location of Section 5.3.5 in 2527 format.)

No stipulation.

5.3.6 Sanctions for unauthorized actions

(New location of Section 5.3.6 in 2527 format.)

The CA shall take appropriate administrative and disciplinary actions against personnel who have performed actions involving the CA or its RAs that are not authorized in this CP, the corresponding CPS, or other published procedures.

5.3.7 Independent contractor requirements

(New location of Section 5.3.7 in 2527 format.)

See 5.3.1. PKI vendors who provide any services shall establish procedures to ensure that any subcontractors perform in accordance with the CPS and this policy.

5.3.8 Documentation supplied to personnel

(New location of Section 5.3.8 in 2527 format.)

Documentation sufficient to define duties and procedures for each role shall be provided to the personnel filling that role.

5.4 Audit logging procedures

(New location of Section 4.5 in 2527 format.)

Audit log files shall be generated for all events relating to the security of the CA. Where possible, the security audit logs shall be automatically collected. Where this is not possible, a logbook, paper form, or other physical mechanism shall be used. All security audit logs, both 16

Page 23

electronic and non-electronic, shall be retained and made available during compliance audits. The security audit logs for each auditable event defined in this section shall be maintained in accordance with Section 4.5.3,Retention Period for Security Audit Data.

(Old location of Section 4.5.1 in 2527 format) (Old location of Section 4.5.2 in 2527 format) (Old location of Section 4.5.3 in 2527 format) (Old location of Section 4.5.4 in 2527 format) (Old location of Section 4.5.5 in 2527 format) (Old location of Section 4.5.6 in 2527 format) (Old location of Section 4.5.7 in 2527 format) (Old location of Section 4.5.8 in 2527 format)

5.4.1 Types of events recorded

(New location of Section 4.5.1 in 2527 format.)

All security auditing capabilities of CA operating system and PKI CA applications shall be enabled during installation. At a minimum, each audit record shall include the following (either recorded automatically or manually for each auditable event): • The type of event • The date and time the event occurred • A success or failure indicator when executing the CA’s signing process • A success or failure indicator when performing certificate revocation • The identity of the entity and/or operator that caused the event. A message from any source requesting an action by the CA is an auditable event; the message must include message date and time, source, destination, and contents. The CA shall record the events identified in the list below. Where these events cannot be electronically logged, the CA shall supplement electronic audit logs with physical logs as necessary. • SECURITY AUDIT: oAny changes to the Audit parameters, e.g., audit frequency, type of event audited oAny attempt to delete or modify the Audit logs oObtaining a third-party time-stamp • IDENTIFICATION AND AUTHENTICATION: oSuccessful and unsuccessful attempts to assume a role oThe value of maximum authentication attempts is changed oMaximum authentication attempts unsuccessful authentication attempts occur during user login oAn Administrator unlocks an account that has been locked as a result of unsuccessful authentication attempts oAn Administrator changes the type of authenticator, e.g., from password to biometrics • LOCAL DATA ENTRY: oAll security-relevant data that is entered in the system • REMOTE DATA ENTRY: oAll security-relevant messages that are received by the system • DATA EXPORT AND OUTPUT: oAll successful and unsuccessful requests for confidential and security-relevant information • KEY GENERATION:

Page 24

oWhenever the CA generates a key. (Not mandatory for single session or one-time use symmetric keys) • PRIVATE KEY LOAD AND STORAGE: oThe loading of Component private keys oAll access to certificate subject private keys retained within the CA for key recovery purposes • TRUSTED PUBLIC KEY ENTRY, DELETION AND STORAGE: oAll changes to the trusted public keys, including additions and deletions • SECRET KEY STORAGE: oThe manual entry of secret keys used for authentication • PRIVATE AND SECRET KEY EXPORT: oThe export of private and secret keys (keys used for a single session or message are excluded) • CERTIFICATE REGISTRATION: oAll certificate requests • CERTIFICATE REVOCATION: oAll certificate revocation requests • CERTIFICATE STATUS CHANGE APPROVAL: oThe approval or rejection of a certificate status change request • CA CONFIGURATION: oAny security-relevant changes to the configuration of the CA • ACCOUNT ADMINISTRATION: oRoles and users are added or deleted oThe access control privileges of a user account or a role are modified • CERTIFICATE PROFILE MANAGEMENT oAll changes to the certificate profile • REVOCATION PROFILE MANAGEMENT oAll changes to the revocation profile • CERTIFICATE REVOCATION LIST PROFILE MANAGEMENT oAll changes to the certificate revocation list profile • MISCELLANEOUS oAppointment of an individual to a Trusted Role oDesignation of personnel for multiparty control oInstallation of the Operating System oInstallation of the CA oInstalling hardware cryptographic modules oRemoving hardware cryptographic modules oDestruction of cryptographic modules oSystem Startup oLogon Attempts to CA Apps oReceipt of Hardware / Software 18

Page 25

oAttempts to set passwords oAttempts to modify passwords oBacking up the CA internal database oRestoring the CA internal database oFile manipulation (e.g., creation, renaming, moving) oPosting of any material to a repository oAccess to the CA internal database oAll certificate compromise notification requests oLoading tokens with certificates oShipment of Tokens oZeroizing tokens oRekey of the CA oConfiguration changes to the CA server involving: Hardware Software Operating System Patches Security Profiles • PHYSICAL ACCESS / SITE SECURITY oPersonnel Access to the room housing the CA oAccess to the CA server oKnown or suspected violations of physical security • ANOMALIES oSoftware Error conditions oSoftware check integrity failures oReceipt of improper messages oMisrouted messages oNetwork attacks (suspected or confirmed) oEquipment failure oElectrical power outages oUninterruptible Power Supply (UPS) failure oObvious and significant network service or access failures oViolations of Certificate Policy oViolations of Certification Practice Statement oResetting Operating System clock

5.4.2 Frequency of processing log

(New location of Section 4.5.2 in 2527 format.)

Review of the audit log shall be required at least once every two months. All significant events shall be explained in an audit log summary. A statistically significant portion of the security audit data generated by the CA since the last review shall be examined. This amount will be 19

Page 26

described in the CPS. Such reviews involve verifying that the log has not been tampered with and then briefly inspecting all log entries, with a more thorough investigation of any alerts or irregularities in the logs. Actions taken as a result of these reviews shall be documented.

5.4.3 Retention period for audit log

(New location of Section 4.5.3 in 2527 format.)

Audit logs shall be retained onsite for at least 2 months in addition to being retained in the manner described below. The individual who removes audit logs from the CA system shall be an official different from the individuals who, in combination, command the CA signature key.

5.4.4 Protection of audit log

(New location of Section 4.5.4 in 2527 format.)

The security audit data shall not be open for reading or modification by any human, or by any automated process, other than those that perform security audit processing. CA system configuration and procedures must be implemented together to ensure that only authorized people archive or delete security audit data. Procedures must be implemented to protect archived data from deletion or destruction before the end of the security audit data retention period (note that deletion requires modification access). Security audit data shall be moved to a safe, secure storage location separate from the CA equipment.

5.4.5 Audit log backup procedures

(New location of Section 4.5.5 in 2527 format.)

Audit logs and audit summaries shall be backed up at least monthly. A copy of the audit log shall be sent offsite in accordance with the CPS, on a monthly basis.

5.4.6 Audit collection system (internal vs. external)

(New location of Section 4.5.6 in 2527 format.)

The audit log collection system may or may not be external to the CA system. Automated audit processes shall be invoked at system or application startup, and cease only at system or application shutdown. Should it become apparent that an automated audit system has failed, and the integrity of the system or confidentiality of the information protected by the system is at risk, operations shall be suspended until the problem has been remedied. The PA, as specified in its charter, shall determine when to resume operations.

5.4.7 Notification to event-causing subject

(New location of Section 4.5.7 in 2527 format.)

There is no requirement to notify a subject that an event was audited. Real-time alerts are neither required nor prohibited by this policy.

5.4.8 Vulnerability assessments

(New location of Section 4.5.8 in 2527 format.)

The CA will perform routine self-assessments of security controls.

5.5 Records archival

(New location of Section 4.6 in 2527 format.) (Old location of Section 4.6.1 in 2527 format) (Old location of Section 4.6.2 in 2527 format) (Old location of Section 4.6.3 in 2527 format) (Old location of Section 4.6.4 in 2527 format) (Old location of Section 4.6.5 in 2527 format) (Old location of Section 4.6.6 in 2527 format) (Old location of Section 4.6.7 in 2527 format)

5.5.1 Types of records archived

(New location of Section 4.6.1 in 2527 format.)

CA archive records shall be sufficiently detailed to determine the proper operation of the CA and the validity of any certificate (including those revoked or expired) issued by the CA. At a minimum, the following data shall be recorded for archive: • CA accreditation (if applicable) 20

Page 27

• Certificate Policy • Certification Practice Statement • Contractual obligations • Other agreements concerning operations of the CA • System and equipment configuration • Modifications and updates to system or configuration • Certificate requests • All certificates issued and/or published • Record of Re-key • Security audit data (in accordance with Section 4.5) • Revocation requests • Subscriber identity Authentication data as per Section 3.1.9 • Subscriber agreements • Documentation of receipt of tokens • All CRLs issued and/or published • Other data or applications to verify archive contents • Documentation required by compliance auditors In addition, CAs that retain subscriber private encryption keys for business continuity purposes shall archive such subscriber private keys.

5.5.2 Retention period for archive

(New location of Section 4.6.2 in 2527 format.)

The archive records must be kept for a minimum of 10 years and 6 months without any loss of data.

5.5.3 Protection of archive

(New location of Section 4.6.3 in 2527 format.)

No unauthorized user shall be permitted to write to, modify, or delete the archive. For the CA, archived records may be moved to another medium. The contents of the archive shall not be released except (1) in accordance with agency policy, or (2) as required by law. Records of individual transactions may be released upon request of any subscribers involved in the transaction or their legally recognized agents. Archive media shall be stored in a safe, secure storage facility separate from the CA.

5.5.4 Archive backup procedures

(New location of Section 4.6.4 in 2527 format.)

No stipulation.

5.5.5 Requirements for time-stamping of records

(New location of Section 4.6.5 in 2527 format.)

CA archive records shall be automatically time-stamped as they are created. The CPS shall describe how system clocks used for time-stamping are maintained in synchrony with an authoritative time standard.

5.5.6 Archive collection system (internal or external)

(New location of Section 4.6.6 in 2527 format.)

Archive data may be collected in any expedient manner.

Page 28

5.5.7 Procedures to obtain and verify archive information

(New location of Section 4.6.7 in 2527 format.)

Procedures detailing how to create, verify, package, transmit, and store the CA archive information shall be published in the CPS.

5.6 Key changeover

(New location of Section 4.7 in 2527 format.)

To minimize risk from compromise of a CA’s private signing key, that key may be changed often. From that time on, only the new key will be used for certificate signing purposes. If the old private key is used to sign CRLs that contain certificates signed with that key, the old key must be retained and protected. The CA’s signing key shall have a validity period as described in Section 6.3.2.

5.7 Compromise and disaster recovery

(New location of Section 4.8 in 2527 format.)

The CA and directory system shall be deployed so as to provide 24-hour, 365-day availability. The CA shall implement features to provide high levels of reliability. The following subsections outline the policy for instances that may prevent such maintenance of reliability. The CA shall have recovery procedures in place to reconstitute the CA within 72 hours in the event of a catastrophic failure, as described in the following subsections.

(Old location of Section 4.8.1 in 2527 format) (Old location of Section 4.8.2 in 2527 format) (Old location of Section 4.8.3 in 2527 format) (Old location of Section 4.8.4 in 2527 format)

5.7.1 Incident and compromise handling procedures

(New location of Section 4.8 in 2527 format.)

(Old location of Section 4.8.1 in 2527 format) (Old location of Section 4.8.2 in 2527 format) (Old location of Section 4.8.3 in 2527 format) (Old location of Section 4.8.4 in 2527 format)

5.7.2 Computing resources, software, and/or data are corrupted

(New location of Section 4.8.1 in 2527 format.)

If the CA equipment is damaged or rendered inoperative, but the CA signature keys are not destroyed, CA operation shall be reestablished as quickly as possible, giving priority to the ability to generate certificate status information. The PA shall be notified as soon as possible.

5.7.3 Entity private key compromise procedures

(New location of Section 4.8.3 in 2527 format.)

In case of a CA key compromise, the PA and EAO shall be immediately informed, as well as any superior CAs. Subsequently, the CA installation shall be reestablished. If the CA distributes a trusted certificate for use as a trust anchor, the new self-signed certificate must be distributed via secure out-of-band mechanisms. The CPS shall detail the secure out-of-band mechanisms. Subscriber certificates may be renewed automatically by the CA under the new key pair, or the CA may require subscribers to repeat the initial certificate application process.

5.7.4 Business continuity capabilities after a disaster

(New location of Section 4.8.4 in 2527 format.)

In the case of a disaster whereby the CA installation is physically damaged and all copies of the CA signature key are destroyed as a result, the PA and EAO shall be notified at the earliest feasible time, and the PA shall take whatever action it deems appropriate. Relying parties may decide of their own volition whether to continue to use certificates signed with the destroyed private key pending reestablishment of CA operation with new certificates. 22

Page 29

5.8 CA or RA termination

(New location of Section 4.9 in 2527 format.)

In the event of termination of the CA operation, certificates signed by the CA shall be revoked. Prior to CA termination, the CA shall provide archived data to an archive facility as specified in the CPS. As soon as possible, the CA will advise all other organizations to which it has issued certificates of the CA termination, using an agreed-upon method of communication specified in the CPS.

6. Technical Security Controls

(New location of Section 2.1.4 in 2527 format.)

(New location of Section 2.1.3 in 2527 format.)

Page 12

(New location of Section 6 in 2527 format.) (Old location of Section 6.1 in 2527 format) (Old location of Section 6.2 in 2527 format) (Old location of Section 6.3 in 2527 format) (Old location of Section 6.4 in 2527 format) (Old location of Section 6.5 in 2527 format) (Old location of Section 6.6 in 2527 format) (Old location of Section 6.7 in 2527 format) (Old location of Section 6.8 in 2527 format)

6.1 Key pair generation and installation

(New location of Section 6.1 in 2527 format.) (Old location of Section 6.1.1 in 2527 format) (Old location of Section 6.1.2 in 2527 format) (Old location of Section 6.1.3 in 2527 format) (Old location of Section 6.1.4 in 2527 format) (Old location of Section 6.1.5 in 2527 format) (Old location of Section 6.1.6 in 2527 format) (Old location of Section 6.1.7 in 2527 format) (Old location of Section 6.1.8 in 2527 format) (Old location of Section 6.1.9 in 2527 format)

6.1.1 Key pair generation

(New location of Section 6.1.8 in 2527 format.)

Validated software or hardware cryptographic modules shall be used to generate all subscriber key pairs, as well as pseudo-random numbers and parameters used in key pair generation. Any pseudo-random numbers used for key generation material shall be generated by a FIPS-approved method. Symmetric keys may be generated by means of either software or hardware mechanisms.

(New location of Section 6.1.1 in 2527 format.)

Cryptographic keying material used by CAs to sign certificates, CRLs or status information shall be generated in FIPS 140 validated cryptographic modules. The module(s) shall meet or exceed Security Level 2. Multiparty control is required for CA key pair generation, as specified in Section 5.2.2. CA key pair generation must create a verifiable audit trail that the security requirements for procedures were followed. The audit trail must identify and document any failures or anomalies in the key generation process, and any corrective actions taken. For all levels of assurance, the documentation of the procedure must be detailed enough to show that appropriate role separation was used.

Where the subscriber is an agency application server, either the subscriber or an e-Governance CA shall generate the subscriber key pair. In all other cases, the subscriber shall perform their own key pair generation. Key generation shall be performed using a FIPS approved method.

Page 34

6.1.2 Private key delivery to subscriber

(New location of Section 6.1.2 in 2527 format.)

If subscribers generate their own key pairs, then there is no need to deliver private keys, and this section does not apply. Where the Subscriber is an agency application server and an e-Governance CA generates the key pair, then the private key must be delivered securely to the Subscriber. Private keys may be delivered electronically or may be delivered on a hardware cryptographic module. The e- Governance CA shall not retain any copy of the key after delivery of the private key to the Subscriber. The Subscriber shall acknowledge receipt of the private key(s).

6.1.3 Public key delivery to certificate issuer

(New location of Section 6.1.3 in 2527 format.)

The public key and the Subscriber’s identity must be delivered securely to the CA for certificate issuance. The delivery mechanism shall bind the Subscriber’s verified identity to the public key. If cryptography is used to achieve this binding, it must be at least as strong as the CA keys used to sign the certificate.

6.1.4 CA public key delivery to relying parties

(New location of Section 6.1.4 in 2527 format.)

When a CA updates its signature key pair, the CA shall distribute the new public key in a secure fashion. The new public key may be distributed in a self-signed certificate or in a key rollover certificate. Self-signed certificates shall be conveyed to relying parties in a secure fashion to preclude substitution attacks. Acceptable methods for self-signed certificate delivery are: • The CA loading a self-signed certificate onto tokens delivered to Relying Parties via secure mechanisms; • Secure distribution of self-signed certificates through secure out-of-band mechanisms; • Comparison of the hash of the self-signed certificate against a hash value made available via authenticated out-of-band sources (note that hashes posted in-band along with the certificate are not acceptable as an authentication mechanism); and • Loading certificates from web sites secured with a currently valid certificate of equal or greater assurance level than the certificate being downloaded. [Practice Note: Other methods that preclude substitution attacks may be considered acceptable.] Key rollover certificates are signed with the CA’s current private key, so secure distribution is not required. [Practice Note: To ensure the availability of the new public key, the key rollover certificates should be distributed using directories and other repositories.]

6.1.5 Key sizes

(New location of Section 6.1.5 in 2527 format.)

This CP requires use of RSA PKCS 1 signatures; additional restrictions on key sizes and hash algorithms are detailed below. Certificates issued under this policy shall contain RSA public keys. [Practice Note: Future versions of this policy may specify additional FIPS-approved signature algorithms.] CAs that generate certificates and CRLs under this policy shall use signature keys of at least 2048 bit keys. 28

Page 35

CAs that generate certificates and CRLs under this policy shall use SHA-1, or SHA-256 hash algorithm when generating digital signatures. Signatures on certificates and CRLs that are issued before January 1, 2011 shall be generated using SHA-1 or SHA-256. Signatures on certificates and CRLs that are issued on or after January 1, 2011 shall be generated using SHA-256. End entity certificates that expire before January 1, 2011 shall contain RSA public keys that are at least 1024 bits in length. End entity certificates that expire on or after January 1, 2011 shall contain RSA public keys that are at least 2048 bits. Use of TLS or another protocol providing similar security to accomplish certificate issuance or any of the requirements of this CP shall require (1) triple-DES or AES for the symmetric key through 12/31/2010 and AES for the symmetric key after 12/31/2010 and (2) at least 1024 bit RSA or 163 bit elliptic curve keys through 12/31/2008 and at least 2048 bit RSA or 224 bit elliptic curve keys after 12/31/2008.

6.1.6 Public key parameters generation and quality checking

(New location of Section 6.1.7 in 2527 format.)

Parameter quality checking (including primarily testing for prime numbers) shall be performed in accordance with FIPS 186-2.

(New location of Section 6.1.6 in 2527 format.)

Public key parameters shall always be generated and checked in accordance with the standard that defines the cryptographic algorithm in which the parameters are to be used. Public key parameters prescribed in the Digital Signature Standard (DSS) shall be generated in accordance with FIPS 186-2.

6.1.7 Key usage purposes (as per X.509 v3 key usage field)

6.2 Private Key Protection and Cryptographic Module Engineering Controls

(New location of Section 6.8 in 2527 format.)

Requirements for cryptographic modules are as stated above in Section 6.2

(New location of Section 6.2 in 2527 format.) (Old location of Section 6.2.1 in 2527 format) (Old location of Section 6.2.2 in 2527 format) (Old location of Section 6.2.3 in 2527 format) (Old location of Section 6.2.4 in 2527 format) (Old location of Section 6.2.5 in 2527 format) (Old location of Section 6.2.6 in 2527 format) (Old location of Section 6.2.7 in 2527 format) (Old location of Section 6.2.8 in 2527 format) (Old location of Section 6.2.9 in 2527 format)

6.2.1 Cryptographic module standards and controls

(New location of Section 6.2.1 in 2527 format.)

The relevant standard for cryptographic modules isSecurity Requirements for Cryptographic Modules[FIPS 140-2]. The PA may determine that other comparable validation, certification, or verification standards are sufficient. The PA will publish these standards. Cryptographic modules shall be validated to a FIPS 140 level identified in this section, or validated, certified, or verified to requirements published by the PA. The CA and RA shall use a FIPS 140 Level 2 or higher validated hardware cryptographic module. Subscribers shall use a FIPS 140 Level 1 or higher validated cryptographic module for all cryptographic operations.

(New location of Section 6.8 in 2527 format.)

Requirements for cryptographic modules are as stated above in Section 6.2

6.2.2 Private key (n out of m) multi-person control

(New location of Section 6.2.2 in 2527 format.)

A single person shall not be permitted to invoke the complete CA signature process or access any cryptomodule containing the complete CA private signing key. CA signature keys may be backed up only under two-person control. Access to CA signing keys backed up for disaster recovery shall be under at least two-person control. The names of the parties used for two- person control shall be maintained on a list that shall be made available for inspection during compliance audits.

6.2.3 Private key escrow

(New location of Section 6.2.3 in 2527 format.)

Neither CA nor Subscriber private keys are ever escrowed.

6.2.4 Private key backup

(New location of Section 6.2.4 in 2527 format.)

The CA private signature keys shall be backed up under the same multiperson control as the original signature key. Such backup shall create only a single copy of the signature key at the CA location; a second copy may be kept at the CA backup location. Backup procedures shall be included in the CA’s CPS.

Subscriber private keys whose corresponding public key is contained in a certificate may be backed up or copied, but must be held in the subscriber’s control. Backed up subscriber private keys must be encrypted using a symmetric algorithm of consistent strength or stored in a cryptographic module validated at FIPS 140 Level 2.

6.2.5 Private key archival

(New location of Section 6.2.5 in 2527 format.)

CA and subscriber private keys shall not be archived.

6.2.6 Private key transfer into or from a cryptographic module

(New location of Section 6.2.6 in 2527 format.)

Subscriber keys shall be generated by and in a cryptographic module. In the event that a private key is to be transported from one cryptographic module to another, the private key must be

Page 37

encrypted during transport; private keys must never exist in plaintext form outside the cryptographic token boundary. Private or symmetric keys used to encrypt other private keys for transport must be protected from disclosure.

6.2.7 Private key storage on cryptographic module

(New location of Section 6.2.6 in 2527 format.)

Subscriber keys shall be generated by and in a cryptographic module. In the event that a private key is to be transported from one cryptographic module to another, the private key must be

Page 37

6.2.8 Method of activating private key

(New location of Section 6.2.7 in 2527 format.)

The subscriber must be authenticated to the cryptographic token before the activation of any private key(s). Acceptable means of authentication include but are not limited to pass-phrases, PINs or biometrics. Entry of activation data shall be protected from disclosure (i.e., the data should not be displayed while it is entered).

6.2.9 Method of deactivating private key

(New location of Section 6.2.8 in 2527 format.)

Cryptographic modules that have been activated shall not be available to unauthorized access.

6.2.10 Method of destroying private key

(New location of Section 6.2.9 in 2527 format.)

Private keys shall be destroyed when they are no longer needed or when the certificates to which they correspond expire or are revoked. This may be performed by executing a “zeroize” command. Physical destruction of hardware is not required.

6.2.11 Cryptographic Module Rating

(New location of Section 6.8 in 2527 format.)

Requirements for cryptographic modules are as stated above in Section 6.2

6.3 Other aspects of key pair management

(New location of Section 6.3 in 2527 format.) (Old location of Section 6.3.1 in 2527 format) (Old location of Section 6.3.2 in 2527 format)

6.3.1 Public key archival

(New location of Section 6.3.1 in 2527 format.)

The public key is archived as part of the certificate archival.

6.3.2 Certificate operational periods and key pair usage periods

(New location of Section 6.3.2 in 2527 format.)

The usage period for a CA key pair is a maximum of six years. The CA private key may be used to generate certificates for the first half of the usage period (3 years), and the public key may be used to validate certificates for the entire usage period. If the CA private key is used to sign CRLs, it may be used to sign CRLs for the entire usage period. Subscriber public keys have a maximum usage period of one half the CA key pair usage period. Subscriber private keys have the same usage period as their corresponding public key.

6.4 Activation data

(New location of Section 6.4 in 2527 format.) (Old location of Section 6.4.1 in 2527 format) (Old location of Section 6.4.2 in 2527 format) (Old location of Section 6.4.3 in 2527 format)

6.4.1 Activation data generation and installation

(New location of Section 6.4.1 in 2527 format.)

CA activation data may be user-selected (by each of the multiple parties holding that activation data). If the activation data must be transmitted, it shall be via an appropriately protected channel, and distinct in time and place from the associated cryptographic module. RA and Subscriber activation data may be user-selected. If the activation data must be transmitted, it shall be via an appropriately protected channel, and distinct in time and place from the associated cryptographic module.

Page 38

6.4.2 Activation data protection

(New location of Section 6.4.2 in 2527 format.)

Data used to unlock private keys shall be protected from disclosure by a combination of cryptographic and physical access control mechanisms. Activation data should be either biometric in nature or memorized (not written down). If written down, activation data shall be physically secured or encrypted under a FIPS approved cryptographic algorithm, and shall not be stored with the cryptographic module.

6.4.3 Other aspects of activation data

(New location of Section 6.4.3 in 2527 format.)

No stipulation.

6.5 Computer security controls

(New location of Section 6.5 in 2527 format.)

Computer security controls are required to ensure CA/RA operations are performed as specified in this policy. The following computer security functions may be provided by the operating system, or through a combination of operating system, software, and physical safeguards: • Require authenticated logins • Provide Discretionary Access Control • Provide a security audit capability • Restrict access control to CA services and PKI roles • Enforce separation of duties for PKI roles • Require identification and authentication of PKI roles and associated identities • Prohibit object reuse or require separation for CA random access memory • Require use of cryptography for session communication and database security • Archive CA history and audit data • Require self-test security-related CA services • Require a trusted path for identification of PKI roles and associated identities • Require a recovery mechanism for keys and the CA system • Enforce domain integrity boundaries for security-critical processes. When CA equipment is hosted on evaluated platforms in support of computer security assurance requirements, the system (hardware, software, operating system) shall, when possible, operate in an evaluated configuration. At a minimum, such platforms shall use the same version of the computer operating system as that which received the evaluation rating.

6.5.1 Specific computer security technical requirements

6.5.2 Computer security rating

6.6 Life cycle technical controls

(New location of Section 6.6 in 2527 format.) (Old location of Section 6.6.1 in 2527 format) (Old location of Section 6.6.2 in 2527 format) (Old location of Section 6.6.3 in 2527 format)

6.6.1 System development controls

(New location of Section 6.6.1 in 2527 format.)

The System Development Controls for the CA and RA are as follows: • The CA shall use software that has been designed and developed under a formal, documented development methodology. • Hardware and software procured to operate the CA shall be purchased in a fashion to reduce the likelihood that any particular component was tampered with (e.g., by ensuring the equipment was randomly selected at time of purchase). • Hardware and software developed specifically for the CA shall be developed in a controlled environment, and the development process shall be defined and documented. This requirement does not apply to commercial off-the-shelf hardware or software. 32

Page 39

• The CA hardware and software shall be dedicated to performing one task: the CA. There shall be no other applications, hardware devices, network connections, or component software installed that are not parts of the CA operation. Where the CA operation supports multiple CAs, the hardware platform can support multiple CAs. • Proper care shall be taken to prevent malicious software from being loaded onto the CA equipment. Only applications required to perform the operation of the CA shall be obtained from sources authorized by local policy. RA hardware and software shall be scanned for malicious code on first use and periodically thereafter. • Hardware and software updates shall be purchased or developed in the same manner as original equipment, and shall be installed by trusted and trained personnel in a defined manner.

6.6.2 Security management controls

(New location of Section 6.6.2 in 2527 format.)

The configuration of the CA system, in addition to any modifications and upgrades, shall be documented and controlled. There shall be a mechanism for detecting unauthorized modification to the software or configuration. The CA software, when first loaded, shall be verified as being that supplied from the vendor, with no modifications, and be the version intended for use. The CA shall periodically verify the integrity of the software as specified in the CPS.

6.6.3 Life cycle security controls

(New location of Section 6.6.3 in 2527 format.)

No stipulation.

6.7 Network security controls

(New location of Section 6.7 in 2527 format.)

A network guard, firewall, or filtering router must protect network access to CA equipment. The network guard, firewall, or filtering router shall limit services allowed to and from the CA equipment to those required to perform CA functions. Protection of CA equipment shall be provided against known network attacks. All unused network ports and services shall be turned off. Any network software present on the CA equipment shall be necessary to the functioning of the CA application. Any boundary control devices used to protect the network on which PKI equipment is hosted shall deny all but the necessary services to the PKI equipment.

6.8 Time-stamping

7. Certificate, CRL, and OCSP Profiles

(New location of Section 7 in 2527 format.) (Old location of Section 7.1 in 2527 format) (Old location of Section 7.2 in 2527 format)

7.1 Certificate profile

(New location of Section 7.1 in 2527 format.)

Certificates issued by a CA under this policy shall conform to the Common CP Certificate Profile [CCP-PROF], except as specified below. Subscriber certificates shall conform to the Certificate Profile for Computing and Communication Devices in [CCP-PROF], except that the certificatePolicies extension shall assert one of the policies specified in Section 7.1.6 instead of id-fpki-common-devices and the LDAP URI in the authorityInfoAccess extension does not need to specify the crossCertificatePair attribute. Self-Signed certificates shall conform to the Self- 33

Page 40

Signed Certificate Profile in [CCP-PROF], except that the subjectInfoAccess extension does not need to be included. CA certificates that are not self-signed shall conform to the Self-Issued CA Certificate Profile in [CCP-PROF], except that the certificatePolicies extension shall assert one of the policies specified in Section 7.1.6 instead of the OIDs from the Common Certificate Policy and the authorityInfoAccess and subjectInfoAccess extensions do not need to be included.

(Old location of Section 7.1.1 in 2527 format) (Old location of Section 7.1.2 in 2527 format) (Old location of Section 7.1.3 in 2527 format) (Old location of Section 7.1.4 in 2527 format) (Old location of Section 7.1.5 in 2527 format) (Old location of Section 7.1.6 in 2527 format) (Old location of Section 7.1.7 in 2527 format) (Old location of Section 7.1.8 in 2527 format) (Old location of Section 7.1.9 in 2527 format)

7.1.1 Version number(s)

(New location of Section 7.1.1 in 2527 format.)

The CA shall issue X.509 v3 certificates (populate version field with integer “2”).

7.1.2 Certificate extensions

(New location of Section 7.1.2 in 2527 format.)

Rules for the inclusion, assignment of value, and processing of extensions are defined in [CCP- PROF].

7.1.3 Algorithm object identifiers

(New location of Section 7.1.3 in 2527 format.)

Certificates issued under this CP shall use the following OIDs for signatures: sha1WithRSAEncryption {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs- 1(1) 5} sha256WithRSAEncryption {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs- 1(1) 11} Certificates issued under this CP shall use the following OID to identify the algorithm associated with the subject key: RsaEncryption {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}

7.1.4 Name forms

(New location of Section 7.1.4 in 2527 format.)

The subject and issuer fields of the base certificate shall be populated with an X.500 Distinguished Name, with the attribute type as further constrained by Section 3.1.1. Subscriber certificates shall contain Internet Domain Names, as specified in Section 3.1.1.

7.1.5 Name constraints

(New location of Section 7.1.5 in 2527 format.)

Certificates issued under this CP shall not contain name constraints.

7.1.6 Certificate policy object identifier

(New location of Section 7.1.6 in 2527 format.)

Certificates issued under this CP shall assert one or both of the following OIDs in the certificate policies extension, as appropriate: id-eGov-Level1 ::= {2 16 840 1 101 3 2 1 3 9} id- eGov-Level2::= {2 16 840 1 101 3 2 1 3 10} id-eGov-Applications ::= {2 16 840 1 101 3 2 1 3 11}

Page 41

7.1.7 Usage of Policy Constraints extension

(New location of Section 7.1.7 in 2527 format.)

Certificates issued under this CP shall not contain policy constraints.

7.1.8 Policy qualifiers syntax and semantics

(New location of Section 7.1.8 in 2527 format.)

Certificates issued under this CP shall not contain policy qualifiers.

7.1.9 Processing semantics for the critical Certificate Policies extension

(New location of Section 7.1.9 in 2527 format.)

Certificates issued under this policy shall not contain a critical certificate policy extension.

7.2 CRL profile

(New location of Section 7.2 in 2527 format.)

CRLs issued by a CA under this policy shall conform to the CRL Profile specified in [CCP- PROF].

(Old location of Section 7.2.1 in 2527 format) (Old location of Section 7.2.2 in 2527 format)

7.2.1 Version number(s)

(New location of Section 7.2.2 in 2527 format.)

Detailed CRL profiles addressing the use of each extension are specified in [CCP-PROF].

(New location of Section 7.2.1 in 2527 format.)

The CAs shall issue X.509 Version two (2) CRLs.

7.2.2 CRL and CRL entry extensions

7.3 OCSP profile

7.3.1 Version number(s)

7.3.2 OCSP extensions

8. Compliance Audit and Other Assessments

(New location of Section 2.7 in 2527 format.) (Old location of Section 2.7.1 in 2527 format) (Old location of Section 2.7.2 in 2527 format) (Old location of Section 2.7.3 in 2527 format) (Old location of Section 2.7.4 in 2527 format) (Old location of Section 2.7.5 in 2527 format) (Old location of Section 2.7.6 in 2527 format) (New location of Section 2 in 2527 format.) (Old location of Section 2.1 in 2527 format) (Old location of Section 2.2 in 2527 format) (Old location of Section 2.3 in 2527 format) (Old location of Section 2.4 in 2527 format) (Old location of Section 2.5 in 2527 format) (Old location of Section 2.6 in 2527 format) (Old location of Section 2.7 in 2527 format) (Old location of Section 2.8 in 2527 format) (Old location of Section 2.9 in 2527 format)

8.1 Frequency of circumstances of assessment

(New location of Section 2.7.1 in 2527 format.)

CAs and RAs operating under this policy shall conduct a compliance audit no less than once every year. Additionally, the PA has the right to require aperiodic inspections of CAs and RAs to validate that the CA/RA is operating in accordance with their CPS.

8.2 Identity/qualifications of assessor

(New location of Section 2.7.2 in 2527 format.)

The auditor must demonstrate competence in the field of compliance audits, and must be thoroughly familiar with the CA’s CPS and this CP.

8.3 Assessor's relationship to assessed entity

(New location of Section 2.7.3 in 2527 format.)

The compliance auditor either shall be a private firm, which is independent from the entities (CA and RAs) being audited, or it shall be sufficiently organizationally separated from those entities to provide an unbiased, independent evaluation. An example of the latter situation may be an Agency inspector general. The PA shall determine whether a compliance auditor meets this requirement.

8.4 Topics covered by assessment

(New location of Section 2.7.4 in 2527 format.)

The purpose of a compliance audit shall be to verify that a CA and its recognized RAs comply with all the requirements of the current versions of this CP and the CA’s CPS. All aspects of the CA/RA operation shall be subject to compliance audit inspections. The process used by the EAO to determine if a certificate should be issued to a CSP or agency application server is out of scope for the compliance audit.

8.5 Actions taken as a result of deficiency

(New location of Section 2.7.5 in 2527 format.)

When the compliance auditor finds a discrepancy between the requirements of this CP or the stipulations in the CPS and the design, operation, or maintenance of the PKI Authorities, the following actions shall be performed:

Page 15

• The compliance auditor shall note the discrepancy; • The compliance auditor shall notify the parties identified in Section 2.7.6 of the discrepancy; • The party responsible for correcting the discrepancy will propose a remedy, including expected time for completion, to the PA. Depending upon the nature and severity of the discrepancy, and how quickly it can be corrected, the PA may decide to temporarily halt operation of the CA or RA, to revoke a certificate issued to the CA or RA, or take other actions it deems appropriate. The PA will develop procedures for making and implementing such determinations.

8.6 Communication of results

(New location of Section 2.7.6 in 2527 format.)

An Audit Compliance Report shall be provided to the CA. After 30 days, the Audit Compliance Report and identification of corrective measures taken or being taken by the CA or RA shall be provided to the PA. A special compliance audit may be required to confirm the implementation and effectiveness of the remedy.

9. Other Business and Legal Matters

(New location of Section 2 in 2527 format.) (Old location of Section 2.1 in 2527 format) (Old location of Section 2.2 in 2527 format) (Old location of Section 2.3 in 2527 format) (Old location of Section 2.4 in 2527 format) (Old location of Section 2.5 in 2527 format) (Old location of Section 2.6 in 2527 format) (Old location of Section 2.7 in 2527 format) (Old location of Section 2.8 in 2527 format) (Old location of Section 2.9 in 2527 format)

9.1 Fees

(New location of Section 2.5 in 2527 format.)

No stipulation.

9.1.1 Certificate issuance of renewal fees

9.1.2 Certificate access fees

9.1.3 Revocation or status information access fees

9.1.4 Fees for other services

9.1.5 Refund policy

9.2 Financial responsibility

(New location of Section 2.3 in 2527 format.)

This CP contains no limits on the use of certificates issued by CAs under this policy. Rather, entities, acting as Relying Parties, shall determine what financial limits, if any, they wish to impose for certificates used to consummate a transaction.

(Old location of Section 2.3.1 in 2527 format) (Old location of Section 2.3.2 in 2527 format)

9.2.1 Insurance coverage

9.2.2 Other assets

9.2.3 Insurance or warranty coverage for end-entities

9.3 Confidentiality of business information

(New location of Section 2.8 in 2527 format.)

CA information not requiring protection shall be made publicly available. Public access to organizational information shall be determined by the respective organization.

9.3.1 Scope of confidential information

9.3.2 Information not within the scope of confidential information

9.3.3 Responsiblity to protect confidential information

9.4 Privacy of personal information

(New location of Section 2.8 in 2527 format.)

CA information not requiring protection shall be made publicly available. Public access to organizational information shall be determined by the respective organization.

9.4.1 Privacy plan

9.4.2 Information treated as private

9.4.3 Information not deemed private

9.4.4 Responsibility to protect private information

9.4.5 Notice and consent to use private information

9.4.6 Disclosure pursuant to judicial or administrative process

9.4.7 Other information disclosure circumstances

9.5 Intellectual property rights

(New location of Section 2.9 in 2527 format.)

No stipulation.

Page 16

9.6 Representations and warranties

(New location of Section 2.2 in 2527 format.)

The U.S. Government shall not be liable to any party, except as determined pursuant to the Federal Tort Claims Act (FTCA), 28 U.S.C. 2671-2680, or as determined through a valid express written contract between the Government and another party.

9.6.1 CA representations and warranties

9.6.2 RA representations and warranties

9.6.3 Subscriber representations and warranties

(New location of Section 2.1.3 in 2527 format.)

Page 12

9.6.4 Relying party representations and warranties

(New location of Section 2.1.4 in 2527 format.)

9.6.5 Representations and warranties of other participants

9.7 Disclaimers of warranties

(New location of Section 2.3.2 in 2527 format.)

No stipulation.

(New location of Section 2.2 in 2527 format.)

9.8 Limitations of liability

(New location of Section 2.2 in 2527 format.)

9.9 Indemnities

(New location of Section 2.3.1 in 2527 format.)

No stipulation.

(New location of Section 2.1.4 in 2527 format.)

(New location of Section 2.1.3 in 2527 format.)

Page 12

(New location of Section 2.2 in 2527 format.)

9.10 Term and termination

9.10.1 Term

9.10.2 Termination

9.10.3 Effect of termination and survival

(New location of Section 2.4.2 in 2527 format.)

The E-Authentication PMO shall facilitate the resolution between entities when conflicts arise as a result of the use of certificates issued under this policy.

9.11 Individual notices and communications with particpants

(New location of Section 2.4.2 in 2527 format.)

The E-Authentication PMO shall facilitate the resolution between entities when conflicts arise as a result of the use of certificates issued under this policy.

9.12 Amendments

(New location of Section 8.1 in 2527 format.)

The PA shall review this CP at least once every year. Corrections, updates, or suggested changes to this CP shall be publicly available. Suggested changes to this CP shall be communicated to the contact in Section 1.4; such communication must include a description of the change, a change justification, and contact information for the person requesting the change.

9.12.1 Procedure for amendment

9.12.2 Notification mechanism and period

9.12.3 Circumstances under which OID must be changed

9.13 Dispute resolution provisions

9.14 Governing law

(New location of Section 2.4.1 in 2527 format.)

Should it be determined that one section of this CP is incorrect or invalid, the other sections of this CP shall remain in effect until the CP is updated. The process for updating this CP is described in Section 8.1

9.15 Compliance with applicable law

(New location of Section 2.4.1 in 2527 format.)

9.16 Miscellaneous provisions

(New location of Section 2.4 in 2527 format.)

The terms and provisions of this Certificate Policy shall be interpreted under and governed by applicable Federal law.

(Old location of Section 2.4.1 in 2527 format) (Old location of Section 2.4.2 in 2527 format)

9.16.1 Entire agreement

(New location of Section 2.4.2 in 2527 format.)

The E-Authentication PMO shall facilitate the resolution between entities when conflicts arise as a result of the use of certificates issued under this policy.

9.16.2 Assignment

9.16.3 Severability

(New location of Section 2.4.2 in 2527 format.)

The E-Authentication PMO shall facilitate the resolution between entities when conflicts arise as a result of the use of certificates issued under this policy.