10.8.52 IRS Public Key Infrastructure (PKI) X.509 Certificate Policy

Manual Transmittal

August 18, 2017

Purpose

(1) This transmits revised Internal Revenue Manual (IRM) 10.8.52, Information Technology (IT) Security, IRS Public Key Infrastructure (PKI) X.509 Certificate Policy.

Material Changes

(1) The entire IRM has been restructured to align with Treasury PKI X.509 Certificate Policy. The following sections and exhibits are new to this revision of the IRM:

  1. IRM 10.8.52.2.3.3 Authentication of Human Subscribers for Role Based Certificates

  2. Exhibit 10.8.52-1 PIV Interoperable Smart Card Requirements

  3. Exhibit 10.8.52-2 PIV I Card Management System Requirements

  4. Exhibit 10.8.52-3 Summary of Available Policies (Certificate Types)

(2) More than 50 sections contain revised or additional requirements. For a detailed listing of the changes please see Exhibit 10.8.52-6

(3) Editorial changes (including grammar, spelling, and minor clarification) were made throughout the IRM.

Effect on Other Documents

IRM 10.8.52 dated February 9, 2015 is superseded. This IRM supersedes all prior versions of IRM 10.8.52. This IRM supplements IRM 10.8.1, Information Technology (IT) Security Policy and Guidance; IRM 10.8.2, Information Technology Security Roles and Responsibilities; and IRM 10.8.3, Information Technology Audit Logging Security Standards.
Also, this IRM augments IT security controls as defined in IRM 10.8.10, Linux and Unix Security Policy, IRM 10.8.20 , Information Technology (IT) Security, Windows Security Policy, and IRM 10.8.22, Information Technology (IT) Security, Web Server Security Policy.

Audience

IRM 10.8.52 shall be distributed to all personnel who install, use or operate PKI services, and who store, process, or transmit IRS data. This policy applies to all employees, contractors, and vendors of the IRS.

Effective Date

(08-18-2017)

S. Gina Garza
Chief Information Officer

Program Scope and Objectives

  1. IRM 10.8.52, Information Technology (IT) Security, PKI Security Policy, lays the foundation to implement and manage security for the internal and external Internal Revenue Service (IRS) Public Key Infrastructure (PKI) implementation.

  2. Audience: The provisions in this manual apply to:

    1. All offices and business, operating, and functional units within the IRS, and are to be applied when IT is used to accomplish the IRS mission.

    2. Individuals and organizations having contractual arrangements with the IRS, including employees, contractors, vendors, and outsourcing providers, which use or operate information systems that store, process, or transmit IRS Information or connect to an IRS network or system.

    3. All IRS information and information systems. For information systems that store, process, or transmit classified information, refer to IRM 10.9.1, National Security Information, for additional procedures for protecting classified information.

  3. Policy Owner: Gina Garza, Chief Information Officer

  4. Program Owner: Olga Plotkin, Cybersecurity Architecture and Implementation

Scope

  1. This IRM covers all personnel who install, use, or operate PKI, and store, process, or transmit IRS data.

  2. The provisions in this manual apply to:

    1. All offices and business, operating, and functional units within the IRS, and are to be applied when IT is used to accomplish the IRS mission.

    2. Individuals and organizations having contractual arrangements with the IRS, including employees, contractors, vendors, and outsourcing providers, which use or operate information systems that store, process, or transmit IRS Information or connect to an IRS network or system.

    3. All IRS information and information systems. For information systems that store, process, or transmit classified information, refer to IRM 10.9.1, National Security Information, for additional procedures for protecting classified information.

  3. IRS PKI Subscribers include but are not limited to the following categories of entities that may wish to conduct official Agency business:

    1. IRS personnel: Direct Hire, Part-time/Intermittent/Temporary (PIT) employees, contractors, commercial vendors, and agents.

    2. Federal Government departments and agency personnel, and their contractors and agents.

    3. Non Person Entities (NPE) such as: workstations, guards and firewalls, routers, trusted servers, applications and other infrastructure components. These components shall be under the cognizance of humans (Sponsor), who accept the certificate and are responsible for the correct protection and use of the associated private key.

    • Note:

      For the automated certificate issuance and life-cycle management (ACM) process, the NPE Sponsor is not responsible for protecting the NPE’s private key or ensuring proper use of each sponsored NPE’s key and certificate.

  4. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  5. In the event there is a discrepancy between this policy and IRM 10.8.1, IRM 10.8.1 has precedence, unless the security controls/requirements in this policy are more restrictive, or unless otherwise noted.

Objectives

  1. This IRM establishes the minimum baseline security policy and requirements for all IRS IT assets in order to:

    1. Protect the critical infrastructure and assets of the IRS against attacks that exploit IRS assets.

    2. Prevent unauthorized access to IRS assets.

    3. Enable IRS IT computing environments that meet the security requirements of this policy and support the business needs of the organization.

  2. Specifically, the PKI program in the IRS:

    1. Provides a method for securing transmission of information across Agency Automated Information System (AIS) assets.

    2. Supports the verification of an individual’s identity for physical and logical access control.

    3. Establishes a secure electronic environment, at the Sensitive But Unclassified (SBU) level, that fully complements hard-copy documentation standards currently in use.

    4. Consists of products and services that provide and manage X.509 certificates for public key cryptography. Public key cryptography is an information technology security service that can provide identity authentication, data integrity, non-repudiation, and confidentiality (i.e., privacy) to electronic transactions.

  3. It is acceptable to configure settings to be more restrictive than those defined in this IRM.

  4. To configure less restrictive controls requires a risk-based decision (RBD). See the Risk Acceptance and Risk-Based Decisions section within this IRM for additional guidance.

Background

  1. This Internal Revenue Manual (IRM) establishes the minimum security controls for internal and external Internal Revenue Service (IRS) Public Key Infrastructure (PKI) implementation used to protect federal information systems and data.

    1. Policies in this IRM are based on the most recent Treasury guidance in effect at the time of IRM publication.

  2. FIPS 200 mandates the use of National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 as an initial set of baseline security controls for the creation of agency IT security policy.

  3. IRM 10.8.52 is part of the Security, Privacy and Assurance policy family, IRM Part 10 series for IRS Information Technology Cybersecurity.

Authority

  1. IRM 10.8.1, Information Technology (IT) Security, Policy and Guidance, establishes the IT security program and the policy framework for the IRS.

  2. IRS shall operate in accordance with Department of the Treasury (Treasury) Public Key Infrastructure (PKI) X.509 Certificate Policy. For additional information regarding Department of the Treasury PKI policy and the role of the Treasury PMA, see:
    http://pki.treas.gov/

    1. Any exception to Department of the Treasury PKI policy shall be approved by the Treasury PMA.

    2. See also the Roles and Responsibilities section within this IRM for additional guidance.

Risk Acceptance and Risk Based Decisions

  1. Any exception to this policy requires that the Authorizing Official (AO) make a Risk-Based Decision.

  2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
    ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  3. Refer to IRM 10.8.1 for additional guidance about risk acceptance.

Roles and Responsibilities

  1. IRM 10.8.2, Information Technology (IT) Security, IT Security Roles and Responsibilities, defines IRS-wide roles and responsibilities related to IRS information and computer security, and is the authoritative source for such information.

  2. The supplemental roles provided below are specific to the implementation of the IRS’s PKI Certificate Policy.

Treasury Policy Management Authority (PMA)

  1. The Treasury Policy Management Authority (PMA) resides in the Office of the Chief Information Officer (OCIO) for Treasury. The Treasury PMA provides management authority over Treasury’s PKI and Shared Service Programs (SSP). As such, the Treasury PMA ensures the conformity to central Department policy for PKI implementation and operation to ensure installation of one PKI solution throughout Treasury. The Treasury PMA is responsible for:

    1. The Treasury PKI Certificate Policy (CP).

    2. Review, approval, and compliance review of all Treasury Certification Practices Statement (CPS) issued and maintained in support of the Treasury Certification Authority (TCA).

    3. Approval of any subordinate or other certificate authorities created in support of other Agencies and Bureaus to support digital technologies for authentication, signing, encryption, access, or authorizations.

    4. Oversight compliance management of the TCA and all Treasury CAs assigned by the Treasury Root Certification Authority (TRCA).

    5. Internal Auditing and compliance oversight of TCA operations.

    6. Determinations regarding CP and CPS compliance and assurance level with the Treasury CP.

    7. Review and approval of Treasury or other Entities CPs and CPS pertaining to CAs being considered for cross certification with the TRCA.

  2. In the event the Treasury PMA makes the determination that other, non-Department of the Treasury Certificate Policies offer appropriately equivalent levels of assurance to the Treasury Certificate Policies, the TCA may respond to such decisions by methods including, but not limited to the following:

    1. Issuing cross certificates to other PKIs asserting other policies.

    2. Including certificates issued by other PKIs and asserting other Certificate Policies, in Department of the Treasury Certificate Status Authorities (CSAs).

    3. Recommending CAs asserting other Certificate Policies for inclusion in Department of the Treasury application trust lists.

  3. The PMA shall make information regarding such equivalency determinations widely available to Department of the Treasury Subscribers and Relying Parties.

  4. The PMA guidance in this section comes directly from Department of the Treasury PKI policy.

IRS PKI Program Management Office (PMO)

  1. The IRS PKI Program Management Office (PMO) shall be established within the IRS Information Technology (IT) organization, ACIO Cybersecurity.

  2. The PMO shall enforce Department of the Treasury and IRS PKI policy. The PMO shall represent the interests of the PKI Program and the IRS in all internal and external matters relative to PKI technology. The PMO shall:

    1. Provide oversight and coordination of the IRS CA on behalf of the IRS.

    2. Create, publish, and maintain all CPS pertaining to the IRS PKI.

    3. Participate in audit management activities (e.g., Government Accountability Office (GAO) and Treasury Inspector General Tax Administration (TIGTA) in accordance with the IRS IT organization Strategy and Planning, Risk Management organizational processes and procedures for audit management, reporting, and oversight.

    4. Provide Bureau Registration Authority (RA) and Local Registration Authority (LRA) training.

    5. Provide Bureau RA and LRA guidance.

  3. The PMO shall establish SOPs for the management and secure operation of the PKI program and assets per IRM 10.8.1.

  4. For additional information regarding the PKI PMO and SOPs, please email the Cybersecurity Front Door at *IT Cybersecurity Front Door.
    or contact the PMO through the *IT PKI Management Solutions mailbox.

PKI Operations Program Manager

  1. The position of PKI Operations Program Manager shall be established within the IRS IT organization, Enterprise Operations (EOps).

  2. The PKI Operations Program Manager shall be responsible for the operation, control and management of all IRS subordinate CAs. In addition, the PKI Operations Program Manager shall:

    1. Establish the operational requirements for the IRS subordinate CAs in the CPS.

    2. Make recommendations to the PMO and PMA regarding corrective actions or other measures that might be appropriate for the IRS subordinate CAs.

    3. Provide acquisition support to maintain PKI technology.

    4. Provide costing support and seek funding as required to maintain technologically current hardware and software levels for IRS PKI.

    5. Stay abreast of new PKI technology and requirements (i.e., Homeland Security Presidential Directive 12 (HSPD-12)) and participate in technology summits and meetings dealing with IRS PKI, including interdependencies with Department of the Treasury PKI.

    6. Work with IRS IT organization communications to provide customer advisories in advance of any downtime or potential impact. Refer to IRM 10.8.1 for additional information regarding incident reporting requirements if applicable.

    7. Coordinate PKI activities with the IRS IT organization, Enterprise Services and ensure that the IRS PKI complies with the IRS Enterprise Architecture.

    8. Select the PKI operational staff to operate and maintain the IRS PKI CAs on behalf of the IRS, in coordination with the PKI PMO.

  3. The PKI Operations Program Manager can be contacted through the *PKI Program Office mailbox.

Treasury PKI Operational Authority

  1. The Treasury CIO has designated the Bureau of Public Debt, as the Treasury PKI Operational Authority (PKI OA).

  2. The PKI OA is responsible for the operation, and control of the TRCA and the operation, control and management of all subordinate CAs.

  3. The PKI OA is responsible for the following:

    1. Establishing the operational requirements for the subordinate CAs in the CPS.

    2. Making recommendations to the PMO and PMA regarding corrective actions or other measures that might be appropriate for the TCA.

  4. The PKI OA established the PKI Program Team.

    1. The PKI Program Team is the organization that operates and maintains the Treasury PKI CAs on behalf of the Treasury, subject to the direction of the PMA.

    Note:

    The PKI OA guidance stated above comes directly from the Treasury PKI policy.

PKI Operational Staff

  1. The PKI operational staff shall be established within the IRS IT organization, Enterprise Operations (EOps). The PKI operational staff shall administer the IRS’ PKI from an operation perspective and shall:

    1. Administer PKI and IRS PKI CAs.

    2. Publish certificates.

    3. Perform issuance and revocation of certificates to subordinate CAs, and to Subscribers from those CAs.

    4. Manage certificate repositories and certificate and authority revocation lists.

    5. Ensure that all aspects of CA services, security/access controls, operations and infrastructure related to certificates issued under the CP are performed in accordance with the requirements, representations, and warranties of the CP, the appropriate CPS, IRS policy, and Department of the Treasury policy.

    6. Manage technical operational issues, including:

      • Set up and administer subordinate CAs

      • Implement the PKI and components

      • Coordinate installation

      • Administer the IRS’ PKI from a key management perspective, including rekey of CA signing material in cooperation with the PMO

      • Security Assessment and Authorization activities, in accordance with IRM 10.8.1

    7. Shall support the PMO/PMA with the creation and revisionCertification Practices Statements, including evaluation of changes at the requested of the PMA or PMO, and recommendation for approval/disapproval to the PMA, to maintain the level of assurance and operational practicality.

    8. Establish operational guidance and procedures for subordinate CAs.

    9. Perform Certification and Accreditation activities, including:

      • Preparation of system security plans

      • Conduct annual system security self-assessment reviews and prepare Plans of Action and Milestones (POA&M)

    10. Perform Backup and Contingency planning, including:

      • System backup

      • Key recovery

      • Key escrow

      • Disaster recovery planning

      • Perform contingency planning to ensure continuity of operations

    11. Participate in the Federal PKI Policy Authority Share Service Program (SSP) working group to ensure compliance to the Federal model.

    12. Conduct liaison with other government agencies concerning SSP PKI matters.

    13. Act as a focal point for IRS participation in the Federal PKI Policy Authority SSP.

Registration Authority/Local Registration Authority

  1. The IRS Registration Authority (RA) and Local Registration Authority (LRA) are entities recognized as authorized to collect and verify users’ identity and information that is to be entered into the Subscriber’s public key certificates. The key difference between RAs and LRAs is the nature and degree of their respective access to the IRS and treasury PKI CAs.

  2. RA functions as the Officer trusted role of the Treasury PKI (TPKI) and IRS PKI CA.

  3. The EOps Program Manager(PM) appoints all RA and LRA for TPKI and IRS CA from members of the PKI operational staff, or other IRS personnel as necessary.

  4. The EOps PM shall maintain a current active list of all RAs and provide that list to the PMO when requested.

  5. Both Certification Authorities and Registration Authorities are termed “Certificate Management Authorities (CMA).” This policy uses the term “CMA” when a function may be assigned to either a CA or an RA, or when a requirement applies to both CAs and RAs. The term “Registration Authority” includes entities such as Local Registration Authorities (a.k.a. Trusted), unless otherwise specified.

  6. The division of Subscriber registration responsibilities between the CA and RA may vary among implementations of this CP, as outlined in the appropriate CPS. All CMAs shall protect personal information from unauthorized disclosure as mandated by the Privacy Act of 1974, as amended.

IRS Subscribers

  1. A Subscriber is the entity (the user to whom, or device to which, a certificate is issued) whose Distinguished Name (DN) appears as the subject in a certificate, and who asserts that they use the key and certificate in accordance with this policy. Although CAs can be considered as PKI subjects, the term “Subscriber” as used in this document refers only to entities who request certificates for uses other than signing and issuing certificates or certificate status information.

  2. PKI Subscribers include but are not limited to the following categories of entities that may wish to conduct official Department business:

    1. IRS personnel: Direct Hire, Part-time/Intermittent/Temporary (PIT) employees, contractors, commercial vendors, and agents.

    2. Federal Government departments and agency personnel, and their contractors and agents.

    3. Workstations, guards and firewalls, routers, trusted servers (e.g., database, domain controller, File Transfer Protocol (FTP), and World Wide Web (WWW)), and other infrastructure components. These components shall be under the cognizance of humans, who accept the certificate and are responsible for the correct protection and use of the associated private key.

  3. A PKI Sponsor fills the role of a Subscriber for groups, organizations, disabled personnel, and non-human system components named as public key certificate subjects.

    1. The PKI Sponsor works with the CMAs to register the above elements.

    2. The PKI Sponsor is responsible for meeting the obligations of Subscribers as defined throughout this document.

  4. TRCA Subscribers include only PMA, PMO or PKI Program Team personnel and, when determined by the PMA, PKI network or hardware devices.

  5. The Treasury may issue certificates to Subscribers other than employees of the U.S. Government, such as commercial vendors and agents, at the convenience of the Government and without fee, when those Subscribers have a bona fide need to possess a certificate issued by a Treasury CAs.

  6. The Card Management System (CMS) shall not be issued any certificates that express the PIV-I Hardware or PIV-I Card Authentication policy Object Identifier (OID). The CMS is responsible for managing smart card token content.

Relying Parties

  1. A Relying Party uses a Subscriber’s certificate to verify or establish the identity and status of an individual, the integrity of a digitally signed message, the identity of the creator of a message, and confidential communications with the Subscriber.

  2. The Relying Party relies on the validity of the binding between the Subscriber’s name and public key.

    1. A Relying Party may use information in the certificate (such as CP Identifiers) to determine the suitability of the certificate for a particular use.

  3. The Relying Party shall be responsible for deciding whether or how to check the validity of the certificate by checking the appropriate certificate status information.

    1. For a Certificate Policy, the relying party may be any Entity that wishes to validate the binding of a public key to the name of a federal employee, contractor, other affiliated personnel or device.

  4. This CP makes no assumptions or limitations regarding the identity of Relying Parties. While Relying Parties may be Subscribers, Relying Parties are not required to have an established relationship with the IRS PKI CA, Treasury PKI CA, Federal Bridge Certification Authority (FBCA) or another Entity CA.

Other Participants

  1. All IRS CAs operating under this policy require the services of other security and application authorities, such as compliance auditors and attribute authorities.

    1. Each IRS CA shall identify, in its CPS, the parties responsible for providing such services and the mechanisms used to support these services.

Treasury Root certification authority (TRCA)

  1. The Treasury Root Certification Authority TRCA (a collection of hardware, software, and operating personnel) is established by the Treasury Program Management Office (PMO) to certify Treasury and IRS subordinate CAs that, in turn, create, sign, and issue public key certificates to subscribers within IRS and other related PKI communities.

  2. The Treasury’s PKI operates in a hierarchical fashion, utilizing a TRCA and subordinate CAs. The TRCA serve as the trust anchors for all certificates issued under this policy. The TRCA also acts as the Principal CA (PCA) for Treasury to cross certify directly with the Federal PKI (e.g., through the exchange of cross certificates).

  3. The Principal CA issues either end entity certificates, or CA certificates to other Entity or external party CAs, or both. The PCA shall cross certify with the Federal Common Policy Certification Authority (FCPCA), and other root level CAs from other trust domains as appropriate. The PCA shall also certify CA’s within Treasury that want to be part of the subordination hierarchy (as opposed to cross certification).

  4. This policy permits an off-line TRCA. The TRCA is physically isolated from all networks. The TRCA is responsible for issuing and managing certificates; and ensuring that the performance of all aspects of CA services, operations, and infrastructure related to certificates issued under the Treasury’s CP are in accordance with the requirements, representations, and warranties of the Treasury’s CP. This includes the following:

    1. The TRCA certifies subordinate CAs, which will assert one or more assurance levels defined in the Treasury’s CP, and outlined in the appropriate CPS.

    2. The TRCA shall also comply with the requirements set forth in applicable Memorandum of Agreement (MOA), Memorandum of Understanding (MOU), and contractual agreements with cross-certified CAs and/or other entities.

Subordinate Certification Authorities

  1. Treasury’s Subordinate Certification Authorities are responsible for all aspects of the issuance and management of certificates to users and devices, including control over the enrollment process, the identification and authentication process, the certificate manufacturing process, publication of certificates, revocation of certificates, and rekey.

  2. A CA, which issues certificates that assert the policies defined within the Treasury’s CP, shall conform to the stipulations of the Treasury’s CP and this document, including the following:

    1. Providing to the appropriate authorities a CPS, as well as any subsequent changes, for conformance assessment.

    2. Maintaining its operations in conformance to the stipulations of the approved CPS.

    3. Ensuring that registration information is accepted only from Registration Authorities (RAs)/ Local Registration Authorities (LRAs) who understand and are obligated to comply with this policy, and operating under an approved CPS.

    4. Including only valid and appropriate information in the certificate, and to maintaining evidence that due diligence was exercised in validating the information contained in the certificate.

    5. Ensuring that all Subscribers (government and non-government) are informed of their obligations, including the consequences of not complying with those obligations, and revoking the certificates of Subscribers found to have acted in a manner counter to those obligations.

    6. Operating or obtaining the services of an online repository that satisfies the obligations defined within the Treasury’s CP and this document, and informing the repository service provider of those obligations if applicable.

Certificate Status Servers

  1. The IRS CA may optionally include an authority that provides status information about certificates on behalf of the IRS PKI CAs through online transactions. Examples include Online Certificate Status Protocol (OCSP) responders, termed Certificate Status Servers (CSS).

  2. Where certificates identify CSS as an authoritative source for revocation information, the operations of that authority shall be within the scope of this policy. This policy does not cover OCSP servers that are locally trusted.

    1. A CSS shall assert all the policy Object Identifiers (OIDs) for which it is authoritative.

Repositories

  1. The Department of Treasury (Treasury) PKI CA infrastructure shall serve as the primary repository of information for Subscribers and Relying Parties.

    1. For all Treasury PKI CAs, this repository is the Treasury directory infrastructure.

    2. The PKI Program Team web site (http://pki.treas.gov) serves as the primary repository to publish public information.

    3. Network directories and all other repositories used to disseminate relevant information will:

      • Maintain availability necessary to distribute current certificate information in a manner consistent with the posting and retrieval stipulations defined within the Treasury’s CP and this policy

      • Implement access controls on all CA repositories to provide sufficient protection as described within the Treasury’s CP and this policy

  2. The PKI Program Team may use a variety of mechanisms for posting information into a repository as required by the Treasury’s CP. These mechanisms at a minimum include:

    1. A Directory Server System that is also accessible through the Lightweight Directory Access Protocol (LDAP)

    2. Availability of the information as required by the certificate information posting and retrieval stipulations of this CP

    3. Access control mechanisms when needed to protect repository information as described in later sections

Trusted Roles

  1. 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 shall be extraordinarily responsible and above reproach or the integrity of the CA is weakened. The functions performed in these roles form the basis of trust in the entire PKI.

    1. There are two approaches to increase the likelihood of successfully carrying out these roles:

      • The first approach is to ensure that the person filling the role is trustworthy and properly trained

      • The second is to distribute the functions of the role among several people, so that any malicious activity requires collusion

  2. The requirements of this policy are defined in terms of four roles. (Note: the information derives from the Certificate Issuing and Management Components (CIMC) Protection Profile.)

    1. Each CA shall maintain lists, including names, organizations, contact information, and copies of appointment memoranda of those who act in these trusted roles, and shall make them available during compliance audits.

    2. The CA will make this information a part of the permanent records of the CA. However, the CA shall not maintain personnel or investigative records requiring protection under the Privacy Act.

      • Administrator – authorized to install, configure, and maintain the CA; establish and maintain Subscriber accounts; configure profiles and audit parameters; and generate component keys

      • Officer – authorized to request or approve certificates or certificate revocations

      • Auditor – authorized to maintain audit logs

      • Operator – authorized to perform system backup and recovery

  3. The following subsections provide a detailed description of the responsibilities for each .

Administrator

  1. The Administrator role is responsible for the following:

    1. Installation, configuration, and maintenance of the CA

    2. Establishing and maintaining CA system accounts

    3. Configuring certificate profiles or templates and audit parameters

    4. Generating and backing up CA keys

  2. Administrators do not issue certificates to Subscribers

Officer

  1. The Officer (a.k.a. Security Officer, Registration Authority) role is responsible for issuing certificates, that is:

    1. Registering new Subscribers and securely requesting the issuance of certificates

    2. Verifying the identity of Subscribers, validity of documentation, and accuracy of information included in certificates

    3. Approving and executing the issuance of certificates

    4. Requesting, approving and executing the revocation of certificates

    5. Receiving, controlling, and distributing Subscriber certificates on FIPS 140 Level 2 compliant hardware tokens (cryptographic modules containing the CA private key), as specified in this CP and the applicable CPS

  2. The Officer also performs the administration and operation of the RA workstation.

Auditor

  1. The Auditor role is responsible for the following:

    1. Reviewing, maintaining, and archiving audit logs

    2. Performing or overseeing internal compliance audits to ensure that the CA is operating in accordance with its CPS

Operator

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

IRS PKI Infrastructure

  1. The IRS shall use a dual PKI structure: external and internal. The IRS external certification services shall be provided by the Treasury PKI, and the internal certification services shall be provided by the internal IRS PKI.

External PKI Infrastructure

  1. Externally, the IRS is subordinate to the TRCA.

    1. Any additional CAs within Treasury are subordinated to TRCA.

    2. External Treasury CAs operate under approved Treasury CP and CPS.

    3. TRCA is cross-certified with the FBCA.

    4. The CPS of CAs subordinate to the TRCA shall comply with the Treasury CP.

  2. Externally, the Treasury CAs supports the IRS by providing two certificate types (confidentiality and signature), and six (6) levels of assurance: Level 1, Level 2, Level 3, Level 4, Level 5, and Level 6

    1. Certificate type and assurance levels shall correspond to the Federal Bridge CA assurance levels of rudimentary (Level 1), basic (Level 2), medium (Level 3), Personal Identity Verification Interoperability (PIV-I) card authentication (Level 4), medium hardware (Level 5), and high (Level 6l) and associated X.509 object identifiers defined by the Federal Bridge CA.

    2. The reliance IRS chooses to place on any given level of certificate assurance shall be based on the amount and type of inherent risk of an activity, the consequence of failure, and the use of risk mitigation controls.

Internal PKI Infrastructure

  1. The IRS Internal PKI is a Subordinate CA to TRCA.

    1. The two communities, Treasury and IRS, shall interact as described in the Department of the Treasury Internal Non Person Entity (NPE) X.509 Certificate Policy. The basis of trust between the two comes from the subordination of the IRS CAs to the TRCA.

    2. All internal CAs shall operate under an approved CP and CPS consistent with the Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (PKIX) RFC 3647, Certificate Policy and Certification Practice Statement Framework.

  2. Internally, the EOPs PKI PMO, shall ensure the IRS CA shall operate at a Basic (Level 2) level of assurance and issue certificates for Basic levels of assurance.

  3. Internal IRS PKI shall only be used for Non Personal Entity (NPE) certificates.

  4. For the Internal IRS PKI, NPE certificates shall implement:

    1. The use of a manual certificate issuance and life-cycle management (MCM) process for certificates.

    2. The use of an automated certificate issuance and life-cycle management (ACM) process.

  5. The IRS shall use a dual PKI structure: external and internal. The IRS external certification services shall be provided by the Treasury PKI, and the internal certification services shall be provided by the internal IRS PKI.

Certificate Usage

  1. Certificates shall not have an infinite lifetime and shall be subject to expiration.(IRS-defined)

    1. The lifetime shall not be set longer than the issuer certificate.

  2. The IRS shall implement X.509 v3 certificates and use CA components that support version one of the NIST Minimum Interoperability Specifications for PKI Components as a basis for interoperation between PKI components and various vendors.(IRS-defined)

  3. Personal Identity Verification (PIV) certificates shall be used for personal S/MIME email encryption and signature. For additional personal certificate needs, certificates shall be obtained from the Treasury Operational Certification Authority (TOCA).(IRS-defined)

Appropriate Certificate Usage

  1. The sensitivity of the information processed or protected using certificates issued by the TCA may vary significantly. Relying Parties should evaluate the environment and the associated threats and vulnerabilities and determine the level of risk they are willing to accept based on the sensitivity or significance of the information. Each Relying Party makes this evaluation for its application outside the control of this CP. To provide sufficient granularity, this CP specifies security requirements at six (6) increasing, qualitative levels of assurance: Rudimentary, Basic, Medium, PIV-I card authentication, Medium Hardware, and High.

  2. All IRS implementations to use PKI technology to secure data are subject to the requirements within the Treasury’s CP and this policy. The TCA is intended to support applications involving unclassified information, which can include SBU data protected pursuant to Federal statutes and regulations. Other agencies that exchange information electronically with Department assets, including those requiring the security of Public Key technology, are subject to the same requirements. Each CA asserting this policy must state this requirement in the CPS and inform Subscribers of the limitation.

  3. The level of assurance associated with a public key certificate describes the procedures and controls involved in validating a Subscriber’s identity and binding that identity to a public key. It is the responsibility of the Relying Party to assess that level of assurance and determine if it meets their security requirements for some particular use. The level of assurance depends on the proper generation and management of the certificate and associated private keys, in accordance with the stipulations of this policy. Personnel, physical, procedural, and technical security controls contribute to the assurance level of the certificates issued by a certificate management authority or system.

  4. The following table provides a brief description of the appropriate uses for certificates at each level of assurance defined in this CP. These descriptions are guidance and are not binding.

    Assurance Level Appropriate Certificate Uses
    Rudimentary This level provides the lowest degree of assurance concerning identity of the individual. One of the primary functions of this level is to provide data integrity to the digitally signed information. This level is relevant to environments in which the risk of malicious activity is considered low. It is not suitable for transactions requiring authentication, and is generally insufficient for transactions requiring confidentiality, but may be used for the latter where certificates having higher levels of assurance are unavailable.
    Basic This level provides a basic level of assurance relevant to environments where there are risks and consequences of data compromise, but which are not considered to be of major significance. This may include access to private information where the likelihood of malicious access is not high. This security level assumes that subscribers are not likely to be malicious.
    Medium This level is relevant to environments where risks and consequences of data compromise are moderate. This may include transactions having substantial monetary value or risk of fraud, or involving access to private information where the likelihood of malicious access is substantial.
    PIV-I Card Authentication This level is used to uniquely identify a PIV-I card – not the cardholder – for the purposes granting the cardholder physical access to high-volume, low-risk areas or in combination with other authentication mechanisms for access to high-risk areas.
    Medium Hardware This level is relevant to environments where threats to data are high or the consequences of the failure of security services are high. This may include very high value transactions or high levels of fraud risk.
    High This level is reserved for cross certification with government entities and is appropriate for those environments where the threats to data are high, or the consequences of the failure of security services are high. This may include very high value transactions or high levels of fraud risk.
  5. General usage for certificates covered by this policy includes:

    1. Digital signature services (authentication and data integrity)

    2. Protection (confidentiality)

    3. Technical non-repudiation

    4. Authentication of identity and status with Treasury for access control to a Federal facility or information systems across the Federal Government.

Prohibited Certificate Usage

  1. Subscribers shall not use PKI certificates to conceal an unauthorized act as specified in Federal law or Department of the Treasury regulations. Examples of such actions include, but are not limited to, the following:

    1. Use of PKI certificates, especially in conjunction with an IRS-issued PIV card, to gain unauthorized access to a Federal facility, information system, or electronic data (e.g., Privacy information), or to enable others to gain such access.

    2. Use of PKI certificates to facilitate and/or hide an unauthorized action, including but not limited to::

      • Transfer information to an unauthorized individual

      • Generate income for oneself or for an organization

      • View sexually explicit material, gamble, or for the purposes of conducting Unlawful or malicious activities

      • Negatively affect the integrity, accessibility, and/or confidentiality of Treasury’s cyber infrastructure

  2. The IRS specifically prohibits such uses of PKI regardless of whether the use is during or outside normal work hours, whether use occurs on or off U.S. Government premises, or whether the use occurs within or outside the United States.

  3. Each CA asserting this policy shall state the above requirement in the CPS and inform Subscribers of these usage limitations. All IRS offices and posts that use PKI technology are subject to the requirements of the Treasury’s CP and this policy.

  4. The Treasury CP specifies requirements imposed upon issuing CA, subject CAs, RAs, subscribers, or other participants with respect to the life-cycle of a certificate.

Identification and Authentication

  1. The Treasury PKI CP defines “Identification and Authentication” requirements used to authenticate the identity and/or other attributes of an end-user certificate to a CA or RA within External PKI.

  2. The supplemental requirements provided in a CA’s CP regarding Identification and Authentication requirements are specific to the implementation of the internal IRS PKI, and shall be combined with the Treasury CP in order to adequately address this security control.

  3. Refer to IRM 10.8.1 for additional identification and authentication requirements.

Naming

  1. The following sections detail the requirements for certificate naming.

Types of Names
  1. All CAs shall be able to generate and sign certificates that contain an X.501 DN or if applicable a Domain Component (DC) identifier.

    1. See RFC 4514, Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names for additional guidance on the use of DN in security applications.

  2. The DN assigned to IRS employees shall be in the following form:

    CN= userid, OU=bureau, OU=Department of the Treasury, OU=structural container, O=U.S. Government, C=US

    :

  3. The organizational unit bureau and Department of the Treasury are used to specify the federal entity that employs the subscriber. At least one of these organizational units must appear in the DN.

    1. The additional organizational unit structural container is permitted to support local directory requirements, such as differentiation between human subscribers and devices. This organizational unit may not be employed to further differentiate between subcomponents within a bureau.

  4. The userID is unique across the Treasury directory. It is a non-identifying ID and can be composed in the following form: the first two letters of the subscribers surname and a four digit number that is assigned sequentially as userID are assigned. The directory can be queried using a subscriber name (as long as access controls are not in place to protect it) or userID to get the subscriber’s certificate.

  5. For non-human Subscribers, a PKI Sponsor shall provide a uniquely identifying name for the entity to be issued a certificate. This information may be a Uniform Resource Locator (URL), Internet Protocol (IP) address, hostname, application, or process name, or other value that can reasonably identify this entity. The name of the PKI sponsor does not need to appear in the certificate, but may be kept as an attribute in the directory.

    1. An example of a non-human subject would be:
      CN =www.publicdebt.ustreas.gov, OU=Bureau of Public Debt, OU=Department of the Treasury, O=U.S. Government, C=US

  6. DNs employed externally to the IRS shall not include Sensitive But Unclassified (SBU) information.

    1. Refer to IRM 10.8.1 for additional guidance on protecting SBU information.

  7. The CA shall generate and sign certificates that contain an X.501 DN for certificates issued under policies associated with Medium (Software), Medium (Hardware), High, and for devices.

    1. These distinguished names may be in either one of two forms: a geo-political name space or an Internet domain component (dc) name space.

    2. Where Subscriber certificate name forms must assert the Federal Common Policy Framework (FCPF) (e.g., for PIV), Subscriber DNs shall also meet that policy.

  8. When organizational units department and agency appear and are used to specify the federal entity that employs the subscriber, at least one of these organizational units shall appear in the DN.

    1. The additional organizational unit structural container is permitted to support local directory requirements, such as differentiation between human subscribers and devices. This organizational unit may not be employed to further differentiate between subcomponents within an agency.

  9. All geo-political X.501 distinguished names assigned to Federal employees are to be in one of the following directory information trees:

    C=US, o=U.S. Government, [ou=department], [ou=agency], [ou= structural_container]

    C=US, [o=department], [ou=agency], [ou= structural_container]

    1. All certificates issued after May 2006 shall assign names that conform to the remainder of this section.:]

  10. When organizational units department and agency appear and are used to specify the CA Sponsor that employs the subscriber, at least one organizational unit shall appear in the DN.

    1. The distinguished name of the Federal employee subscriber shall be structured in one of the three following forms:

      1.C=US, o=U.S. Government, [ou=department], [ou=agency], [ou= structural_container], cn=nickname lastname

      2.C=US, o=U.S. Government, [ou=department], [ou=agency], [ou= structural_container], cn=firstname initial. lastname

      3.C=US, o=U.S. Government, [ou=department], [ou=agency], [ou= structural_container], cn=firstname middlename lastname

  11. X.501 distinguished names assigned to Federal contractors and other affiliated persons shall be within the same directory information tree.

    1. The distinguished name of the Federal contractor subscriber and any affiliate subscribers must take one of the three following forms:

      1. C=US, o=U.S. Government, [ou=department], [ou=agency], [ou= structural_container], cn=nickname lastname (affiliate)

      2. C=US, o=U.S. Government, [ou=department], [ou=agency], [ou= structural_container, cn=firstname initial. lastname (affiliate)

      3. C=US, o=U.S. Government, [ou=department, [ou=agency, [ou= structural_container, cn=firstname middlename lastname (affiliate)

  12. Distinguished names based on Internet Domain Component (DC) names shall be in one of the following directory information trees:

    • dc=gov, dc=org0, [dc=org1, [ dc=orgN

    • dc=mil, dc=org0, [dc=org1, [ dc=orgN



    ]

  13. The default Internet domain name for any CA participating component using either the [orgN.]…[org0.gov branches shall be used to determine DNs uniqueness.

    1. The first DC of the DN shall be dc=gov. At a minimum, the org0 DC must appear in the DN.

    2. The org1 to orgN DC appear, in order, when applicable and are used to specify the Treasury entity that employs the subscriber.

  14. The distinguished name of the CA Federal employee subscriber must take one of the following three forms when the CA Sponsor’s Internet domain name ends in .gov:

    1. dc=gov, dc=org0, [dc=org1], [dc=orgN], cn=nickname lastname

    2. dc=gov, dc=org0, [dc=org1], [dc=orgN], cn=firstname initial. lastname

    3. dc=gov, dc=org0, [dc=org1], [dc=orgN], cn=firstname middlename lastname

  15. The distinguished name for Federal contractors and affiliated subscribers shalluse one of the following three forms when the CA Sponsor’s Internet domain name ends in .gov:

    1. dc=gov, dc=org0, [dc=org1], [dc=orgN], cn=nickname lastname (affiliate)

    2. dc=gov, dc=org0, [dc=org1], [dc=orgN], cn=firstname initial. lastname (affiliate)

    3. dc=gov, dc=org0, [dc=org1], [dc=orgN], cn=firstname middlename lastname (affiliate)

  16. PIV-I Hardware certificates shall indicate whether or not the Subscriber is associated with an Affiliated Organization by taking one of the following forms:

    1. For certificates with an Affiliated Organization:

      cn=Subscriber's full name, ou=Affiliated Organization Name,{Base DN}

    2. For certificates with no Affiliated Organization:

      cn=Subscriber's full name, ou=Unaffiliated, ou=Entity CA’s Name,{Base DN}

  17. PIV-I Content Signing certificates shall clearly indicate the organization administering the CMS.

  18. For PIV-I Card Authentication subscriber certificates, use of the subscriber common name is prohibited.

  19. PIV-I Card Authentication certificates shall indicate whether or not the Subscriber is associated with an Affiliated Organization by taking one of the following forms:

    1. For certificates with an Affiliated Organization:

      serialNumber=UUID, ou=Affiliated Organization Name,{Base DN}

    2. For certificates with no Affiliated Organization:

      serialNumber=UUID, ou=Unaffiliated, ou=Entity CA’s Name,{Base DN}

  20. The UUID shall be encoded within the serialNumber attribute using the UUID string representation defined in Section 3 of RFC 4122 (e.g., "f81d4fae-7dec-11d0-a765-00a0c91e6bf6").

  21. The CA may supplement any of the name forms for users specified in this section by including a dnQualifier, serial number, or user id attribute.

    1. When any of these attributes are included, they may appear as part of a multi-valued relative distinguished name (RDN) with the common name or as a distinct RDN that follows the RDN containing the common name attribute.

    2. Generational qualifiers may optionally be included in common name attributes in distinguished names based on Internet domain names.

    3. For names assigned to employees, generational qualifiers may be appended to the common name.

    4. For names assigned to federal contractors and other affiliated persons, generational qualifiers may be inserted between lastname and “(affiliate)”.

    5. Sponsored devices that are the subject of certificates shall be assigned either a geo-political or an Internet DC name.

    6. Device names shall use one of the following forms:
      1. C=U.S.,o=U.S. Government
      2. [ou=department]
      3. [ou=agency]
      4. cn=device name
      5. dc=gov,dc=org0
      6. [dc=org1], [dc=orgN]
      7. [cn=devicename]
      8. dc=mil,dc=org0
      9. [dc=org1]
      10. [dc=orgN]
      11. [cn=device name]]

  22. Where device name is a descriptive name of the device, and when a device is fully described by the Internet domain name, the common name attribute is optional.

  23. CAs and CSSs distinguished names shall be either a geo-political or an Internet DC name.

    1. The CA will use the following naming convention for certificate authorities:

      C=US, o=U.S. Government, ou=Department of the Treasury, ou=Certification Authorities, cn= [CA name]

  24. A TCA participant or sponsoring entity reserves the right to issue certificates using any of the above-defined naming conventions in order to prevent duplication of Subscriber names to maintain uniqueness within the domain.

  25. The table below summarizes the naming requirements that apply to each level of assurance.

    Assurance Level Naming Requirements
    Rudimentary Non-Null Subject Name, or Null Subject Name if Subject Alternative Name is populated and marked critical
    Basic Non-Null Subject Name, and optional Subject Alternative Name if marked non-critical
    Medium (all policies) Non-Null Subject Name, and optional Subject Alternative Name if marked non-critical
    PIV Authentication Non-Null Subject Name, and optional Subject Alternative Name
    High Non-Null Subject Name, and optional Subject Alternative Name if marked non-critical
Need for Names to be Meaningful
  1. Names used within certificates shall identify the person or object to which it is assigned in a meaningful way.

    Note:

    For equipment, this may be a model name and serial number, or an application process (e.g., Organization X Mail Server).

    1. Any CA asserting this policy shall only sign certificates with subject names from within a name-space approved by the PMO and PMA.

  2. The directory information tree shall accurately reflect organizational structures.

    1. The common name shall represent the Subscriber in a way that is easily understandable for humans.

  3. The common name within the DN shall respect name space uniqueness requirements and is not to be misleading.

    Note:

    This does not preclude the use of pseudonymous certificates.

  4. User Principal Names (UPN) (when used) shall be unique and accurately reflect organizational structures.

  5. While the issuer name in CA certificates is not generally interpreted by Relying Parties, this CP requires use of meaningful names by CAs issuing under this policy.

    1. If included, the common name should describe the issuer, such as:
      cn=Treasury Operational CA-1.

  6. The subject name in CA certificates must match the issuer name in certificates issued by the subject, as required by RFC 5280.

Anonymity or Pseudonymity of Subscribers
  1. The TRCA shall not issue anonymous certificates.

    1. Subordinate CAs may issue pseudonymous certificates to support internal operations.

    2. CA certificates issued by the TRCA shall not contain anonymous or pseudonymous identities.

Rules for Interpreting Various Name Forms
  1. Rules for interpreting name forms shall use the appropriate standard.

    1. Rules for interpreting distinguished name forms are specified in X.501.

    2. Rules for interpreting email addresses are specified in [RFC 2822].

    3. Rules for interpreting the UUID name type are specified in RFC 4122.

Uniqueness of Names
  1. The Treasury and IRS CMAs shall enforce name uniqueness within the X.500 name space, which they have been authorized, and that uniqueness shall be enforced by the PMO.

    1. Name uniqueness is not violated when multiple certificates are issued to the same entity.

    2. The userID attribute is used to ensure that no two individuals are assigned the same DN, and therefore potentially the same electronic identity or credential.

  2. Each PKI CA shall unambiguously identify each object in the naming hierarchy for the certificate repository using DNs.

    1. The CAs shall ensure that a DN, once assigned, remains unique for the lifetime of the PKI, and shall not reuse that name to identify a different entity.

  3. When other name forms are used, CMAs shall allocate them, to ensure such name uniqueness across Treasury.

    1. Each PKI CA shall document the following in its CPS:

    • What name forms shall be used.

    • How the TCA will interact with the enterprise services to ensure this is accomplished.

    • How the names will be allocated within the Subscriber community to guarantee name uniqueness among current and past Subscribers (e.g., if “Joe Smith” leaves a CA’s community of Subscribers, and a new, different “Joe Smith” enters the same community of Subscribers, how will these two people be provided unique names?).

  4. The CMA shall investigate and if necessary recommend the correction for any name collisions brought to its attention.

    1. The CMA shall coordinate with and defer to the PMO where appropriate.

Recognition, Authentication, and Role of Trademarks
  1. The CMA shall investigate and if necessary recommend the correction for any trademark name collisions brought to its attention.

    1. The CMA shall coordinate with and defer to the PMO where appropriate.

    2. The CMA will communicate resolutions to all interested parties.

    3. Consistent with Federal Policy, PKI CAs will not knowingly use trademarks in names unless the subject has the rights to use that name.

Initial Identity Validation

  1. Certificate applicants shall communicate application requests for certificates to an authorized RA or LRA via a trustworthy process, but generally in person.

    1. An authorized RA, equipped with hardware and software, may communicate authorizations to issue Certificates directly to the supporting CA electronically, provided all communication is secure.

    2. An LRA, who is not equipped with Registration Authority hardware and software, shall transmit authorization requests to issue Certificates to the appropriate RA by secure means (i.e., digitally signed electronic means, via registered mail, or in person).

Method to Prove Possession of Private Key
  1. In the case where the CMA generates the key directly on the Subscriber’s token, or in a key generator that benignly transfers the key to the Subscriber’s token, then the end-entity is presumed to be in possession of the private key at the time of generation or transfer and proof of possession is not required.

    1. If the user is not in possession of the token during key generation, the CMA shall deliver the token to the Subscriber via an accountable method.

    2. The CMA shall obtain acknowledgment of receipt from the Subscriber of shipment or shall revoke any certificates issued to that Subscriber.

    3. The CMA shall deliver activation data for the private keys within the token or module to the Subscriber through a separate, secure communication unless the CMA delivers the token or module in person.

  2. When the CMA delivers keyed hardware tokens to Subscribers, they shall accomplish delivery in a way that ensures that they provide the correct tokens and activation data to the correct people.

    1. The CMA shall maintain a Subscriber token receipt validation record.

    2. When any mechanism that includes a shared secret (e.g., a password or PIN) is used, the mechanism shall ensure that the applicant and the CMA are the only recipients of this shared secret.

  3. In those cases where the Subscriber causes the system to generate keys (e.g., remote emergency renewal), the Subscriber is required to prove possession of the private key that corresponds to the public key in the certificate request to the CMA.

Authentication of Organization Identity
  1. A PKI CA may issue certificates directly in the name of an organization rather than an individual for those functions and applications performed on behalf of the organization.

    1. The CMA shall authenticate the identity of any organization that appears as a component of a subject name appearing in a certificate issued by the CA before processing the certificate application.

    2. Any organization requesting a certificate shall have a PKI Sponsor to accept the obligations of the organization.

      Note:

      This section pertains only to the authentication and naming of an organization as the subject in a certificate.

  2. Requests for certificates in the name of an organization or group shall include the necessary identifying data of the Sponsor, the group or organization name, address, and documentation of the existence of the organization.

    1. This information will include but is not limited to the following:

    • Organization identification and authorization

    • Contact information to enable the CMA to communicate with the PKI Sponsor as required

  3. The CMA shall verify this information, in addition to the authenticity and authorization of the requesting PKI Sponsor, authenticate the validity of any authorizations to be asserted in the certificate, and verify the source and integrity of the data collected to an assurance level commensurate with the certificate assurance level requested.

    1. The CPS shall specify acceptable measures for authenticating both the organization and PKI Sponsor’s identity and authorizations.

  4. The CMA shall also include his or her own identity information and authentication declaration.

    1. The PKI Sponsor shall present information sufficient for registration at the level of assurance requested, for both himself or herself and the non-human Entity (i.e., organization or group) requesting a certificate, and shall authenticate this information in person.

Authentication of Individual Identity
  1. The authentication of individual identity requirements defined in the following subsections apply.

Authentication of Human Subscribers
  1. For Subscribers (including all RAs/LRAs and PKI Sponsors of organizations, components, and minors or others not legally competent), the CMA shall ensure that the applicant’s identity information is verified in accordance with this CP, the applicable CPS, and all applicable MOAs.

    1. The CMA shall ensure that the applicant’s identity information and public key are adequately bound.

    2. For each assurance level, the applicant shall meet the minimum set of requirements identified in this section.

    3. A CMA may use mechanisms of equivalent or stronger assurance if documented in their CPS.

    4. The appropriate PKI CA CPS shall specify the acceptable procedures for authenticating a Subscriber’s identity.

  2. The CMA must record the process followed for each certificate.

    1. Process information shall depend upon the certificate’s level of assurance and shall be addressed in the applicable CPS.

  3. The documentation and authentication requirements vary depending upon the level of assurance. At a minimum, process documentation and authentication requirements shall include the following, depending on the level of assurance for issuance of each certificate:

    1. Identity of the applicant

    2. Identity of the person performing the identification

    3. A signed declaration by that person that he or she verified the identity of the applicant as required using the format set forth at 28 U.S.C. 1746 (declaration under penalty of perjury) or comparable procedure under local law; The signature on the declaration may be either a handwritten or digital signature using a certificate that is of equal or higher level of assurance as the credential being issued

    4. If in-person identity proofing is done, a unique identifying number(s) from the ID(s) of the applicant, or a facsimile of the ID(s)

    5. The date of the verification

    6. A declaration of identity signed by the applicant using a handwritten signature or appropriate digital signature (see Practice Note) and performed in the presence of the person performing the identity authentication, using the format set forth at 28 U.S.C. 1746 (declaration under penalty of perjury) or comparable procedure under local law

    Note:

    In those cases in which the individual is in possession of a valid digital signature credential of equal of higher level of assurance or the signature certificate is generated immediately upon authentication of the applicant’s identity, the applicant may sign the declaration of identity and certificate of acceptance using the digital credential. In the latter case, if the applicant fails to sign the declaration of identity then the certificate shall be revoked.

  4. For All Levels: As an alternative to presentation of identification credentials, the CMA may use other mechanisms of equivalent or greater assurance (including but not limited to comparison of biometric data to identities pre-verified to the standards of this policy, and obtained via authenticated interaction with secured databases).

  5. For Medium and High Assurance: The CMA shall establish identity no more than 30 days before initial certificate issuance. Before enabling the applicant’s certificate, the CMA shall personally verify the applicant’s identity. Minors and others not legally competent to provide face-to-face registration information alone shall be accompanied by a person already certified by the PKI (i.e., a Sponsor), who will present information sufficient for registration at the level of the certificate being requested, for himself or herself, and the person accompanied. Persons not physically capable of providing face-to-face registration information shall be proxied by a person already certified by the PKI, who will present information sufficient for registration at the level of the certificate requested, for both himself or herself and the person unable to appear himself or herself.

  6. An Entity certified by a State or Federal Entity as being authorized to confirm identities may perform in-person authentication on behalf of the RA/LRA. The certified Entity forwards the information collected from the applicant directly to the RA/LRA in a secure manner. Packages secured in a tamper-evident manner by the certified Entity satisfy this requirement; other secure methods are also acceptable. Such authentication does not relieve the RA/LRA of responsibility to verify the presented data.

  7. For PIV-I Certificates: The following biometric data shall be collected during the identity proofing and registration process, and shall be formatted in accordance with NIST SP 800-76 (see Exhibit 2 ):

    1. An electronic facial image used for printing the facial image on the card, as well as for performing visual authentication during card usage. A new facial image shall be collected each time a card is issued;

    2. Two (2) electronic fingerprints to be stored on the card for automated authentication during card usage.

  8. The table below summarizes the identification requirements for each level of assurance.

    Assurance Level Identification Requirements
    Rudimentary No identification requirement; applicant may apply and receive a certificate by providing his or her email address.
    Basic Identity may be established by in-person proofing before a RA/LRA; or by remotely verifying information provided by applicant through record checks with the applicable agency, credit bureaus, or similar databases to confirm that the information provided uniquely identifies an individual and that records are consistent with the application.
    Address confirmation:
    a) Issue credentials in a manner that confirms the address of record supplied by the applicant; or
    b) Issue credentials in a manner that confirms the ability of the applicant to receive telephone communications at a number associated with the applicant in records, while recording the applicant’s voice.
    Medium (all policies except PIV-I hardware) Applicant shall establish identity by in-person proofing before the RA/LRA, Trusted Agent, or an Entity certified by a State or Federal Entity as being authorized to confirm identities; the proofing authority shall verify such information provided to ensure legitimacy. A trust relationship between the Trusted Agent and the applicant, based on an in-person antecedent, may suffice as meeting the in-person identity-proofing requirement. Credentials required are either one Federal Government-issued Picture ID, one REAL ID Act compliant picture ID, or two non-Federal Government IDs, one of which shall be a photo ID (e.g., Non-REAL ID Act compliant Drivers License). Any credentials presented shall be unexpired. Clarification on the trust relationship between the Trusted Agent and the applicant, which is based on an in-person antecedent identity proofing event, can be found in the “FBCA Supplementary Antecedent, In-Person Definition” document https://www.idmanagement.gov/IDM/s/document_detail?Id=kA0t00000008OcMCAU.
    PIV-I Card Authentication, PIV-I Hardware For PIV-I, credentials required are two (2) identity source documents in original form. The identity source documents shall come from the list of acceptable documents included in Form I-9, OMB No. 1115-0136, Employment Eligibility Verification. At least one document shall be a valid State or Federal Government-issued picture identification (ID). For PIV-I, the use of an in-person antecedent is not applicable.
    High Applicant shall establish identity by in-person appearance before the RA/LRA, or Trusted Agent; the proofing authority shall verify such information provided to ensure legitimacy Credentials required are either one Federal Government-issued Picture ID, or two non-Federal Government IDs, one of which shall be a photo ID (e.g., Drivers License).
Authentication of Human Subscribers for Group Certificates
  1. Normally, a certificate shall be issued to a single Subscriber.

    1. For cases where there are several entities acting in one capacity, and where non-repudiation for transactions is not desired, a certificate may be issued that corresponds to a private key that is shared by multiple Subscribers.

    2. The Treasury PMA and/or RA shall record the information identified in IRM 10.8.52.2.3.1 “Authentication of Human Subscribers” for a sponsor from the organization’s PKI PMO or equivalent, before issuing a group certificate.

  2. In addition to the authentication of the sponsor, the following procedures shall be performed for members of the group:

    • The PKI PMOor equivalent shall be responsible for ensuring control of the private key, including maintaining a list of Subscribers who have access to use of the private key, and accounting for which Subscriber had control of the key at what time

    • The subjectName DN shall not imply that the subject is a single individual, e.g. by inclusion of a human name form

    • The list of those holding the shared private key shall be provided to, and retained by, the applicable CA or its designated representative

    • The procedures for issuing tokens for use in shared key applications shall comply with all other stipulations of this CP (e.g., key generation, private key protection, and Subscriber obligations)

  3. Group certificates shall not assert the following certificate policies defined within this CP: PIV-I Hardware, PIV-I Card Authentication, PIV-I Content Signing. Additionally, group certificates shall not assert any of the policies used by Treasury from the FCPF (i.e., PIV Authentication, PIV Card Authentication, and PIV Content Signing).

Authentication of Human Subscribers For Role-based Certificates
  1. There is a subset of human subscribers who will be issued role-based certificates.

  2. These certificates will identify a specific role on behalf of which the subscriber is authorized to act rather than the subscriber’s name and are issued in the interest of supporting accepted business practices.

    1. The role-based certificate can be used in situations where non-repudiation is desired.

    2. Normally, it will be issued in addition to an individual subscriber certificate.

  3. A specific role may be identified in certificates issued to multiple subscribers, however, the key pair will be unique to each individual role-based certificate (i.e. there may be four individuals carrying a certificate issued in the role of “Chief Information Officer” however, each of the four individual certificates will carry unique keys and certificate identifiers).

    1. Roles for which role-based certificates may be issued are limited to those that uniquely identify a specific individual within an organization (e.g., Chief Information Officer is a unique individual whereas Program Analyst is not).

    2. Role based certificates shall not be shared, but shall be issued to individual subscribers and protected in the same manner as individual certificates.

    3. For pseudonymous certificates that identify subjects by their organizational roles, the CA shall validate that the individual either holds that role or has been delegated the authority to sign on behalf of the role.

  4. The Treasury CAss shall record the information identified in this section for a sponsor associated with the role before issuing a role-based certificate. The sponsor shall hold an individual certificate in his/her own name issued by the same CA at the same or higher assurance level as the role-based certificate.

  5. The procedures for issuing role-based tokens shall comply with all other stipulations of this CP (e.g., key generation, private key protection, and Subscriber obligations).

  6. Role-based certificates shall not assert the following certificate policies defined within this CP:

    1. PIV-I Hardware

    2. PIV-I Card Authentication

    3. PIV-I Content Signing

    , . Additionally, role-based certificates shall not assert any of the policies used by Treasury from the FCPF (i.e., PIV Authentication, PIV Card Authentication, and PIV Content Signing).

Authentication of Devices
  1. Some computing and communications components (routers, firewalls, servers, etc.) will be named as certificate subjects. In such cases for all assurance levels, the component shall have a human PKI Sponsor.

    • Equipment identification (e.g., serial number) or service name (e.g., Domain Name Services (DNS) name) or unique software application name

    • Equipment or software application public keys

    • Equipment or software application authorizations and attributes (if any are to be included in the certificate)

    • Contact information to enable the CA or RA to communicate with the Sponsor when required

  2. The identity of the sponsor shall be authenticated by:

    1. Verification of digitally signed messages sent from the sponsor using a certificate issued under this policy; or

    2. In-person registration by the sponsor, with the identity of the sponsor confirmed in accordance with the requirements defined within this CP

  3. Acceptable methods for performing this authentication and integrity checking include, but are not limited to the following:

    1. Verification of digitally signed messages sent from the Sponsor (using certificates of equivalent or greater assurance than that requested)

    2. In person registration by the Sponsor, with the identity of the Sponsor confirmed in accordance with the requirements specified within this CP

  4. For Subscriber certificates issued to devices that use Federal Information Processing Standard (FIPS) 140 Level 2 or higher cryptographic, modules shall include either id-fpki-common-devices Hardware, id-fpki-common-devices, or both.

  5. Subscriber certificates issued to devices under this policy using software cryptographic modules shall include id-fpki-common-devices.

    Note:

    “Device” means a non-person entity, i.e., a hardware device or software application.

Non-verified Subscriber Information
  1. Except for the rudimentary assurance level, CMAs shall not include unverified information in certificates.

Validation of Authority
  1. For cross certification, the PKI PMO shall validate the representative’s authorization to act in the name of the organization, and include such verification in the recommendation to the PMA.

Criteria for Interoperation
  1. The PMA shall determine the criteria for cross certification with other Entities in accordance with this CP and the U.S. Government Public Key Infrastructure Cross Certification Methodology and Criteria. (See http://www.idmanagement.gov/federal-public-key-infrastructure.)

Identification and Authentication For Re-key Request

  1. The identification and authentication for re-key request requirements in the following subsections apply.

Identification and Authentication for Routine Rekey
  1. Rekeying a certificate means that the CMA creates a new certificate that has the same characteristics and level as the old one, except that the new certificate has a new, different public key (corresponding to a new, different private key) and a different serial number and possibly different validity period.

  2. In the event that a TRCA rekey is required, the FBCA shall issue a new certificate to the TRCA.

    1. For any subordinate PKI CA that requires a rekey, the TRCA shall issue its new certificate.

    2. Before issuance, the subordinate CA shall identify itself through use of its current signature key or the initial registration process.

    3. If it has been more than three years since the subordinate CA identification, the PKI subordinate CA shall re-establish identity through the initial registration process.

  3. Subscribers shall periodically obtain new keys and re-establish identity.

  4. A PKI CA may re-key Subscribers based on electronically authenticated Subscriber requests.

    1. Subscribers shall stop using private keys before the public key expires.

    2. Confidentiality private keys do not have a lifetime so Subscribers may use these keys at any time to decrypt information.

  5. For device certificates, issued by a CA, identity shall be established through the use of the device’s current signature key, the signature key of the device’s human sponsor, except that identity shall be established through the initial registration process at least once every nine years from the time of initial registration.

  6. The following key lifetimes given are maximums. A program may always require shorter lifetimes. The following key lifetimes are for end entities:

    Assurance Level Public Key Certificate Lifetimes
    Rudimentary Signature & confidentiality keys rekey every three years
    Basic Signature & confidentiality keys rekey every three years
    Medium (all policies) Signature & confidentiality keys rekey every three years
    High Signature & confidentiality keys rekey every three years
  7. Subscribers of PKI CAs shall identify themselves for the purpose of rekeying as required below:

    Assurance Level Routine Rekey Identity Requirements for Subscriber Signature and Encryption Certificates
    Rudimentary Subscriber shall establish identity through use of current signature key.
    Basic Subscriber shall establish identity through use of current signature key, except that the Subscriber shall re-establish identity through initial registration process at least once every fifteen years from the time of initial registration.
    Medium (all policies) Subscriber shall establish identity through use of current signature key, except that the Subscriber shall re-establish identity through initial registration process at least once every nine years from the time of initial registration, or as required by renewal of PIV Card. For mediumDevice and mediumDeviceHardware certificates, identity may be established through the use of current signature key or using means commensurate with the strength of the certificate being requested, except that identity shall be stablished through initial registration process at least once every nine years from the time of initial registration.
    PIV-I Card Authentication Identity shall be established through use of the current signature key certificate, except that identity shall be established through initial registration process at least once every nine years from the time of initial registration.
    High Subscriber shall establish identity through use of current signature key, except that identity shall be established through initial registration process at least once every three years from the time of initial registration, or as required by renewal of PIV Card.
  8. If Treasury implements the capability of associating authorizations with a certificate, including any conveyed or implied by the subject’s DN, the Subscriber and/or the Subscriber’s organization shall notify the appropriate CAs of the withdrawal of authorization.

    1. The CPS shall document the mechanisms used to notify the appropriate CAs of this action. In such instances, withdrawal of authorization may result in revocation of the old certificate and, if necessary, the issuance of a new certificate with a different public key and the appropriate associated authorizations.

Certificate Renewal
  1. Renewing a certificate means creating a new certificate with the same name, key, and authorizations as the old one, but a new, extended validity period, and a new serial number.

  2. The TRCA shall not perform certificate renewal for CA or Subscriber certificates.

    1. Any certificate issued by a TRCA with a new serial number shall contain a unique public key not previously certified.

    2. Subordinate PKI CAs may renew certificates.

    3. A PKI CA may renew a certificate if the public key has not reached the end of its validity, the associated private key has not been compromised, and the user name and attributes are still correct.

    4. The PKI CA need not revoke the old certificate, but may not rekey, renew, or update it further.

Certificate Update
  1. Updating a certificate means creating a new certificate that has the same or a different key, a different serial number, and differs in one or more other fields, from the old certificate.

    1. PKI subordinate CAs may or may not revoke the old certificate, but must not rekey, renew, or update it further. Except at Rudimentary assurance, if a Subscriber’s common name is legally changed (e.g., due to marriage or divorce), then legal proof of the name change (i.e., the same requirements used to apply for a certificate) shall be provided to the Designated Naming Authority to initiate the name change process in the directory structure. Once this change has taken place, the individual shall appear before (or be validated by) an RA/LRA in order for an updated certificate having the new name to be issued.

  2. When a PKI CA updates its private signature key and thus generates a new public key, the PKI CA shall notify all CAs, RAs, and Subscribers that rely on the CA’s certificate of the change.

    1. For self-signed (i.e., TRCA) certificates, such certificates shall be conveyed to users in a secure fashion to preclude malicious substitution attacks.

Identification and Authentication for Rekey after Revocation
  1. For all levels of assurance, Subscribers requesting certificates after revocation, other than during a renewal or update action, shall meet initial identity authentication and registration requirements, as indicated in the “Initial Identity Validation” section to obtain a new certificate.

    Note:

    This applies to all certificates issued by both a TRCA and any subordinate PKI CA.

Identification and Authentication for Revocation Request

  1. The CMA shall authenticate revocation requests in accordance with the established procedures of revocation request.

    1. The CMA may authenticate requests to revoke a certificate using signatures generated with that certificate’s associated private key, regardless of whether or not the private key has been compromised.

Certificate Lifecycle

  1. The Treasury CP specifies requirements imposed upon issuing CA, subject CAs, RAs, subscribers, or other participants with respect to the life-cycle of a certificate.

Application

  1. This policy identifies the minimum requirements and procedures that are necessary to support trust in the PKI, without imposing specific implementation requirements on CMAs or users, and specifies requirements for initial application for certificate issuance.

  2. The TRCA shall issue end-entity certificates to trusted role PKI Program Team personnel where necessary for the internal operations of the PKI TRCA.

    1. The TRCA will not issue end-entity certificates for any other reasons.

Submission of Certificate Application
  1. For the TRCA, the Treasury PMA shall submit the certificate application to the Federal Public Key Infrastructure Policy Authority (FPKIPA).

  2. For subordinate Treasury PKI CAs, subordinate and/or supported activities shall submit requests for subordinate PKI CA certificates to Treasury's PKI PMO.

Enrollment Process and Responsibilities
  1. Within Treasury, only the TRCA shall apply for cross certification with the Federal PKI, using the procedures outlined in the FBCA CP, the U.S. Government Public Key Infrastructure Cross Certification Criteria Methodology.

  2. Only the TRCA shall cross certify with external CAs, or establish subordinate CAs.

    1. A Certification Practices Statement, written to the format of the Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework (RFC 3647) shall accompany all such requests.

  3. Entities applying for cross certification are responsible for providing accurate information on their certificate applications.

    1. Upon issuance by the TCRA, the CMA shall manually check each certificate issued to a CA to ensure the proper population of each field and extension with the correct information before delivering the certificate to the Entity.

  4. All CMAs shall:

    1. Authenticate, and protect from modification, communications among PKI authorities supporting the certificate application and issuance process.

Certificate Application Processing

  1. The CMA shall verify the accuracy of certificate application information, using procedures as specified in the applicable CPS, before issuing certificates.

Performing Identification and Authentication Functions
  1. For the TRCA, the Treasury PKI PMA shall validate acceptance of applicant identification and authentication.

  2. For subordinate Treasury PKI CAs, the identification and authentication of the Subscriber mu meet the requirements specified for Subscriber authentication as specified within this policy.

    1. The applicant and the supporting CMA shall perform the steps outlined in the applicable CPS when an applicant applies for a certificate.

    2. The CMA and Subscribers may perform these steps in any order that is convenient and that does not defeat security; however, they must complete all steps before certificate issuance.

  3. CMAs shall authenticate and protect from modification all communications supporting the certificate application and issuance process using mechanisms commensurate with the protection requirements of the data.

    1. CMAs shall protect from unauthorized disclosure any electronic transmission of this data (i.e., encryption) commensurate with the protection requirements of the data.

Approval or Rejection of Certificate Application
  1. The PMA shall require an initial compliance audit to ensure that the PKI CAs and other Entity CAs are prepared to implement all aspects of the applicable CPS, before authorizing the PKI PMO to issue and manage certificates asserting Department of the Treasury.

    1. PKI CAs shall only issue certificates asserting certificate policies upon receipt of written notification from the PMA authorizing them to do so.

      Note:

      Key generation signing ceremony can serve as initial compliance audit.

  2. The PKI PMO and RAs/LRAs may reject any Subscriber, group, or component application that is incomplete, or that contains information that they cannot verify as accurate.

    1. The CMA may afford Subscribers and Sponsors the opportunity to complete and/or augment application information. Failure to do so will result in denial of PKI certificates; and the CMA shall submit a report via protected communications to the PKI PMO, outlining the circumstances and providing full identifying data about the applicant (i.e., Subscriber, organization, or device) and any Sponsor.

Time to Process Certificate Applications
  1. CMAs shall identify and authenticate Subscribers, organizations, components, and PKI Sponsors not more than 30 days prior to certificate issuance. Otherwise, the CMA shall re-confirm the identity to ensure issuance of the certificates to the appropriate individual.

Certificate Issuance

  1. The certificate issuance requirements in the following subsections apply.

CA Actions During Certificate Issuance
  1. It is the responsibility of the CMA to verify that the certificate information is correct and accurate.

    1. The CMA shall check all CA certificates to ensure that all fields and extensions are properly populated.

    2. The CMA shall not sign any certificate until the RA and/or LRA have completed all verifications and modifications, if any, to the CA’s satisfaction, and the identification and authentication process set forth in the CP and appropriate CPS are complete.

    3. If an RA or LRA denies a certificate request, then the CA shall not sign the requested certificate.

  2. CMAs shall verify all authorization and other attribute information received from an applicant. In most cases, the RA or LRA is responsible for verifying applicant data, but if CAs accept applicant data directly from applicants, then the CA is responsible for verifying the applicant data.

    1. The CMA shall verify information regarding attributes via those offices or roles that have authority to assign the information or attribute. The applicable CPS describes these processes and relationships.

Notification to Subscriber of Certificate Issuance
  1. Where notification is not an integral component of the issuance process (e.g., when individual is present as the certificate is generated on their token), PKI CAs shall proactively notify Subscribers that certificates have been generated.

Certificate Acceptance

  1. Before a Subscriber can make effective use of the private key, the CMA shall convey their responsibilities to the Subscriber (or Sponsor in the case of group/organization or device certificates).

  2. For Rudimentary assurance, there is no stipulation for use.

  3. For all other assurance levels before a CA provides a Subscriber or Sponsor with the private key and allows its effective use, a CMA shall inform the Subscriber of the certificate’s contents and responsibilities for its use and security; and require and document the Subscriber’s acceptance of those obligations.

  4. The CPS outlines the specific steps for conveying responsibilities.

Conduct Constituting Certificate Acceptance
  1. Failure to object to the certificate or its contents constitutes acceptance of the certificate.

Publication of the Certificate by the CA
  1. Each PKI CA shall publish all CA and Subscriber certificates in the appropriate certificate repositories.

Notification of Certificate Issuance by the CA to Other Entities
  1. For the TRCA, the Treasury PKI PMA shall provide notification to all subordinate and cross-certified entities, including the FPKIPA upon issuance of new inter-organizational CA cross certificates.

Key Pair and Certificate Usage

  1. The key pair and certificate usage requirements in the following subsections apply.

Subscriber Private Key and Certificate Usage
  1. Subscriber Private Key and Certificate Usage:

    1. For High, Medium Hardware, Medium, and Basic Assurance, Subscribers shall protect their private keys from access by other parties.

    2. For Rudimentary assurance, this IRM makes no stipulation for usage.

    3. The IRS PKI CA shall specify restrictions in the intended scope of usage for a private key through certificate extensions, including the key usage and other extensions as needed, in the associated certificate.

Relying Party Public Key and Certificate Usage
  1. Relying Party Public key and Certificate Usage:

    1. TRCA certificates issued to subordinate and cross-certified CAs, shall specify restrictions on use through critical certificate extensions, including the key usage extensions

    2. IRS PKI CAs shall issue a Certificate Revocation List (CRL) specifying the status of all unexpired certificates.

    3. Relying Parties shall process and comply with this information whenever using IRS PKI CA-issued certificates in a transaction.

Certificate Renewal

  1. Certificate renewal consists of issuing a new certificate with a new validity period and serial number while retaining all other information in the original certificate including the public key.

    1. Frequent renewal of certificates may assist in reducing the size of CRLs.

    2. The TRCA shall not perform certificate renewal for CA or Subscriber certificates.

  2. Where permitted after certificate renewal, an IRS PKI CA may or may not revoke the old certificate, but shall not rekey, renew, or modify it further.

Circumstance for Certificate Renewal
  1. Subordinate PKI CAs may renew Subscriber certificates if the public key has not reached the end of its validity period, the associated private key has not been compromised or expired, and the Subscriber name and attributes are unchanged.

    1. In addition, the validity period of the certificate shall meet the requirements specified within this policy.

    2. PKI CAs may also renew Subscriber certificates when the CA rekeys.

    3. The CMA may renew OCSP Responder certificates except that the aggregated lifetime of the public key shall not exceed the certificate lifetime.

Who May Request Renewal
  1. For subordinate PKI CAs that support renewal, the CA shall only accept renewal requests from certificate Subscribers, PKI Sponsors, or RAs.

    1. Additionally, a PKI CA may perform renewal of its Subscriber certificates without a corresponding request, such as when the CA rekeys.

Processing Certificate Renewal Requests
  1. For PKI CAs that support renewal, the PKI PMO shall approve certificate renewal for reasons other than rekey of the PKI CA.

Notification of New Certificate Issuance to Subscriber
  1. Subordinate PKI CAs shall proactively notify affected Subscribers of certificate renewal by any appropriate and secure means.

Conduct Constituting Acceptance of a Renewal Certificate
  1. Failure to object to the certificate or its contents constitutes acceptance of the certificate.

Publication of the Renewal Certificate by the CA
  1. PKI CAs shall publish all CA and Subscriber certificates in the appropriate certificate repositories.

Notification of Certificate Issuance by the CA to Other Entities
  1. For subordinate Treasury PKI CAs, the responsible Operating Authority shall notify the Treasury PKI PMO.

Certificate Rekey

  1. Rekeying a certificate consists of creating new certificates with a different public key (and serial number) while retaining the remaining contents of the old certificate that describe the subject.

    1. The new certificate may be assigned a different validity period, key identifiers, specify a different CRL distribution point, and/or be signed with a different key.

    2. After certificate rekey, the CA may or may not revoke the old certificate, but shall not rekey, renew, or modify it further.

    3. Rekey of a certificate does not require a change to the subject Name and does not violate the requirement for name uniqueness.

  2. Subscribers of Entity CAs shall identify themselves for the purpose of rekeying as required in the Identification and Authentication for Rekey Request section of this IRM.

Circumstances for Certificate Rekey
  1. The TRCA will issue new cross certificates to subordinate or cross-certified CAs when a currently recognized subordinate or cross-certified CA has generated a new key pair and a valid CPS exists between the TRCA and the subordinate or cross-certified CAs.

Who May Request Certification of a New Public Key
  1. The Treasury PKI PMA may request certification of a new public key for subordinate Treasury PKI CAs or cross-certified Entity Principal CAs.

    1. For subordinate CAs that support rekey, the CA shall only accept such requests from the subject of the certificate or PKI Sponsors.

    2. Additionally, CAs and RAs may initiate rekey of a Subscriber’s certificates without a corresponding request.

Processing Certificate Rekeying Requests
  1. For TRCA, before performing rekeys on cross-certified or subordinate CAs, the Treasury PKI PMA shall identify and authenticate Principal CAs by performing the identification processes.

    1. The validity period associated with the new certificate shall not extend beyond the period of the MOA.

Notification of New Certificate Issuance to Subscriber
  1. The Treasury PKI PMO shall notify subordinate Treasury PKI CAs and cross-certified Entity Principal CAs upon issuance of new certificates.

    1. Subordinate CAs shall proactively notify affected Subscribers of certificate renewal by any appropriate and secure means.

Conduct Constituting Acceptance of a Rekeyed Certificate
  1. Failure to object to the certificate or its contents constitutes acceptance of the certificate.

Publication of the Rekeyed Certificate to the CA
  1. PKI CAs shall publish all CA and Subscriber certificates in the appropriate certificate repositories.

Notification of Certificate Issuance by the CA to Other Entities
  1. For the TRCA, the Treasury PKI PMA shall provide notification to all subordinate and cross-certified entities, including the FPKIPA upon issuance of renewed inter-organizational CA cross certificates.

    1. For subordinate CAs, the responsible Operating Authority shall notify the Treasury PKI PMO.

Certificate Modification

  1. Certificate modification (a.k.a. update) consists of creating new certificates with subject information (e.g., a name or email address) that differs from the old certificate. For example, a subordinate IRS PKI CA may perform certificate modification for a Subscriber whose characteristics have changed (e.g., has just received a medical degree). The new certificate may have the same or different subject public key.

  2. After certificate modification, the IRS PKI CA may or may not revoke the old certificate, but shall not rekey, renew, or modify it further.

Circumstance for Certificate Modification
  1. For the TRCA, the CA performs certificate modification if the subordinate Treasury PKI CA or cross-certified Entity CA changes its name. For subordinate CAs and cross-certified Entity CAs, the CA performs certificate modification if the subject changes their name or other identifying data included in the certificate.

Who May Request Certificate Modification
  1. The Treasury PKI PMO or the subordinate CA (or cross-certified Principal CA) PKI OA may request certificate modification for subordinate Treasury PKI CAs (or cross-certified Entity Principal CAs).

  2. For subordinate Treasury PKI CAs that support modification, the CA shall only accept such requests from the subject of the certificate or PKI Sponsors.

    1. CAs and RAs may initiate modification of a Subscriber’s certificates without a corresponding request in cases where the change is the result of a modification to the CA or the directory.

Processing Certificate Modification Requests
  1. For the TRCA, the Treasury PKI PMO shall perform certificate modification at the direction of the PMA.

  2. The validity period associated with the new certificate shall not extend beyond the period of the MOA and the Information System Security Officer shall verify the information before the CA issues the modified certificate.

  3. For subordinate Treasury PKI CAs, the Subscriber shall provide proof of all Subscriber information changes to the RA/LRA or other designated agent; and the RA/LRA must verify the information before the CA issues the modified certificate.

Notification of New Certificate Issuance to Subscriber
  1. The Treasury PKI PMA shall notify subordinate Treasury PKI CAs and cross-certified Entity Principal CAs upon issuance of new certificates.

    1. Subordinate Treasury PKI CAs shall proactively notify affected Subscribers of certificate renewal or modification by any appropriate and secure means.

Conduct Constituting Acceptance of Modified Certificate
  1. Failure to object to the certificate or its contents constitutes acceptance of the certificate.

Publication of the Modified Certificate by the CA
  1. PKI CAs shall publish all CA and Subscriber certificates in the appropriate certificate repositories.

Notification of Certificate Issuance by the CA to Other Entities
  1. For the TRCA, the Treasury PKI PMA shall provide notification to all subordinate and cross-certified entities, including the FPKIPA upon issuance of modified inter-organizational CA cross certificates.

    1. For subordinate Treasury PKI CAs, the responsible Operating Authority shall notify the Treasury PKI PMO.

Certificate Revocation and Suspension

  1. The CMA shall authenticate all revocation requests.

  2. CMAs may authenticate requests to revoke a certificate using that certificate's associated private key, regardless of whether or not the private key has been compromised.

  3. For High, Medium Hardware, Medium, and Basic Assurance, all CAs shall publish CRLs.

Circumstances for Revocation
  1. The CMA will revoke certificates issued by the TRCA under three circumstances:

    1. The first circumstance is when the PMA requests revocation of a TRCA-issued certificate. This will be the normal mechanism for revocation in cases where the PMA determines that a subordinate Treasury PKI CA or a cross-certified Entity PKI does not meet the Treasury PKI CP requirements or certification of the Entity PKI is no longer in the best interests of the Department of the Treasury or the Federal Government.

    2. The second circumstance is when the Treasury PKI PMO receives an authenticated request from a previously designated official of the cross-certified Entity responsible for the Principal CA.

    3. The third circumstance is when the Treasury PKI Program Team determines that an emergency has occurred that may affect the integrity of the certificates issued by a Treasury PKI CA. Under such circumstances, the following individuals may authorize immediate certificate revocation:
      - Treasury PMA
      - Treasury PKI PMO
      - Treasury PKI OA

  2. The PMA shall review the emergency revocation as soon as practicable.

    1. The TRCA shall revoke, at a minimum, certificates for the reason of key compromise upon receipt of an authenticated request from a subordinate Treasury PKI CA or cross-certified Entity.

    2. Whenever any of the above circumstances occur, the TRCA shall revoke the associated certificate and place it on the appropriate revocation list.

    3. Revoked certificates shall be included on all new publications of the certificate status information until the certificates expire.

  3. For the TRCA, subordinate Treasury PKI CAs, and cross-certified Entity CAs, the CMA shall revoke a certificate when the binding between the subject and the subject’s public key defined within a certificate, excluding DN changes, is no longer considered valid.

  4. The CMA shall revoke a Subscriber certificate when the binding between the subject and the subject’s public key defined within a certificate is no longer valid. Examples of circumstances that invalidate the binding include but are not limited to the following:

    1. The Subscriber can be shown to have violated the stipulations of its Subscriber obligations and/or agreement

    2. The private key is suspected of compromise

    3. The user. Affiliated Organization, or other authorized party (as defined in the CPS) makes a formal request to the CMA asking to revoke his or her certificate

    4. Privileged attributes if implemented, asserted in the Subscriber’s certificate are reduced

  5. For Certificates that express an organizational affiliation, the CMA shall require that the organization must inform the CMA of any changes in the subscriber affiliation.

    1. If the affiliated organization no longer authorizes the affiliation of a Subscriber, the CMA shall revoke any certificates issued to that Subscriber containing the organizational affiliation.

    2. If an organization terminates its relationship with TCA such that it no longer provides affiliation information, the CMA shall revoke all certificates affiliated with that organization

  6. Whenever any of the above circumstances occur, the CMA revokes the associated certificate and places it on the CRL. Once revoked, a certificate will remain on the CRL or ARL at least until the certificate expires.

Who Can Request Revocation
  1. The PMA may direct revocation of a TRCA certificate, or certificate issued by the TRCA.

    1. Subordinate Treasury PKI CAs and cross-certified Entity CAs shall accept, at a minimum, revocation requests from Subscribers.

    2. The CMA may support requests for certificate revocation from other parties as specified in the appropriate CPS.

    3. A cross-certified Entity Principal CA may always revoke the certificate it has issued to a TRCA without PMA action.

  2. Within the TCA, a CA may summarily revoke certificates within its domain.

    1. An RA may request the revocation of a Subscriber’s certificate on behalf of any authorized party as specified in its CPS or Subscriber agreements. A Subscriber can request the revocation of his or her own certificate(s).

Procedure for Revocation Request
  1. Upon receipt of a revocation request involving a TRCA-issued certificate, the Treasury PKI shall authenticate the request and apprise the PMA.

    1. The PMA shall take whatever measures it deems appropriate to verify the need for revocation.

    2. If the revocation request appears valid, the PMA shall direct the Treasury PKI to revoke the certificate.

    3. The Treasury PKI PMO shall give prompt oral or electronic notification to previously designated officials in all subordinate Treasury PKI CAs and cross-certified Entities having a Principal CA with which the TRCA interoperates.

  2. Subordinate Treasury PKI CAs and cross-certified Entity CAs that implement certificate revocation shall revoke certificates upon receipt of sufficient evidence of compromise or loss of the Subscriber’s corresponding private key.

    1. A request to revoke a certificate shall identify the certificate to be revoked, explain the reason for revocation, and provide a means for the request to be authenticated (e.g., digitally, or manually signed).

    2. Where Subscribers use hardware tokens, revocation is optional if all the following conditions are met:

    • The revocation request was not for key compromise

    • The hardware token does not permit the Subscriber to export the signature private key

    • The Subscriber surrendered the token to the PKI CMA

    • The token was zeroized or destroyed promptly upon surrender

    • The token has been protected from malicious use between surrender and zeroization or destruction

  3. For PIV-I and in all other cases not defined above , revocation of the certificates is mandatory. Even where all the above conditions have been met, associated certificates shall be revoked.

  4. Upon receipt of a revocation request from the Subscriber or another authorized party, the CA shall authenticate the revocation request.

    1. The CA shall take measures to verify the need for revocation. Revocation takes effect upon publication of status information.

  5. For PKI implementations using hardware tokens, Subscribers lshall surrender to their sponsoring organization (e.g., Affiliated Organization) or CMA (through any accountable mechanism) all cryptographic hardware tokens issued under the sponsoring organization whenever they become invalid or before leaving the organization.

    1. If the CA cannot obtain the hardware tokens when a Subscriber leaves an organization, then the CA, immediately upon notification, shall revoke all Subscribers’ certificates associated with the un-retrieved tokens with the reason specified as key compromise.

    2. If later recovered, the token shall be zeroized or destroyed promptly upon surrender and shall be protected from malicious use between surrender and being zeroized or destroyed.

    3. Destruction of hardware tokens shall be recorded by the CMA or delegate.

Revocation Request Grace Period
  1. There is no grace period for revocation under this policy; Subscribers and authorized parties shall notify the CMA as soon as they identify the need to revoke a certificate.

Time Within Which CA Shall Process the Revocation Request
  1. The TRCA and subordinate CAs shall revoke certificates as quickly as practical upon receipt of a proper revocation request.

    1. Revocation requests shall be processed before the next CRL is published, excepting those requests validated within two hours of CRL issuance.

    2. Revocation requests validated within two hours of CRL issuance shall be processed before the following CRL is published.

    3. A request is considered received when a Trusted Role authorized to revoke certificates, first accesses a valid request.

Revocation Checking Requirements for Relying Parties
  1. This CP makes no stipulation.

    Note:

    Use of revoked certificates could have damaging or catastrophic consequences. The Relying Party and/or System Accreditor should make any determinations on the matter of how often new revocation data should be obtained, considering the risk, responsibility, and consequences for using a certificate whose revocation status cannot be guaranteed.

CRL Issuance Frequency
  1. CRLs shall be issued periodically, even if there are no changes to be made, to ensure timeliness of information. Certificate status information may be issued more frequently than the issuance frequency described below.

  2. Certificate status information shall be published not later than the next scheduled update.

    Note:

    This will facilitate the local caching of certificate status information for off-line or remote (laptop) operation.

  3. CAs that only issue certificates to other CAs and that operate off-line shall issue CRLs at least once every 31 days, and the nextUpdate time in the CRL may be no later than 32 days after issuance time (i.e., the thisUpdate time).

  4. CAs that issue certificates to subscribers or operate on-line shall issue CRLs at least once every 18 hours, and the nextUpdate time in the CRL may be no later than 180 hours after issuance time (i.e., the thisUpdate time).

  5. Practice Note: Since many applications only check for a new CRL at nextUpdate, a longer nextUpdate time may result in applications continuing to rely on older CRLs even when a newer CRL is available. A longer nextUpdate time also increases the potential of a replay attack to validate a newly revoked certificate. Where the CRL nextUpdate exceeds 48 hours, Relying Parties should consider these risks and take appropriate measures to mitigate the risk. For high risk, sensitive Relying Party applications suggested measures include configuring a preference for OCSP by applications, pre-fetching CRLs at least every 18 hours, and use of other compensating controls.

Maximum Latency of CRLs
  1. PKI CAs shall publish CRLs within four hours of generation.

    1. The CAs shall publish each CRL no later than the time specified in the nextUpdate field of the previously issued CRL for same scope.

Online Revocation/Status Checking Availability
  1. For all authentication levels except Rudimentary, Treasury shall support online certificate status checking via OCSP [RFC 2560]. Since Treasury operates in some environments that cannot accommodate online communications, all PKI CAs shall be required to support CRLs.

  2. Online Certificate Status Authority (OCSA) used for verifying certificates asserting Department of the Treasury certificate policies shall perform the following actions:

    1. Certificates indicated as being valid shall have a chain of valid certificates (valid as defined by X.509) linking back to the TRCA

    2. Each certificate in the certificate chain used to validate the certificate whose status is being requested is checked for revocation, such that the Relying Party need not check more than one OCSA to validate a Subscriber certificate

    3. The certificate status response makes clear which attributes, if any and if used, other than certificate subject name the CSA authenticates

  3. If an Entity CA supports online revocation and status checking, the latency of certificate status information distributed online by Entity CAs or their delegated status responders shall meet or exceed the requirements for CRL issuance.

Online Revocation Checking Requirements
  1. This CP makes no stipulation. Clients using online revocation checking need not obtain or process CRLs.

Other Forms of Revocation Advertisements Available
  1. A CA may also use other methods to publicize the certificates it has revoked.

    1. Any alternative method shall meet the following requirements:

    • Shall be described in the appropriate CPS

    • Shall provide authentication and integrity services commensurate with the assurance level of the certificate being verified

    • Any alternate forms used to disseminate revocation information shall be implemented in a manner consistent with the security and latency requirements for the implementation of CRLs and online revocation and status checking

Special Requirements Related to Key Compromise
  1. In the event of a TRCA or Entity Principal CA (non-Treasury, non-subordinate) private key compromise or loss, the cross certificates shall be revoked and a CRL shall be published at the earliest feasible time by the Treasury PKI OA.

  2. For subordinate Treasury PKI CAs, when a CA certificate is revoked or Subscriber certificate is revoked because of compromise, or suspected compromise, of a private key, a CRL shall be issued as specified below:

    Assurance Level Maximum Latency for Emergency CRL Issuance
    Rudimentary No stipulation
    Basic 18 hours after notification
    Medium (all policies) 18 hours after notification
    PIV-I Card Authentication 18 hours after notification
    High 6 hours after notification
  3. The CRL shall contain codes identifying the reason for revoking a certificate and/or specific key pair.

  4. For CAs that only issue CA certificates and are operated in an off-line manner, the interval between routine CRL issuance shall not exceed 31 days.

    1. Such CAs shall meet the requirements specified above for issuing Emergency CRLs.

      Note:

      Such CAs shall also be required to notify the FPKI Management Authority upon Emergency CRL issuance.

Circumstances for Suspension
  1. For CA certificates, suspension is not permitted.

  2. For end entity certificates with private keys residing on PIV cards, suspension is allowed.

  3. The Subscriber, Sponsor, or a Security Officer shall have knowledge of the whereabouts of the PIV card at the time of the suspension request and throughout the suspension period.

Those Authorized to Request Suspension
  1. Sponsors and Security Officers are authorized to request suspension. Other parties, such as supervisors, security personnel, and adjudicators, may request suspension of certificates by providing a reason for the suspension request.

Requirement for Suspension
  1. Any format that is used to request a suspension shall identify the certificate(s) to be suspended, explain the reason for suspension, include an estimated time for the resolution of the suspension, and allow the request to be authenticated (e.g., digitally or manually signed).

  2. Once approved by the RA, the certificates on the PIV card shall be marked suspended and the serial numbers and other identifying information placed on a CRL, in addition to any other suspension or revocation advertisement mechanisms used.

  3. A Security Officer or a Sponsor coming into possession of the PIV card during the suspension period they shall put the card into a locked state The token shall be protected from malicious use between surrender and return to the Subscriber.

  4. A Security Officer shall have reasonable knowledge of the whereabouts of the PIV card at the time of the suspension request and throughout the suspension period.

Limits on Suspension Period
  1. The certificate(s) may not be suspended for more than two (2) weeks unless the PIV Card is under the control of a Security Officer in a locked state, in which case it may be suspended for up to nine (9) months.

  2. If the binding between the Subscriber and the certificate cannot be reestablished before the suspension period expires, then the certificate shall be revoked.

Certificate Status Services

  1. Treasury PKI supports online certificate status checking via Online Certificate Status Protocol (OCSP) [RFC 2560] and stipulates policy about online certificate status checking in the Certificate, CARL/CRL, and OCSP Profiles Format section of this IRM

Operational Characteristics
  1. No further stipulation.

Service Availability
  1. No further stipulation.

Optional Features
  1. No further stipulation.

End of Subscription

  1. No further stipulation.

Key Escrow and Recovery

  1. The TRCA shall not perform any encryption key recovery functions involving subordinate Treasury PKI CAs or cross certified Entity CAs, and shall not store any information encrypted by the Treasury PKI CA public key that may require key recovery capabilities. However, if and when encryption key pairs need to be issued by the TRCA covering repository system access or for other purposes, the PMA shall publish applicable requirements for that purpose.

Key Escrow and Recovery Policy and Practices
  1. Department of the Treasury PKI key recovery policies and procedures are addressed in the Key Recovery Policy (KRP) and the Key Recovery Practices Statement (KRPS).

    1. The KRPS shall be identified in the CPS. Treasury PKI CA private keys are never escrowed.

  2. Subordinate Treasury PKI CAs may escrow Subscriber key management keys to provide key recovery.

    1. The CA shall protect escrowed keys at no less than the level of security appropriate to the assurance level of the certificate.

Session Key Encapsulation and Recovery Policy and Practices
  1. TCA does not use session key encapsulation and recovery, and as such it is out of scope of this CP.

Facility Management and Operations Controls

  1. The IRS shall implement Facilities, Management and Operation Control controls used by the issuing CA to securely perform the functions of key generation, subject authentication, certificate issuance, certificate revocation, audit, archiving, responding to suspected or detected compromise, and disaster recovery.

  2. The requirements in the following Facility Management and Operations Control subsections augment the associated requirements in IRM 10.8.1 See IRM 10.8.1 and for additional guidance.

Physical Controls

  1. All PKI CA equipment, including CA cryptographic modules, shall be protected from unauthorized access at all times in accordance with TD-P 15-71Treasury Security Manual.

    1. The IRS shall impose physical security requirements that provide similar levels of protection as those specified below. All the physical control requirements apply equally to the Treasury PKI Root, subordinate CAs, and any remote workstations used to administer the CAs except where specifically noted.

Site Location and Construction
  1. The location and construction of the facility housing PKI CA equipment, as well as sites housing remote workstations used to administer the CAs, shall be consistent with facilities used to house high value, sensitive information.

    1. The site location and construction, when combined with other physical security protection mechanisms such as guards, high security locks, and intrusion sensors, shall provide robust protection against unauthorized access to CA equipment and records.

Physical Access
  1. Physical access controls to IRS PKI equipment and facilities shall be implemented .

Physical Access for CA Equipment
  1. The CMA staff and IRS PKI facilities shall protect IRS PKI CA equipment, to include remote workstations used to administer the CAs, from unauthorized access at all times.

    1. The security mechanisms shall be commensurate with the level of threat in the equipment environment. Since the Treasury PKI Treasury Root and subordinate CAs shall plan to issue certificates at all levels of assurance, the PKI OA shall operate and control all CAs on the presumption that each shall issue at least one High Assurance certificate.

  2. The physical security requirements pertaining to PKI CAs shall include:

    1. Ensure no unauthorized access to the hardware is permitted

    2. Ensure all removable media and paper containing sensitive plain-text information is stored in secure containers

    3. Ensure manual or electronic monitoring for unauthorized intrusion at all times

    4. Ensure an access log is maintained and inspected periodically

  3. In addition to those requirements, the following requirements shall apply to PKI CAs that issue Medium, PIV Card Authentication, Medium Hardware, or High assurance certificates:

    • Require two person physical access control to both the cryptographic module and computer systems

  4. Multiparty physical access control to CA equipment can be achieved by any combination of two or more trusted roles as long as the tasks being conducted are segregated in accordance with the requirements and duties defined for each trusted role.

  5. The CMAs shall inactivate removable CA cryptographic modules before storage.

    1. When not in use, the CMA staff shall place removable CMA cryptographic modules, removable media, and any activation information used to access or enable CMA cryptographic modules or CMA equipment, or paper containing sensitive plain-text information, in locked containers.

    2. Such containers shall be sufficient for housing equipment and information commensurate with the classification, sensitivity, or value of the information protected by the certificates issued by the CMA.

    3. CMA staff shall either memorize or record and store activation data in a manner commensurate with the security afforded the cryptographic module, and shall not store such data with the cryptographic module or removable hardware associated with remote workstations used to administer the CA.

  6. A security check of the facility housing PKI CA equipment or remote workstations used to administer the CAs shall occur before leaving the facility unattended. At a minimum, the check shall verify the following:

    1. The equipment is in a state appropriate to the current mode of operation

    2. Any security containers are properly secured

    3. Physical security systems are functioning properly

    4. The area is secured against unauthorized access

  7. The PKI PMO shall explicitly designate a person or group of persons responsible for making such checks. When a group of persons is responsible, the Treasury PKI OA shall maintain a log identifying the person performing a check in each instance. 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.

  8. The following requirements shall apply to CAs operating at the Medium or High assurance level:

    1. Be manually or electronically monitored for unauthorized intrusion at all times

    2. Ensure a visitor access log is maintained and periodically inspected

Physical Access for RA Equipment
  1. RA and LRA equipment shall be protected from unauthorized access while the cryptographic module is installed and activated.

    1. The RA and LRA shall implement physical access controls to reduce the risk of equipment tampering even when the cryptographic module is not installed and activated.

    2. RA and LRA cryptographic tokens shall be protected against theft, loss, and unauthorized use.

    3. These security mechanisms shall be commensurate with the level of threat in the RA and LRA equipment environment.

Physical Access for CSS Equipment
  1. Physical access control requirements for CSS equipment (if implemented) shall meet the PKI CA physical access requirements specified within the Physical Access for CA Equipment section.

Power and Air Conditioning
  1. The facility housing CA equipment shall have power and air conditioning sufficient to create a reliable operating environment.

    1. PKI CAs operating at a Basic, Medium, or High assurance level shall have backup capability sufficient to automatically lockout input, finish any pending actions, and record the state of the equipment before lack of power or air conditioning causes a shutdown.

    2. The PKI CA directories (containing TCA issued certificates and CRLs) shall have Uninterrupted Power sufficient for a minimum of six hours operation in the absence of commercial power.

Water Exposures
  1. The PKI PMO shall install CA equipment such that it is not in danger of exposure to water, and ensure installation of moisture detectors in areas susceptible to flooding. The requirement excludes potential water damage from fire prevention and protection measures (e.g., sprinkler systems).

    1. Contingency plans for a CA that has sprinklers for fire control shall address recovery if the sprinklers malfunction, or cause water damage outside the fire area.

Fire Prevention and Protection
  1. A description of the CMA’s approach for recovery from a fire disaster shall be included in the Disaster Recovery Plan.

Media Storage
  1. Media shall be stored to protect it from accidental damage (water, fire, electromagnetic) and unauthorized access in accordance with IRM 10.8.1

    1. Media that contains security audit, archive, or backup information shall be stored in a location separate from the CMA equipment.

Waste Disposal
  1. CMAs shall remove or destroy normal office waste in accordance with IRM 10.8.1.

    1. The CMAs shall destroy media used to collect, transmit, or store sensitive information , such that the information is unrecoverable before disposal.

    2. Sensitive waste material (i.e., documentation) shall be disposed of in a secure fashion (e.g., shredding or burning).

Off-Site Backup
  1. For PKI CAs operating at Basic, Medium, or High assurance levels full system backups, to recover from system failure, shall be made on a periodic schedule, as described in the respective CPS.

    1. Backups are to be performed and stored off-site not less than once per week.

    2. At least one full backup copy shall be stored at an offsite location (separate from the CA equipment).

    3. Only the latest full backup need be retained.

    4. The backup shall be stored at a site with physical and procedural controls commensurate to that of the operational CA.

Procedural Controls

  1. Unless stated otherwise, the requirements in this section apply equally to all PKI CAs.

Number of Persons Required per Task
  1. Only one person is required per task for CAs operating at the Rudimentary and Basic Levels of Assurance.

    1. Medium, Medium Hardware, and High assurance CAs shall enforce multi-person controls on the CA private signing key to prevent duplication or theft without collusion.

  2. Two or more persons are required for the following tasks:

    • CA key generation

    • CA signing key activation

    • CA private key backup

  3. Where multiparty control for logical access is required, at least one of the participants shall be an Administrator.

    1. All participants shall serve in a trusted role.

    2. Multiparty control for logical access shall not be achieved using personnel that serve in the Auditor Trusted Role.

  4. Physical access to the CAs does not constitute a task as defined in this section. Therefore, multiparty physical access control may be achieved.

Identification and Authentication for Each Role
  1. At all assurance levels other than Rudimentary, an individual shall identify and authenticate him or herself before being permitted to perform any actions set forth above for that role or identity.

Separation of Roles
  1. Role separation, when required as set forth below, may be enforced either by the CA equipment, or procedurally, or both.

    1. Requirements for the separation of roles and limitations on use of procedural mechanisms to implement role separation for the TRCA and any subordinate CAs shall be as follows:

      Assurance Level Separation Rules
      Rudimentary No Stipulation
      Basic The CPS shall specifically designate individual CA personnel to the four roles defined in the Trusted Roles section of this IRM. In general, individuals may assume more than one role; however, no one individual shall assume both the Officer and Administrator roles. The Treasury PKI CAs may enforce this procedurally. No individual shall have more than one identity.
      Medium (all policies) The CPS shall specifically designate individual CA personnel to the four trusted roles. Individuals may only assume one of the Officer, Administrator, and Auditor roles, but generally, any individual may assume the Operator role. The CA and RA 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/or assume both the Auditor and Officer roles. No individual shall have more than one identity.
      PIV-I Card Authentication Individual personnel shall be specifically designated to the four roles defined in the Trusted Roles section above. Role separation duties follow the requirements for Medium assurance above.
      High The CPS shall specifically designate individual personnel to the four roles defined in the Trusted Roles Section above. Individuals may assume only one of the Officer, Administrator, and Auditor roles. Generally, individuals designated as Officer or Administrator may also assume the Operator role. An auditor may not assume any other role. The CA and RA software and hardware shall identify and authenticate its users and shall enforce these roles. No individual shall have more than one identity.
  2. Under no circumstances shall the incumbent of a CMA role perform its own external compliance auditor function.

    1. Only the CA Auditor may perform internal compliance auditor functions.

    2. The TRCA shall operate at the High Assurance level.

    3. The appropriate CPS designates the operating assurance level of individual subordinate CAs.

Personnel Controls

  1. The following personnel controls within the following sections apply.

Background, Qualifications, Experience, and Security Clearance Requirements
  1. The PKI PMO shall identify at least one individual or group responsible and accountable for the operation of each CA in the TCA. For the TRCA, these are the Treasury PMO and the PKI PMO.

  2. Selection for any CMA or other PKI trusted role is on the basis of loyalty, trustworthiness, and integrity. Trusted persons may be IRS direct-hire personnel or contractors, but only U.S. citizens may fill trusted roles.

  3. Only employees of the PKI Program Team shall fill PKI CA trusted roles, unless specifically appointed by the PKI OA to satisfy operational requirements. Personnel appointed to the CA trusted roles shall meet the following requirements:

    1. Be employees of the IRS, GS-5 (equivalent) or above, or equivalent contractor/vendor position of responsibility

    2. Have not been previously relieved of CMA related duties for reasons of negligence or non-performance of duties

    3. Have not been denied a security clearance, or had a security clearance revoked

    4. Have not been convicted of a felony offense

    5. Be appointed in writing by the PKI OA

    6. PKI Program Team personnel acting in trusted roles for the Treasury Root and subordinate CAs appointed by the PKI OA, shall hold TOP SECRET security clearances

  4. For additional personnel security requirements, refer to IRM 10.8.1 and the 10.23 Personnel Security IRM series for additional personnel security guidance.

  5. The naming requirements in the following subsections apply.

  6. All employees and contractors accessing sensitive IT systems shall be subject to a background investigation at the risk level appropriate to the sensitivity of the position held and sensitivity/classification of the data in accordance with 5 CFR 731.106(a), OPM policy, FIPS 201, NIST SP 800-73, NIST 800-76, and NIST 800-78.

  7. Background investigations shall be based on the following certificate assurance level:

    1. Rudimentary: N/A.

    2. Basic: CA and RA shall have a Background Investigation (BI) using Standard Form 85P, “Questionnaire for Public Trust Positions.”

    3. Medium: CA and RA shall have a Background Investigation (BI) using Standard Form 86, “Questionnaire for National Security Positions.”

    4. High: CAs and RAs shall have a Single Scope Background Investigation using Standard Form 86, “Questionnaire for National Security Positions.”

  8. The PKI OA shall identify at least one individual or group responsible and accountable for the operation of each CA in the TCA. For the TRCA, these are the Treasury PMO and the PKI OA.

  9. Selection for any CMA or other PKI trusted role is on the basis of loyalty, trustworthiness, and integrity. Trusted persons may be IRS direct-hire personnel or contractors, but only U.S. citizens may fill trusted roles.

  10. Only employees of the PKI Program Team shall fill IRS PKI CA trusted roles, unless specifically appointed by the PKI PMO to satisfy operational requirements. Personnel appointed to the CA trusted roles shall meet the following requirements:

    • Be employees of the IRS, GS-5 (equivalent) or above, or equivalent contractor/vendor position of responsibility

    • Have not been previously relieved of CMA related duties for reasons of negligence or non-performance of duties

    • Have not been denied a security clearance, or had a security clearance revoked

    • Have not been convicted of a felony offense

    • Be appointed in writing by the PKI PMO

    • PKI Program Team personnel acting in trusted roles for the Treasury Root and subordinate CAs appointed by the PKI PMO, shall hold TOP SECRET security clearances

  11. PKI Program Team and other designated personnel acting in RA trusted roles shall undergo, at a minimum, background check procedures necessary to be cleared for the TOP SECRET level. Information obtained from such checks, performed solely to determine the suitability of a person to fill a PKI role, are not releasable unless authorized by the PMA, this policy, required by law, government rule or regulation, or an order from a court of competent jurisdiction.

  12. PKI CA personnel shall pass, at a minimum, a background investigation covering the following areas:

    • Employment

    • Education

    • Place of residence

    • Law Enforcement

    • References

  13. The period of investigation must cover at least the last five years for each area, excepting the residence check, which must cover at least the last three years. Regardless of the date of award, the investigation shall verify the highest educational degree obtained.

  14. A trained IRS PS Adjudicator will adjudicate a background investigation.

  15. For additional personnel security requirements, refer to IRM 10.8.1 and the 10.23 Personnel Security IRM series for additional personnel security guidance.

Background Check Controls
  1. PKI Program Team and other designated personnel acting in Trusted Rolesshall undergo, at a minimum, background check procedures necessary to be cleared for and maintain aTOP SECRET level. Information obtained from such checks, performed solely to determine the suitability of a person to fill a PKI role, are not releasable unless authorized by the PMA, this policy, required by law, government rule or regulation, or an order from a court of competent jurisdiction.

  2. PKI CA personnel shall pass, at a minimum, a background investigation covering the following areas:

    • Employment

    • Education

    • Place of residence

    • Law Enforcement

    • References

  3. The period of investigation shall cover at least the last five years for each area, excepting the residence check, which shall cover at least the last three years. Regardless of the date of award, the investigation shall verify the highest educational degree obtained.

  4. A trained IRS PS Adjudicator shall adjudicate a background investigation.

Training Requirements
  1. All personnel performing duties with respect to the operation of the PKI CAs shall receive comprehensive training in all operational duties they will perform, including disaster recovery and business continuity procedures.

  2. The PKI Program Team shall ensure appropriate training for all personnel involved in CMA operations. Training will address the following topics:

    • Operation of the CMA software and hardware

    • CA operational and security procedures and mechanisms

    • Stipulations of this policy and local guidance

    • All PKI software versions in use

    • All PKI duties personnel shall perform

    • Disaster recovery and business continuity procedures

  3. The specific training required will depend on the equipment used and the personnel selected.

  4. The PKI Program Team shall establish a training plan for a CMA installation.

    1. The PKI Program Team shall maintain documentation identifying all personnel who received training and the level of training completed.

    2. Where individuals demonstrated competence in lieu of training, the PKI Program Team shall maintain supporting documentation.

    3. CMA Training is the responsibility of the PKI Program Team, under the PKI PMO.

Retraining Frequency and Requirements
  1. Personnel responsible for PKI trusted roles shall be aware of changes in the PKI CA operation.

    1. Any significant change to CMA operations shall have a training (awareness) plan, and the PKI Program Team shall document execution of such plans.

      Note:

      Examples of such changes are CA software or hardware upgrade, changes in automated security systems, and relocation of equipment.

    2. The PKI Program Team shall maintain documentation identifying all personnel who received training and the level of training completed.

Job Rotation Frequency and Sequence
  1. This policy makes no stipulation regarding frequency or sequence of job rotation.

    1. IRS policies that do impose such requirements shall provide for continuity and integrity of the PKI service.

Sanctions for Unauthorized Actions
  1. A CMA (IRS or Treasury depending on local or external certificate usage respectively) shall report suspected security violations or compromises to the appropriate Security organization and the PKI PMO so that the proper authorities may take appropriate administrative and/or disciplinary actions against personnel who violate applicable policy.

  2. The PKI OA shall take appropriate actions where personnel have performed actions involving the PKI CAs or repositories not authorized in this CP, the appropriate CA CPS, or other procedures published by the PKI PMO.

Independent Contractor Requirements
  1. Contractor personnel employed to operate any part of the PKI CAs or perform functions pertaining to the PKI infrastructure shall be subject to the same criteria set forth in IRM 10.8.1 and this IRM.

    1. Contractor personnel filling trusted roles shall be cleared to the TOP SECRET level.

    2. PKI subcontractors who provide services to the IRS shall establish procedures to ensure that they perform in accordance with this policy.

Documentation Supplied To Personnel
  1. Personnel filling trusted roles shall receive documentation sufficient to define duties and procedures for each role.

    1. This documentation includes, but is not limited to this CP; relevant portions of the applicable CPS, Contingency Plan, and Key Recovery Practices Statement (KRPS); any relevant statutes, policies, and/or contracts; and any relevant programmatic documentation (e.g., CONOPS, Implementation Plan).

    2. Documentation may also include any handbooks, guidelines, or instructional manuals that have been or may be developed to ensure that personnel filling trusted roles are adequately trained.

Audit Logging Requirements

  1. PKI CAs shall generate audit log files for all events relating to the security of the CAs.

    1. Where possible, the CAs shall automatically collect security audit log data.

    2. Where this is not possible, the CMA shall use a logbook, paper form, or other physical mechanism.

    3. The CMA shall retain and make available during compliance audits all security audit logs, both electronic and non-electronic.

    4. The CMA shall maintain the security audit logs for each auditable event defined in this section in accordance with retention period for archive.

Types of Events Recorded
  1. For audit logging requirements, refer to IRM 10.8.1

Frequency of Processing Log
  1. For audit log processing frequency, refer to IRM 10.8.1

Retention Period for Audit Logs
  1. For audit log retention periods, please refer to IRM 10.8.1

Protection of Audit Logs
  1. For audit log protection requirements, refer to IRM 10.8.1

Audit Log Backup Requirements
  1. The CMA shall:

    1. Backup audit logs and audit summaries at least monthly.

    2. Send a copy of the audit log off-site.

    3. Protect the security audit data backup.

Audit Collection System
  1. The security audit process shall run independently, and the CMA shall not control it in any way.

  2. PKI CAs shall invoke security audit processes (automated and manual) at system or application startup, and cease only at system or application shutdown.

    1. In the event that the automated security audit system fails, the CMA shall cease all operations, except for revocation processing, until it can restore the security audit capability.

    2. Under these circumstances, the CMA shall employ mechanisms to preclude unauthorized CMA functions.

    3. The CPS shall describe these mechanisms.

Notification to Event-Causing Subject
  1. This policy imposes no requirement to notify an individual, organization, device, or application that caused an auditable event.

  2. This policy neither requires nor prohibits real-time alerts.

Vulnerability Assessments
  1. The CMA, system administrator, and other operating personnel shall routinely assess whether the CA system or its components have been attacked, breached, or for attempts to violate the integrity of the certificate management system, including the equipment, physical location, and personnel.

  2. The Security Operations (SecOps) Analysts shall review security audit data for events such as repeated failed actions, requests for privileged information, attempted access of system files, and unauthenticated responses. Security Operations Analystsshall check for continuity of the security audit data.

Records Archive

  1. In addition to the records archiving requirements defined in IRM 1.15.6 Records and Information Management, Managing Electronic Records, the records archive requirements defined in the following subsections apply.

Types of Events Archived
  1. CMA archive records shall collect and maintain enough detail to establish the proper operation of the PKI CAs, or the validity of any certificate (including revoked and/or expired) issued by the CA.

  2. For minimum archive requirements, refer to IRM 10.8.1.

Retention Period for Archive
  1. For minimum retention periods for archive data, refer to IRM 10.8.1

  2. Executive branch agencies shall follow either the General Records Schedule established by the National Archives and Records Administration or IRM 1.15.x series as applicable. All other entities shall comply with their respective records retention policy in accordance with whatever law applies to that entity.

Protection of Archive
  1. For details regarding the protection of PKI archived records, refer to IRM 10.8.1

Archive Backup Procedures
  1. The Data Archive Policy and Procedure shall describe archive records back up, and archive backup management procedures.

Requirements for Time-Stamping of Records
  1. For information regarding Time Stamping, refer to IRM 10.8.1.

Archive Collection System
  1. PKI CA systems, or the CMA staff, may collect archive data in any expedient manner, provide the collection process does not modify or delete the archive records and protects the data as outlined within this policy.

Requirements to Obtain & Verify Archive Information
  1. Refer to the 1.15.x series for record retention requirements.

  2. The CMA shall not release the contents of the archive except as determined by the PMA or as required by law.

    1. The CMA or archive site may release records of individual transactions upon request of any Subscribers involved in the transaction, or their legally recognized agents.

Key Changeover

  1. CAs shall not issue Subscriber certificates that extend beyond the expiration dates of their own certificates and public keys.

    1. Each Treasury PKI CA certificate validity period shall extend one user certificate validity period past the last use of the CA private key.
      i. To minimize the risk from compromise of a CAs private signing key, the private signing key shall l change more frequently, and from that time on, certificate signing will use only the new key for certificate signing purposes.
      ii. The older, but still valid, certificate shall l be available to verify old signatures until all of the user certificates signed under it have also expired.
      iii. If the old private key signed CRLs that contain certificates also signed with that key, then the CA shall retain and protect the old key.

  2. CAs shall not issue Subscriber certificates that extend beyond the expiration dates of their own certificates and public keys.

    1. Each Treasury PKI CA certificate validity period shall extend one user certificate validity period past the last use of the CA private key.
      i. To minimize the risk from compromise of a CAs private signing key, the private signing key shall change more frequently, and from that time on, certificate signing shall use only the new key for certificate signing purposes.
      ii. The older, but still valid, certificate will be available to verify old signatures until all of the user certificates signed under it have also expired.
      iii. If the old private key signed CRLs that contain certificates also signed with that key, then the CA must retain and protect the old key.

Compromise and Disaster Recovery

  1. Production CA and directory service operations shall develop and test a continuity of operations plan.

  2. If a CA is compromised or unable to function, the IRS shall notify the PMA immediately and implement restoration in accordance with the approved CPS. The PMA shall conduct an audit of the restored CA.

  3. Refer to IRM 10.8.1,IRM 10.8.60IT Disaster Recovery Policy and Guidance, and IRM 10.8.62, Disaster Recovery Testing for additional guidance on contingency planning and disaster recovery.

Incident and Compromise Handling Requirements
  1. For Incident and Compromise Handling Requirement, refer to IRM 10.8.1

Computing Resources, Software, and/or Data Are Corrupted
  1. When computing resources, software, and/or data are corrupted, the affected TRCA and subordinate CAs shall respond as follows:

    • Before returning to operation, the CMA shall ensure that system integrity has been restored; and shall notify the PKI PMO and PMA

    • If the CA signature keys are not destroyed, CA operation shall be reestablished, giving priority to the ability to generate certificate status information within the CRL issuance schedule

    • If the CA signature keys are destroyed, CA operation shall be reestablished as quickly as possible, giving priority to the generation of a new CA key pair

Entity (CA) Requirements
  1. In case of a CA key compromise or loss (such that compromise is possible even though uncertain) involving the TRCA:

    • The PMA shall immediately notify the FPKIPA and all of its member entities so that those entities may issue CRLs revoking any cross certificates issued to the TRCA.

    • The TRCA CMA shall remove the trusted self-signed certificate from each Relying Party application, and shall distribute a new one via secure out-of-band mechanisms. The TRCA will describe its approach to reacting to a TRCA key compromise in its CPS.

    • The PKI Program Team may generate a new TRCA key pair in accordance with procedures set forth in the TRCA CPS if so determined by the PMA.

    • The PKI Program Team may also issue new TRCA certificates to the FCPCA and all cross-certified Entities in accordance with the TRCA CPS. If the CA distributes its key in a trusted certificate, the CMA shall distribute the new trusted certificate.

  2. In case of a CA key compromise or loss involving a subordinate CA:

    • The TRCA shall revoke that CA’s certificate, and publish the revocation information immediately in the most expedient manner.

    • The TRCA shall re-establish the subordinate CA installation as outlined herein.

    • The FPKIPA and all of its member entities shall be notified.

    • If re-establishment is directed, the CMA shall generate a new CA key pair in accordance with procedures set forth in the appropriate CPS.

    • Upon re-establishment, the CMA shall issue new CA certificates to Entities also in accordance with the affected CA CPS.

  3. The PKI PMO shall also investigate and report to the PMA what caused the compromise or loss, and what measures have been taken to preclude recurrence.

Business Continuity Capabilities After a Disaster
  1. The PKI PMO shall maintain a Disaster Recovery Plan and shall operate a warm backup site, whose purpose is to ensure continuity of operations in the event of failure of the primary site.

    1. PKI CA operations shall be designed to restore full service within six hours of primary system failure.

    2. The PKI CA directory system shall be deployed to provide 24 hour, 365 day per year availability.

    3. The PKI PMO shall implement features to provide high levels of directory reliability within the scope of its control.

  2. In the case of a disaster damaging or rendering all CA equipment inoperative, the PKI Program Team shall re-establish affected CA operations as quickly as possible, giving priority to the ability to revoke certificates, regardless of type or user.

    1. For the TRCA, this will require secure out-of-band distribution of the new certificate as well as issuance of new cross certificates, subordinate CA certificates, and Subscriber certificates.

  3. The PMA shall, at the earliest feasible time, securely advise the FPKIPA and all of its member entities in the event of a disaster where the TRCA installations are physically damaged and all copies of the TRCA’ signature keys are destroyed.

    1. Relying Parties may decide of their own volition whether to continue to use certificates signed with the destroyed private key pending reestablishment of TRCA operation with new certificates.

  4. In the case of a disaster causing physical damage to a subordinate CA installation and resulting in destruction of all copies of the CA signature key, the subordinate CA shall request revocation of its certificates.

    1. The PKI Program Team will then completely rebuild the CA installation by reestablishing the CA equipment, generating new private and public keys, be re-certified, and re-issue all cross certificates.

    2. Finally, all Subscriber certificates shall be re-issued.

    3. Relying parties may make a judgment to continue to use certificates signed with the destroyed private key in order to meet urgent operational requirements.

    4. In any event, the PMA shall securely notify all appropriate authorities (e.g., the FPKIPA, FPKI Management Authority,, cross-certified CAs, etc.) of the situation at the earliest feasible time in accordance with applicable MOAs and any other contractual agreements.

  5. If a CA’s signature keys are compromised, lost, or destroyed—such that compromise is possible even though uncertain—the PKI PMO shall cause an investigation to be conducted and report to the PMA concerning the cause of the compromise or loss and what measures have been taken to prevent recurrence.

    1. The PMA, in turn, shall notify the appropriate authorities in accordance with applicable MOAs and any other contractual agreements.

CA and RA Termination

  1. In the event of termination of the TRCA operation, certificates signed by the TRCA shall be revoked and the Treasury PMA will advise entities that have entered into MOAs with Treasury’s PKI that the TRCA operation has terminated so they may revoke certificates they have issued to the TRCA.

    1. Prior to TRCA termination, the PKI PMO shall provide all archived data to an archival facility.

    2. CMAs shall give cross-certified entities as much advance notice as circumstances permit, and attempt to provide alternative sources of interoperation in the event the supporting TRCA is terminated.

  2. In the case of subordinate CAs, if the termination is for convenience, contract expiration, reorganization, or other non-security related reason, and provisions have been made to continue compromise recovery, compliance and security audit, archive, and data recovery services, then neither the terminated CA’s certificate, nor certificates signed by that CA, need to be revoked.

    1. If provisions for maintaining these services cannot be made, then the CA termination will be handled as a CA compromise.

    2. Before termination, the PMA shall securely notify all appropriate authorities (e.g., the FPKI Management Authority, cross-certified CAs, etc.) of the situation at the earliest feasible time in accordance with applicable MOAs and any other contractual agreements.

Technical Security Controls

  1. The IRS shall implement technical security controls and ensure the design of information systems that process, store, or transmit all information include, at a minimum, the technical security requirements discussed in this IRM and IRM 10.8.1.

  2. The IRS shall implement technical security controls used by the issuing CA to protect its cryptographic keys and activation data (e.g., PINs, passwords, or manually held key shares).

Key Pair Generation and Installation

  1. This policy does not preclude any source of key generated in accordance with the stipulations of this policy and local security requirements.

Key Pair Generation
  1. A private key shall not appear outside of the module in which generated unless encrypted for local transmission or for processing or storage by a key recovery mechanism.

CA Key Pair Generation
  1. The Treasury TRCA, subordinate CAs, and OCSPs shall generate cryptographic keying material used to sign certificates, CRLs or status information in FIPS 140 validated cryptographic modules.

    1. CA cryptographic modules shall meet or exceed FIPS 140 Security Level 3.

    2. Multiparty control is required for CA key pair generation.

  2. The Treasury Root and subordinate CAs shall document their key generation procedure in their respective CPS, and generate auditable evidence that they followed the documented procedures.

    1. For all levels of assurance, the documentation of the procedure shall provide enough detail to show the use of appropriate role separation.

    2. An independent third party shall validate the process either by witnessing or by examining the signed and documented procedures.

Subscriber Key Pair Generation
  1. The Subscriber, RA, or CA may perform Subscriber key pair generation.

    1. If the CA or RA generates Subscriber key pairs, the procedure shall meet the requirements for key pair delivery.

    2. All key generation shall be performed using a FIPS approved method.

  2. At the High, PIV-I Card Authentication and Medium Hardware assurance levels, the Subscriber, RA, or CA shall generate the Subscriber key pairs in hardware cryptographic modules validated to FIPS 140 Level 2 or above.

    1. For all other assurance levels, the Subscriber, RA, or CA shall use either validated software or hardware cryptographic modules for key generation.

    2. For PIV-I Hardware certificates, to be used for digital signatures and/or authentication, and PIV-I Card Authentication certificates, subscriber key generation shall be performed on hardware tokens that meet the requirements defined in Exhibit 10.8.52-2

Private Key Delivery to Subscriber
  1. If Subscribers generate their own key pairs, then there is no need to deliver private keys, and this section does not apply.

    1. If an Entity other than the Subscriber generates a private key, the CMA shall deliver the key to the Subscriber electronically or in a hardware token from which the private key cannot be extracted in unencrypted form.

    2. Any transmission of a private key over a network shall be encrypted.

  2. In those cases where a PKI CA generates public/private key pairs on behalf of the Subscriber, the CA shall implement mechanisms to ensure that the public/private key pair is securely delivered to the proper Subscriber. The appropriate CPS describes this method.

  3. For High and Medium Hardware assurance, a private key will be generated and must remain within the cryptographic boundary of the cryptographic module.

    1. If the CMA generates the key, then the CMA shall also deliver the key module to the Subscriber.

    2. The Subscriber shall formally acknowledge receipt of the module.

    3. The CMA shall maintain a record of the Subscriber acknowledgement of receipt of the token.

  4. Under no circumstances shall any entity other than the Subscriber have knowledge of private signing keys.

    1. In the case of tokens (e.g., smart cards) the CA shall also implement procedures to ensure that the token is not activated by an unauthorized Entity.

    2. The CMA must send any key management private keys that are to be delivered over a network, encrypted and directly to the Subscriber’s cryptographic module.

  5. In all cases, the following requirements must be met:

    • No one who generates a private signing key for a Subscriber shall retain any copy of the key after delivery of the private key to the Subscriber

    • The private key must be protected from activation, compromise, or modification during the delivery process

    • The Subscriber shall acknowledge receipt of the private key(s), regardless of the delivery means

    • Delivery shall be accomplished in a way that ensures that the correct tokens and activation data are provided to the correct Subscribers

    • For hardware modules, accountability for the location and state of the module must be maintained until the Subscriber accepts possession of it

    • For electronic delivery of private keys, the key material shall be encrypted using a cryptographic algorithm and key size at least as strong as the private key. Activation data shall be delivered using a separate secure means

Public Key Delivery to Certificate Issuer
  1. For PKI CAs operating at the Basic, Medium, Medium Hardware, or High level of assurance, the following requirements apply:

    1. Where key pairs are generated by the Subscriber or RA, the public key and the Subscriber’s identity shall be delivered securely to the CA for certificate issuance.

    2. The delivery mechanism shall bind the Subscriber’s verified identity to the public key. If cryptography is used to achieve this binding, it shall be at least as strong as the CA keys used to sign the certificate. Alternatively, this binding may be accomplished through in-person appearance before the RA, LRA, or trusted agent.

  2. For Rudimentary Assurance, this CP makes no stipulation.

  3. The CMA shall deliver public keys to the certificate issuer in an authenticated manner set forth in the CPS.

CA Public Key Delivery to Relying Parties
  1. When a CA updates its signature key pair, the CA shall distribute the new public key in a secure fashion.

    1. The CA may distribute the new public key in a self-signed certificate, in a key rollover certificate, or in a new CA (e.g., cross) certificate obtained from the issuer(s) of the current CA certificate(s).

  2. TRCA shall make their public keys available for creation and verification of certification trust paths, in the form of a self-signed public-key certificate.

    1. The CA shall deliver this self-signed certificate to Subscribers in a manner commensurate with the security offered by the public key in the certificate.

    2. CAs shall convey self-signed certificates to Relying Parties in a secure fashion to preclude substitution attacks. Such methods include, but are not limited to the following:

      • Loading a self-signed certificate onto tokens delivered to Relying Parties via secure mechanisms

      • Distribution of self-signed certificates through secure out-of-band mechanisms

      • Comparison of certificate hashes against trusted certificate hashes 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)

      • Downloading certificates from web sites secured with a currently valid certificate of equal or greater assurance level than the certificate downloaded

  3. The CA shall sign the key rollover certificates with the CA’s current private key, so secure distribution is not required.

Key Sizes
  1. The key size requirements set forth in this section apply to both the CA signing key pair and the subscriber key pair.

    1. Treasury Subscriber certificates issued for assurance levels Rudimentary through Medium, and that expire on or before December 31, 2010 shall use at least 1024 bit RSA, DSA or Diffie Hellman (DH) and Secure Hash Algorithm version 1 (SHA-1 or better) in accordance with FIPS 186.

    2. Subscriber certificates issued under id-fpki-common-policy shall comply with Federal PKI Common Policy Framework.

  2. For CAs that distribute self-signed certificates to Relying Parties, the CA’s subject public keys in such certificates shall be at least 2048 bits for RSA, or at least 224 bits for Elliptic Curve Digital Signature Algorithm (ECDSA).

    1. Public keys in all self-signed certificates generated after 12/31/2010 that expire after 12/31/2030 shall be at least 3072 bits for RSA, or at least 256 bits for ECDSA.

  3. CAs that generate certificates and CRLs under this policy shall use signature keys of at least 1024 bits for RSA or DSA, and at least 160 bits for ECDSA.

    1. Certificates that expire after 12/31/2010 shall be generated with at least 2048 bit RSA key or at least 224 bits for ECDSA.

    2. All certificates, except self-signed certificates, that expire after 12/31/2030 shall be signed with keys of at least 3072 bits for RSA or at least 256 bits for EDCSA.

  4. CA that generates certificates and CRLs shall use a FIPS 140-2 compliant hash algorithm when generating digital signatures.

    1. RSA signatures on certificates and CRLs that are issued after December 31, 2030 shall be generated using SHA-256.

  5. Where implemented, certificate status server (CSS) shall sign responses using the same signature algorithm, key size, and hash algorithm used by the CA to sign CRLs.

    1. After December 31, 2010, for Medium and High Assurance, OCSP responders that generate signatures on OCSP responses using SHA-1 shall only provide signed responses that are pre-produced (i.e., any signed response that is provided to an OCSP client shall have been signed before the OCSP responder received the request from the client).

  6. End-entity certificates shall contain public keys that are at least 1024 bits for RSA, DSA, or Diffie-Hellman, or 160 bits for elliptic curve algorithms. The following special conditions also apply:

    1. End-entity certificates that expire after 12/31/2030 shall contain public keys that are at least 3072 bits for RSA or DSA, or 256 bits for elliptic curve algorithms.

    2. End-entity certificates that include a keyUsage extension asserting only the digitalSignature bit, and that expire on or after 12/31/2013 shall contain public keys that are at least 2048 bits for RSA or Diffie-Hellman, or 224 bits for elliptic curve algorithms.

    3. End-entity certificates that do not include a keyUsage extension or that include a keyUsage extension that asserts the nonRepudiation, keyEncipherment, dataEncipherment, or keyAgreement bit, and that expire on or after 12/31/2010 shall contain public keys that are at least 2048 bits for RSA or Diffie-Hellman, or 224 bits for elliptic curve algorithms.

  7. Use of Transport Layer Security (TLS) or another protocol providing similar security to accomplish any of the requirements of this CP shall require at a minimum Advanced Encryption Standard (AES) (128 bits) or equivalent for the symmetric key, and at least 1024 bit RSA or 163 bit elliptic curve keys through 12/31/10 for asymmetric keys issued under assurance levels Rudimentary through MediumHardware and 2048 bit RSA or equivalent for the asymmetric keys issued under High assurance and on or after 12/31/2010 at least 2048 bit RSA or 224 bit elliptic curve keys will be utilized by the protocol for all assurance levels.

    1. Use of TLS or another protocol providing similar security to accomplish any of the requirements of this CP shall be in accordance with IRM 10.8.1,.

Public Key Parameters Generation and Quality Checking
  1. PKI CAs shall generate public key parameters for signature algorithms defined in the Digital Signature Standard (DSS) in accordance with FIPS 186-1 Digital Signature Standard.

  2. The CMA shall generate public key parameters in accordance with the standard that defines the cryptographic algorithm in which the parameters are used.

Key Usage Purposes (as per X.509 v3 key usage field)
  1. CAs shall certify public keys bound into certificates for use in signing or encrypting, but not both, except as specified below.

    1. The key usage extension in the X.509 certificate determines the use of a specific key.

    2. With the exception of the self-signed TRCA certificate, all certificates must have a populated key usage extension as defined in the X.509 key usage extensions.

    3. The key usage extension in the X.509 certificate determines the use of a specific key.

    4. Subordinate CAs shall set at least two key usage bits: cRLSign and keyCertSign.

    5. Where the subject signs OCSP responses, the certificate may also set the digitalSignature and/or nonRepudiation bits.

  2. Subscriber certificates shall assert key usages based on the intended application of the key pair.

    1. Subscriber certificates to be used for digital signatures (including authentication) shall set the digitalSignature and/or nonRepudiation bits. However, a public-key certificate with key usage set for digitalSignature and keyEncipherment shall not also set for nonRepudiation.

    2. Certificates issued only for Authentication shall only set the digitalSignature bit.

    3. Certificates to be used for key or data encryption shall set the keyEncipherment and/or dataEncipherment bits.

    4. Certificates used for key encryption shall set the keyAgreement bit if the algorithm is DH and shall set the keyEncipherment bit if the algorithm is RSA.

      Note:

      This restriction does not prohibit use of protocols that provide authenticated connections using key management certificates.

    5. Certificates to be used for key agreement shall set the keyAgreement bit.

  3. Rudimentary, Basic, and Medium Assurance Level certificates may include a single key for use with encryption and signature in support of legacy applications.

    1. PKI CAs shall generate and manage such dual-use certificates in accordance with their respective signature certificate requirements, except where otherwise noted in this CP. Such dual-use certificates shall never assert the non-repudiation key usage bit, and shall not be used for authenticating data that will be verified on the basis of the dual-use certificate at a future time.

    2. CAs shall issue Subscribers at all levels of assurance two key pairs; one for key management and one for digital signature, except where operationally necessary (e.g., VPN and web site/application access control). This restriction does not prohibit use of protocols that provide authenticated connections using key management certificates.

Private Key Protection and Cryptographic Module Engineering Controls

  1. The relevant standard for cryptographic modules is FIPS 140, Security Requirements for Cryptographic Modules.

Cryptographic Module Standards and Controls
  1. The following table specifies the minimum level of FIPS evaluation a cryptographic module shall complete for use in the PKI:

    Assurance Level CA & CSS Subscriber RA
    Rudimentary Level 1 (Hardware or Software) N/A Level 1 (Hardware or Software)
    Basic Level 2 (Hardware or Software) Level 1 (Hardware or Software) Level 1 (Hardware or Software)
    Medium (all policies) Level 2 (Hardware) Level 1 (Hardware or Software) Level 2 (Hardware)
    PIV-I Card Authentication Level 2 (Hardware) Level 2 (Hardware) Level 2 (Hardware)
    Medium Hardware Level 2 (Hardware) Level 2 (Hardware) Level 2 (Hardware)
    High Level 3 (Hardware) Level 2 (Hardware) Level 2 (Hardware)
  2. The TRCA require Level 3 cryptographic modules as defined by FIPS 140. The TRCA may use a higher level if available or desired.

    1. Subordinate CAs shall sign certificates using a cryptographic module that meets Level 3 or higher.

  3. The Treasury CAs requires that all Subscribers issued certificates under id-fpki-common-hardware, id-fpki-common-devicesHardware, id-fpki-common-authentication, or id-fpki-common-cardAuth use a FIPS Level 2 or higher validated hardware cryptographic module for all private key operations.

  4. All cryptographic modules shall operate such that the private asymmetric cryptographic keys never output in plain text.

    1. No private key shall appear unencrypted outside the CA equipment.

    2. No one shall have access to a private signing key but the subject of the corresponding certificate.

Private Key Multi-Person Control
  1. Use of Treasury CAs private signing keys shall require action by multiple persons.

    1. Use of subordinate CAs private signing keys shall require action by multiple persons at Medium, Medium Hardware, and High Assurance.

  2. Access to Medium, PIV-I Card Authentication, Medium Hardware, and High CA cryptographic modules shall be under two-person control.

    1. CMAs shall also back up key management and signature keys in multiple cryptographic modules under two-person control and ensure the security audit records the CMA backup actions.

    2. Only a CA may reproduce private keys in multiple cryptographic modules on behalf of Subscribers.

    3. Neither RAs nor Subscribers shall duplicate private keys.

    4. The CMA may backup Treasury CAs signature keys only under two-person control.

    5. The CMA shall maintain a list of names of the parties used for two-person control.

Private Key Escrow
  1. The following private key escrow requirements apply.

Escrow of TRCA and Subordinate CA Private Signature Keys
  1. Under no circumstances shall TRCA or subordinate CA signature keys be used to sign certificates or CRLs be escrowed.

Escrow of CA Encryption Keys
  1. TRCA shall not perform any encryption key recovery functions involving encryption keys issued to subordinate CAs. However, if encryption key pairs need to be issued by the TRCA covering repository system access or for other purposes, the PMA shall publish applicable requirements for that purpose.

  2. Subordinate CAs may escrow any encryption keys whose certificates do not contain the digital Signature key usage bit for the purpose of data recovery. The applicable CA CPS shall describe this method.

  3. If a device has a separate key management key certificate, the encryption private key may be escrowed.

Escrow of Subscriber Private Signature Keys
  1. Subscriber private signature keys shall not be escrowed.

  2. If a device has a separate encryption key pair, the encryption private key may be escrowed.

Escrow of Subscriber Private Encryption and Dual Use Keys
  1. Subscriber private dual use keys shall not be escrowed.

    1. Subordinate CAs may escrow any encryption keys whose certificates do not also contain the digital Signature key usage bit for the purpose of data recovery.

    2. Keys in escrow shall be protected using cryptography validated to the same FIPS level as the CA.

    3. Recovery of keys in escrow shall be protected using the same level of strength of technical controls present at the time of initial issuance.

Private Key Backup
  1. This section addresses backup requirements for:

    • TRCA and Subordinate CA Private Signature Keys

    • Subscriber Private Signature Key

    • Subscriber Key Management Private Keys

    • CSS Private Key

Backup of TRCA and Subordinate CA Private Signature Keys
  1. The TRCA shall back up private signature keys under multi-person control.

    1. Backup of subordinate CA private signature keys is required to facilitate disaster recovery.

    2. Where required, subordinate CAs shall back up private signature keys under multi-person control.

  2. The CMA shall create backups of the TRCA and subordinate CA private signature keys on separate cryptographic modules.

    1. The CMA shall create these keys under the same multi-person control as the original signature key. Such backups shall create only a single copy of the TRCA and subordinate CA signature key at the primary CA location.

    2. The CA shall store at least one copy of each TRCA and each subordinate CA private signature key at the off-site backup location.

    3. The CMA shall account for and protect all copies of CA private signature keys in the same manner as the original.

  3. All backup copies of CA private signature keys shall reside solely on cryptographic modules of equal strength and validation level as the primary.

Backup of Subscriber Private Signature Key
  1. The backup, copying, or escrow of Subscriber private signature keys is prohibited.

  2. At the Medium Hardware and High assurance levels, Subscriber private signature keys shall not be backed up or copied.

  3. Backed up subscriber private signature keys shall t be held under the subscriber’s control.

    1. Backed up subscriber private signature keys shall not be stored in plaintext form outside the cryptographic module.

    2. Storage shall ensure security controls consistent with the protection provided by the subscriber’s cryptographic module.

Backup of Subscriber Key Management Private Keys
  1. Subordinate CAs may backup Subscriber key management private keys.

  2. Subordinate CAs shall encrypt backed up Subscriber key management private keys using an algorithm of a strength consistent with the private key being stored; or stored in a cryptographic module validated at FIPS 140 Level 2.

Backup of Certificate Status Servers (CSS) Private Key
  1. CMAs may backup CSS private keys. If backed up, the CMA shall account for and protect all copies in the same manner as the original.

Backup of Device Private Keys
  1. Device private keys may be backed up or copied, but shall t be held under the control of the device’s human sponsor or other authorized administrator.

    1. Backed up device private keys shall not be stored in plaintext form outside the cryptographic module.

    2. Storage shall ensure security controls consistent with the protection provided by the device’s cryptographic module.

Private Key Archival
  1. Treasury CAs shall not escrow or archive private signature keys.

    1. Subordinate CAs may escrow or archive private encryption keys (key management or key transport).

Private Key Transfer into or from a Cryptographic Module
  1. TRCA and subordinate CA private keys shall be generated by and remain within a cryptographic module. At no time shall the CA private key exist in plain text outside the cryptographic module. The CMA may backup CA private keys.

  2. Subscriber private keys shall be generated by and remain within a cryptographic module.

    1. In the event that a CMA transports a private key from one cryptographic module to another, the private key shall be encrypted during transport.

    2. Private keys shall never exist in plain text form outside the cryptographic module boundary.

  3. The system shall protect private or symmetric keys used to encrypt other private keys for transport, from disclosure.

    1. The protection of these keys shallbe commensurate with that provided the data protected by the certificate associated with the private key.

Private Key Storage on Cryptographic Module
  1. This CP makes no further stipulation beyond that specified in FIPS 140.

Requirements forActivating Private Keys
  1. For the private keys of the TRCA and subordinate CAs that operate at the Medium, Medium Hardware, or High level of assurance and PIV-I Content Signing keys, signing key activation requires multiparty control.

  2. Subscribers shall use pass-phrases, PINS, biometric data, or other mechanisms of equivalent authentication robustness to authenticate to the cryptographic module before activating any private key in the cryptographic module for certificates at all levels of assurance.

    1. The CMA shall distribute activation data in person, or by an accountable method to the Subscribers separately from the cryptographic modules that they activate.

    2. Subscribers shall protect the entry of activation data from disclosure.

  3. For certificates issued under id-fpki-common-devices and id-fpki-common-devicesHardware, the device may be configured to activate its private key without requiring its human sponsor or authorized administrator to authenticate to the cryptographic token, provided that appropriate physical and logical access controls are implemented for the device and its cryptographic token.

    1. The strength of the security controls shall be commensurate with the level of threat in the device’s environment, and shall protect the device’s hardware, software, and the cryptographic token and its activation data from compromise.

Requirements for Deactivating Private Keys
  1. The CMA shall remove TRCA and subordinate CA cryptographic modules and store them in a secure container when not in use.

  2. Subscribers shall not leave activated cryptographic modules unattended or otherwise open to unauthorized access.

    1. When not in active use, they shall be deactivated, (e.g. via a manual logout procedure, by removing the cryptographic module, or automatically after a period of inactivity) as defined in the applicable CA CPS.

    2. Subscribers shall remove and secure (e.g., under their personal control or in an approved security container) cryptographic modules when not in use.

Requirements for Destroying Private Keys
  1. Individuals in trusted roles shall destroy CA, RA, and status server (e.g., OCSP server) private signature keys when no longer needed.

    1. Subscriber private signature keys shall be destroyed when no longer needed, or when the certificates to which they correspond expire or are revoked.

    2. For software cryptographic modules, this can be overwriting the data using a Treasury-approved utility and procedures.

    3. For hardware cryptographic modules, this will likely be executing a “zeroize” command.

    Note:

    Private key destruction should not require physical destruction of hardware.

  2. PKI Sponsors shall request the assistance of the LRA, RA, or CMA with the overwriting of software cryptographic modules used by hardware components and applications.

    1. Individual Subscribers shall take hardware tokens to the LRA, RA, or CMA for zeroizing to prevent accidental destruction of Access Control System or other resident data kept on the Smart ID Card/PIV Card.

Other Aspects of Key Management

  1. A single dual-use (digital signature and encryption) key pair is prohibited for Medium Hardware and High Assurance implementations, but may be issued on a case-by-case basis for Rudimentary, Basic, and Medium Assurance levels. Such dual-use key pairs shall be issued only in support of legacy applications.

    1. Human Subscribers shall typically have one key-pair for digital signature, and a separate key-pair for encryption.

    2. A Subscriber’s digital signature key-pair shall never be escrowed, archived, or backed-up, to maintain technical non-repudiation of transactions.

    3. For business continuity reasons, the CA may escrow, archive, or back-up encryption key-pairs.

    4. For additional requirements, see IRM 10.8.1.

Public Key Archival
  1. The public key is archived as part of the certificate archival.

Certificate Operational Periods/Key Usage Periods
  1. CAs that distribute their self-signed certificates for use as trust anchors shall limit the use of its private keys to a maximum of 20 years; the self-signed certificates shall have a lifetime not to exceed 37 years.

    1. For all other CAs, the CA shall limit the use of its private keys to a maximum of six years for Subscriber certificates and ten years for CRL signing and OCSP responder certificates.

    2. Code and content signers shall use their private keys for a maximum of three years; the lifetime of the associated public keys shall not exceed eight years.

    3. Subscriber signature private keys and certificates shall have a maximum lifetime of three years.

    4. Signatures generated with these keys may be validated after expiration of the certificate.

    5. Subscriber key management certificates shall have a maximum lifetime of 3 years; use of Subscriber key management private keys is unrestricted.

    6. All restrictions on private-key usage periods are enforced procedurally.

  2. For subscriber public keys in certificates that assert the id-PIV-content-signing OID in the extended key usage extension refer to the Common Policy for future detail.

  3. The validity period of the Subscriber certificate must not exceed the routine rekey Identity Requirements or Key Changeover Requirements.

Activation Data

  1. Activation data refers to data values other than keys that are required to operate cryptographic modules and need to be protected (e.g., a PIN, a passphrase, or a manually held key share).

Activation Data Generation and Installation
  1. The activation data used to unlock TRCA, subordinate CA or Subscriber private keys, in conjunction with any other access control, shall have an appropriate level of strength for the keys or data protected.

    1. If the activation data is transmitted, it shall be via an appropriately protected channel, and separate in time and place from the associated cryptographic module.

    2. Where the TRCA or a subordinate CA uses passwords as activation data for the CA signing key, the CMA shall change the activation data upon CA rekey at a minimum.

  2. The activation data used by Subscribers to unlock private keys shall have an appropriate level of strength for the keys or data protected.

    1. Subscribers shall use pass-phrases, PINS, biometric data, or other mechanisms of equivalent authentication robustness to protect access to use of a private key for certificates at all other levels of assurance.

Activation Data Protection
  1. Subscribers shall protect data used to unlock private keys from disclosure by a combination of cryptographic and physical access control mechanisms. Activation data shall be:

    1. Memorized

    2. Biometric in nature

    3. Recorded and secured at the level of assurance associated with the activation of the cryptographic module, and shall not be stored with the cryptographic module

  2. The protection mechanism shall include a facility to temporarily lock the account, or terminate the application, after a predetermined number of failed login attempts as set forth in the respective CPS.

  3. Subscribers shall never share activation data for private keys associated with certificates asserting individual identities.

    1. PKI Sponsors shall restrict activation data for private keys associated with certificates asserting group, organizational, non-human component identities to those in the organization authorized to use the private keys.

  4. If the activation data is transmitted, it shall be via a channel with appropriate protection, and distinct in time and place from the associated cryptographic module.

    1. As part of the delivery method, users will sign and return a delivery receipt.

    2. In addition, users will also receive (and acknowledge) a user advisory statement to help to understand responsibilities for use and control of the cryptographic module.

Other Aspects of Activation Data
  1. When operating at a Medium Hardware or High assurance level, RAs shall change their cryptographic module activation data not less than once every six months.

Computer Security Controls

  1. The computer security control requirements in the following subsections apply.

Specific Computer Security Technical Requirements
  1. The computer security functions listed below are required for all PKI CAs.

    Note:

    These functions may be provided by the operating system, or through a combination of operating system, software, and physical safeguards.

    1. CAs and ancillary parts shall include the following functionality:

      • Require authenticated logins

      • Provide Discretionary Access Control

      • Provide a security audit capability

      • Restrict access control to PKI 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 recovery mechanisms for keys and the CA system

      • Enforce domain integrity boundaries for security critical processes and provide process isolation, operating system self-protection, and residual information protection

    2. Subordinate CAs and ancillary parts shall include the following functionality:

      • Authenticate the identity of Subscribers before permitting access to the system or applications

      • Manage privileges of Subscribers to limit Subscribers to their assigned roles

      • Generate and archive audit records for all transactions

      • Enforce domain integrity boundaries for security critical processes

      • Support recovery from key or system failure

  2. The computer security functions listed below are required for CSS operating under this policy:

    • Authenticate the identity of users before permitting access to the system or applications

    • Manage privileges of users to limit users to their assigned roles

    • Enforce domain integrity boundaries for security critical processes and provide process isolation, operating system self-protection, and residual information protection

    • Support recovery from key or system failure

  3. The computer security functions listed below are required for remote workstations used to administer the CAs:

    • Authenticate the identity of users before permitting access to the system or applications

    • Manage privileges of users to limit users to their assigned roles

    • Generate and archive audit records for all transactions

    • Enforce domain integrity boundaries for security critical processes

    • Support recovery from key or system failure

  4. All communications between any PKI trusted role and the CA shall be authenticated and protected from modification.

Computer Security Rating
  1. When evaluated platforms host CA equipment in support of computer security assurance requirements, then the system (hardware, software, and operating system) shall operate only in an evaluated and certified configuration.

    1. At a minimum, such platforms shall use the same version of the computer operating system as received the evaluation rating.

Life-Cycle Security Controls

  1. PKI systems shall comply with IRM 10.8.1 requirements for System and Service Acquisition.

System Development Controls
  1. The System Development Controls for the TRCA and subordinate CAs at the Basic Assurance level and above are as follows:

    1. The CAs shall use software designed and developed under a formal, documented development methodology.

    2. The CA shall use hardware and software specifically developed in a controlled environment; and the CMA shall define and document the development process which shall include software verification and validation requirements. This requirement does not apply to commercial off-the-shelf (COTS) hardware or software.

    3. Where developers use open source software, the developer/vendor shall demonstrate that security requirements were achieved through software verification & validation and structured development/life-cycle management.

    4. The PKI Program Team shall procure hardware and software to operate the CA in a fashion to reduce the likelihood of tampering with any particular component (e.g., by ensuring the random selection of material at time of purchase).

    5. The PKI Program Team shall dedicate CA hardware and software to performing one task: operation and management of the CA. There shall be no other applications, hardware devices, network connections, or component software installed that are not part of the CA operation.

    6. The PKI Program Team shall take proper care to prevent malicious software from being loaded onto the CA equipment. RA hardware and software shall be similarly limited and scanned for malicious code on first use and continuously thereafter.

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

Security Management Controls
  1. The PKI Program Team shall document and control the configuration of all CA systems as well as any modifications and upgrades.

  2. There shall be a mechanism for detecting unauthorized modification to the CA software or configuration.

  3. The PKI Program Team shall use IRS’s formal configuration management methodology, through the IT-CCB, for installation and ongoing maintenance of the IRS PKI CA systems.

  4. The PKI OA shall verify the CA software, when first loaded, as that supplied from the vendor, with no modifications, and the version intended for use.

  5. The operator shall verify the integrity of CA software at least weekly.

Lifecycle Security Ratings
  1. This CP makes no stipulation.

Network Security Controls

  1. The PKI CMAs shall employ network security controls to protect the TRCA, the TRCA certificate repositories, and Certificate Status Servers.

    1. The CMA shall assure that all CMA equipment is protected (e.g., network guard, firewall, and/or filtering router) against known network attacks.

    2. The PKI CA system administrator shall turn off all unused network ports and services on the CAs, and ensure that similar measures are taken on all guards, routers, and firewalls.

    3. Any network software present on CMA equipment shall be necessary to the functioning of the CMA application.

  2. Subordinate CAs, RAs, supporting directories, remote workstations used to administer the CAs, and certificate status servers shall employ the same network security controls required of the TRCA, appropriate to their configuration.

    1. The CA shall establish connection with a remote workstation used to administer the CA only after successful authentication of the remote workstation at a level of assurance commensurate with that of the CA

    2. The Treasury Border Directory shall be connected to the Internet and provide continuous service (except, when necessary, for brief periods of maintenance or backup). Any boundary control devices used to protect the Border directory or any CA local area network shall deny all but the necessary services to the PKI equipment even if those services are enabled for other devices on the network

    3. All boundary control devices shall only have user accounts required to administer the boundary control protections. The TRCA CPS shall define the respective network protocols and mechanisms required for operation of the Border Directory.

    4. The TRCA is operated off-line; CRLs and ARLs are posted manually to the directories

    5. See IRM 10.8.1 and IRM 10.8.55 for any additional IRS requirements.

Certificate, CARL/CRL, and OCSP Profiles Format

  1. The profile format requirements in the following subsections apply.

Certificate Profile

  1. The FPKI PROF defines the Certificate Profile.

    1. The certificate profile that will be used conforms to the FPKI Certificate and CRL profiles as defined in the current Federal Public Key Infrastructure (PKI) X.509 Certificate and CRL Extensions Profile [FPKI-Prof].

Version Numbers
  1. This policy uses X.509 Version 3 certificates exclusively.

  2. The TRCA and subordinate CAs shall issue X.509 v3 certificates.

Certificate Extensions
  1. For all CAs, use of standard certificate extensions shall comply with [RFC 3280].

    1. Certificates issued by the TRCA shall comply with Federal Public Key Infrastructure X.509 Certificate and CRL Extensions Profile [FPKI-Prof].

    2. Certificates issued by subordinate CAs operating at High, Medium Hardware, and/or Medium Assurance shall also comply with [FPKI-Prof].

    3. PIV Authentication Certificates issued by a subordinate CA under this policy may conform to the X.509 CRL Extensions Profile for the SSP Program [CCP-PROF] instead.

  2. Entity CAs that issue PIV-I Certificates shall comply with [PIV-I Profile].

    Note:

    For Entity CAs that issue PIV-I certificates, the associated CSS certificates will also comply with [PIV-I Profile].

  3. Treasury certificates shall not include critical private extensions. Subscriber certificates issued by subordinate CAs may include critical private extensions so long as interoperability within the community of use is not impaired. For PIV Auth certificates, the [CCP-Prof] defines the rules for the inclusion, assignment of value, and processing of extensions.

Algorithm Object Identifiers
  1. Certificates issued under this policy shall use one of the following OIDs for identifying the signature algorithm:

    id-dsa-with-sha1 { iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3 }
    sha-1WithRSAEncryption { iso(1) member-body(2) us(840) rsadis(113549) pkcs-1(1) 5 }
    sha256WithRSAEncryption { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 }
    id-RSASSA-PSS { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 }
    ecdsa-with-SHA1 { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1 }
    Ecdsa-with-SH254 {iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2 (3) 1}
    ecdsa-with-SH256 { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2 (3) 2 }
    ecdsa-with-SHA384 { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 }
    ecdsa-with-SHA512 { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }
  2. PIV Authorities shall sign certificates containing keys generated for use with OID id-dsa-with sha-256, and for keys generated for use with RSA with sha-256WithRSAEncryption.

    Note:

    Treasury will initiate implementation of SHA-256 for all certificates when this level of encryption is supported by the operating system.

  3. Where certificates are signed using RSA with PSS padding, the OID is independent of the hash algorithm; the hash algorithm is specified as a parameter.

    1. RSA signatures with PSS padding may use the hash algorithms and OIDs specified below:

      id-sha256 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 }
      id-sha512 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3 }
  4. Certificates under this CP shall use the following OIDs for identifying the algorithm for which the subject key was generated:

    id-dsa {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1}
    id-ecPublicKey {iso(1) member-body(2) us(840) ansi-x9-62(10045) id-publicKeyType (2) 1}
    RsaEncryption {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}
    Dhpublicnumber {iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1}
  5. Where non-CA certificates issued on behalf of federal agencies contain an elliptic curve public key, the parameters shall be specified as one of the following named curves:

    id-dsa {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1}
    ansip192r1 { iso(1) member-body(2) us(840) 10045 curves(3) prime(1) 1 }
    ansit163k1 { iso(1) identified-organization(3) certicom(132) curve(0) 1 }
    ansit163r2 { iso(1) identified-organization(3) certicom(132) curve(0) 15 }
    ansip224r1 { iso(1) identified-organization(3) certicom(132) curve(0) 33 }
    ansit233k1 { iso(1) identified-organization(3) certicom(132) curve(0) 26 }
    ansit233r1 { iso(1) identified-organization(3) certicom(132) curve(0) 27 }
    ansip256r1 { iso(1) member-body(2) us(840) 10045 curves(3) prime(1) 7 }
    ansit283k1 { iso(1) identified-organization(3) certicom(132) curve(0) 16 }
    ansit283r1 { iso(1) identified-organization(3) certicom(132) curve(0) 17 }
    ansip384r1 { iso(1) identified-organization(3) certicom(132) curve(0) 34 }
    ansit409k1 { iso(1) identified-organization(3) certicom(132) curve(0) 36 }
    ansit409r1 { iso(1) identified-organization(3) certicom(132) curve(0) 37 }
    ansip521r1 { iso(1) identified-organization(3) certicom(132) curve(0) 35 }
    ansit571k1 { iso(1) identified-organization(3) certicom(132) curve(0) 38 }
    ansit571r1 { iso(1) identified-organization(3) certicom(132) curve(0) 39 }
Name Forms
  1. In general, the TCA shall use the X.500 DN in subject and issuer fields of the base certificate throughout Treasury.

    1. The CMA shall populate the subject and issuer fields of the base certificate with an X.500 Distinguished Name.

      Note:

      The subject alternative name extension shall be present and include the pivFASC-N name type in certificates issued at the Card Authentication level of assurance.

  2. Distinguished names shall be composed of standard attribute types, such as those identified in [RFC3280].

Name Constraints
  1. Medium, Medium Hardware, and High assurance CA certificates issued shall impose name constraints and path length constraints as required by FPKI PROF.

Certificate Policy Object Identifier
  1. Certificates issued under this policy shall assert the OID appropriate to the level of assurance in which issued, as defined throughout this policy.

    1. Additionally, a certificate may assert the OID of all lesser assurance levels.

Usage of Policy Constraints Extension
  1. The CAs may assert policy contraints in CA certificates..

Policy Qualifiers Syntax and Semantics
  1. Certificates issued under this policy shall not contain policy qualifiers.

Processing Semantics for the Critical Certificate Policy Extension
  1. Processing semantics for any critical Certificate Policy extensions issued to Subscribers shall conform to FPKI PROF.

CRL Profile

  1. The following CRL policy requirements apply.

Version Numbers
  1. CRLs issued under this policy shall assert Version 2 described in the X.509 standard ISO 9594-8.

    1. The CRL shall always populate the nextUpdate field.

CRL Entry Extensions
  1. Detailed CRL profiles covering the use of each extension are available in FPKI PROF.

    1. For the Treasury Root and subordinate CAs, CRL extensions shall conform to [FPKI-PROF].

Online Certificate Status Profile (OSCP)

  1. CSS operating under this policy shall sign responses using algorithms designated for CRL signing.

    1. CSS shall be able to process SHA-1 hashes when included in the CertID field and the keyHash in the responderID field.

Version Number and Entry Extensions
  1. CSS operating under this policy shall use OCSP version 1.

OSCP Extensions
  1. CSS operating under this policy shall not use critical OCSP extensions.

Compliance Audits and Other Assessments

  1. The PMA shall have a compliance audit mechanism in place to ensure implementation and enforcement of the requirements of this CP and the applicable CPS for subordinate CAs.

    Note:

    This specification does not impose a requirement for any particular assessment methodology.

Frequency of Audits or Assessments

  1. All CAs, CMSs, and RAs shall be subject to a compliance audit at the following frequencies:

    1. At a minimum of once per year for High, Medium Hardware and Medium Assurance levels.

    2. At a minimum of once every two (2) yearsfor Basic Assurance level.

    3. There is no audit requirement for Rudimentary Assurance level.

  2. Where a status server is specified in certificates issued by a CA, the status server shall be subject to the same periodic compliance audit requirements as the corresponding CA.

    Note:

    As an alternative to a full annual compliance audit against the entire CPS, the compliance audit of CAs and RAs may be carried out in accordance with the requirements as specified in the Triennial Audit Guidance document located at http://www.idmanagement.gov/fpkipa/.

Identity and Qualifications of Assessor

  1. The auditors shall demonstrate competence in the field of compliance audits, and must be thoroughly familiar with this policy and the appropriate CPS, as well as those of the FBCA and Common Policy Framework CP.

    1. The compliance auditor shall perform PKI or Information System compliance audits as a regular ongoing business activity.

  2. In addition to the previous requirements, the auditor shall be a certified information system auditor (CISA) or IT security specialist and PKI subject matter specialist who can offer input regarding acceptable risks, mitigation strategies, and industry best practices.

  3. Self assessments shall be performed by an assessor that satisfies the qualifications listed for an Auditor.

    1. The assessor may also hold an Auditor trusted role position within the TCA.

Assessor’s Relationship to Assessed Entity

  1. Either the compliance auditor shall be a private firm, that is independent from the Entity being audited (CAs and RAs), or it shall be sufficiently organizationally separated from that Entity to provide an unbiased, independent evaluation. An example of the latter situation may be an Agency inspector general.

    1. The PMA shall determine whether a compliance auditor meets this requirement.

  2. The PKI PMO shall identify and recommend such auditors to the PMA. The PMA shall, in turn, approve the selection.

Topics Covered by Assessment

  1. The compliance audit of the TRCA shall verify that the PKI PMO is implementing all provisions of the CPS approved by the PMA consistent with this CP.

    1. The audit shall also verify that the PKI PMO is implementing the relevant provisions of the MOAs between Treasury and the FPKIPA.

  2. The purpose of a compliance audit shall be to verify that the TRCA and the CMAs have in place a system to assure the quality of the CMA services that it provides, and that it complies with all of the requirements of Treasury’s CP and the CPS for that Entity.

    1. All aspects of the CMA operation as specified in its CPS shall be subject to compliance audit inspections.

    2. In addition, the compliance audit shall verify that the Treasury PKI is correctly implementing the provisions of the MOA with the FPKIPA..

    3. A full compliance audit for the TRCA or subordinate CAs covers all aspects within the scope identified above.

Actions Taken as a Result of Deficiency

  1. When the compliance auditor finds a discrepancy between a CA or CMA’s operation and the stipulations of this CP, the applicable CPS, and all applicable MOAs, the following actions shall occur:

    1. The compliance auditor shall document the discrepancy and provide a copy to the PKI PMO.

    2. The compliance auditor shall promptly notify the appropriate parties of the discrepancy.

    3. The PKI will propose a remedy, including expected time for completion, to the PKI .

    4. The PKI PMA shall determine what further notifications or actions are necessary to meet the requirements of this CP, the CPS, and any relevant MOAs, and then proceed to make such notifications and take such actions..

    5. The PKI PMA shall determine what further notifications or actions are necessary to meet the requirements of this CP, the CPS, and any relevant MOAs, and then proceed to make such notifications and take such actions without delay. The Treasury PMA may require a special compliance audit to confirm the implementation and effectiveness of the remedy.

Communication Results

  1. The compliance auditor shall report the results of a compliance audit to the PMO and PMA.

    1. The auditor shall also report the results to the audited CMA and its superior CA if applicable.

    2. The PMA shall communicate the audit results and implementation of remedies to the appropriate entities in accordance with established MOAs, MOUs, and contractual agreements.

  2. Upon completion, the PMA shall provide an Audit Compliance Report letter to the Federal PKI Policy Authority.

    1. The report shall identify the versions of the CP and CPS used in the assessment.

    2. Additionally, where necessary, the compliance auditor and/or PKI authorities shall communicate the results as set forth in this policy.

  3. After 30 days, the Audit Compliance Report and identification of corrective measures taken or being taken by the PMO shall be provided to both the PMA and the FPKIPA.

    1. A special compliance audit may be required to confirm the implementation and effectiveness of the remedy.

Other Business and Legal Matters

  1. The other business and legal matters in the following subsections apply.

Fees

  1. The Department currently funds the Treasury Root and subordinate CAs centrally; however, the PMO reserves the right to charge a fee to external Agencies and internal Bureaus in order to operate the Treasury PKI CAs

    1. The CAs will use these fees only to fund operation of the Treasury PKI CAs and fielding of PKI hardware and software beyond normally anticipated requirements (e.g., additional and/or special purpose certificates), based on the recommendation of the PKI PMO and PKI PMA.

Certificate Issuance/Renewal Fees
  1. This CP makes no further stipulation

Certificate Access Fees
  1. This CP makes no further stipulation

Revocation or Status Information Access Fee
  1. This CP makes no further stipulation

Fees for Other Services
  1. This CP makes no further stipulation

Refund Policy
  1. This CP makes no further stipulation

Financial Responsibility

  1. This CP contains no limits on the use of certificates issued by subordinate CAs under this policy, vis-à-vis the protection of financial transactions or information.

    1. Entities (e.g., bureaus, offices, posts, missions, external activities), acting as Relying Parties, shall determine, within their purview, what financial limits if any they wish to impose for certificates used to consummate a transaction; and shall implement applications at an appropriate level of assurance to support those limitations.

    2. The PMA, PKI andPMO and other elements within the IRS assume no financial responsibility or liability for those decisions.

Issuance Coverage
  1. This CP makes no further stipulation

Other Assets
  1. This CP makes no further stipulation

Insurance/Warranty Coverage for End-Entities
  1. This CP makes no further stipulation

Confidentiality of Business Information

  1. PKI CA information not requiring protection shall be made publicly available.

    1. The MOA shall address access to PKI CA information by the Federal PKI Policy Authority.

    2. The respective organization or bureau shall determine public access to IRS information, in accordance with IRS policy and Federal law.

Scope of Confidential Information
  1. A certificate shall only contain relevant information necessary to effect secure transactions with the certificate.

    1. For the purpose of proper administration of the certificates, a CMA may request non-certificate information for use in managing the certificates within an organization (e.g., identifying numbers, business or home addresses and telephone numbers).

    2. The CPS shall explicitly identify any such information.

  2. The CMA shall handle all information stored locally on the CA equipment and not in the repository as sensitive, and restrict access to those with an official need-to-know in order to perform their official duties.

    1. The MOA will address access to IRS information by the FPKIPA.

Information Not Within the Scope of Confidential Information
  1. This CP makes no further stipulation.

Responsibility to Protect Confidential Information
  1. A CMA shall not disclose non-certificate information to any third party unless authorized by this policy, required by U.S. law, U.S. government rule or regulation, or order of a U.S. court of competent jurisdiction.

    1. The PMA shall authenticate any request for release of information.

Privacy of Personal Information

  1. The privacy requirements in the following subsections apply.

Privacy Plan
  1. See IRM 10.8.1 and IRM 10.5.1, Privacy and Information Protection, Privacy Policy for privacy plan requirements

Information Treated as Private
  1. PKI CAs shall protect all Subscribers personally identifying information from unauthorized disclosure.

    1. The PKI CAs shall also protect personally identifying information for Entity personnel collected to support cross certification and MOA requirements from unauthorized disclosure.

    2. The CMA may release records of individual transactions upon request of any Subscriber (i.e., originator or recipient) involved in the transaction, or their legally recognized agents.

    3. The CMA shall not release the contents of archives maintained by CAs operating under this policy except as required by law.

    Note:

    Information included in PKI CA certificates are not subject to the protections in this requirement.

Information not Deemed Private
  1. For CAs, certificates that contain either the UUID or FASC-N in the subject alternative name extension shall not be distributed via publicly accessible repositories (e.g., Lightweight Directory Access Protocol (LDAP), , HTTP).

Responsibility to Protect Private Information
  1. See IRM 10.5.1 for privacy protection responsibilities and requirements.

Notice and Consent to Use Private Information
  1. Providing a notice or obtaining the consent of the Subscriber or Entity personnel is not required in order to release private information in accordance with the stipulations within this IRM.

Disclosure Pursuant to Judicial/Administrative Process
  1. Personally Identifiable Information (PII) shall not be disclosed to a third party unless authorized by PMA, this policy, required by law, government rule or regulation, or order of a court of competent jurisdiction.

    1. Any request for the release of information shall be verified for authorization and authority to act in that capacity.

    2. Before any data is released to the requesting official, and the release of information shall be processed according to 41 CFR 105-60.605.

Other Information Disclosure Circumstances
  1. This CP makes no further stipulation

Intellectual Property Rights

  1. The PKI PMO will not knowingly violate intellectual property rights held by others.

  2. The IRS owns any public key certificates and private keys that it issues.

Representations and Warranties

  1. The obligations described herein pertain to the TRCA (and, by implication, the PMO), and to all other CAs within the IRS, or which either interoperate with the TRCA or are in a trust chain up to a Principal CA that interoperates with the TRCA.

    1. The obligations applying to Principal or other CAs pertain to their activities as issuers of certificates. Further, the obligations focus on external Entity CA obligations affecting interoperability with the TRCA. Thus, where the obligations include, for example, a review or audit by some body other than an IRS activity, the purpose of that review pertains to interoperability using the TRCA, and whether the Entities comply with the MOA.

  2. The following obligations pertain to the PMA, and PKI PMO:

    1. Approve the CPS for each Treasury PKI CA that issues certificates under this policy.

    2. Review periodic compliance audits to ensure that Treasury PKI CAs are operating in compliance with their approved CPS .

    3. Review name space control procedures to ensure that distinguished names are uniquely assigned for all certificates issued under this policy .

    4. Revise this CP to maintain the level of assurance and operational practicality.

    5. Publicly distribute this CP to all subordinate and cross certified CAs, all CMAs, and all Subscribers (distribution may be accomplished by making this CP available on a web site) .

    6. Coordinate modifications to this CP to ensure continued compliance by subordinate CAs operating under approved CPSs

    7. Review periodic compliance audits to ensure that RAs and other components operated by subordinate CAs are in compliance with their approved CPSs

CA Representations and Warranties
  1. TRCA certificates are issued and revoked at the sole discretion of the PMA.

    1. When the TRCA issue a cross certificate to a non-federal Entity, it does so for the convenience of the U.S. Government and the Department of the Treasury.

    2. Any review by the PMA of a non-federal Entity’s Certificate Policy is for the use of the PMA in determining whether or not interoperability is possible, and if possible, to what extent the non-federal Entity’s Certificate Policy maps to the Treasury PKI X.509 CP and/or IRS PKI X.509 CP.

    3. For PIV-I, Entity CAs shall maintain an agreement with Affiliated Organizations concerning the obligations pertaining to authorizing affiliation with Subscribers of PIV-I certificates.

  2. Any CA that issues certificates that assert the policy defined in this document shall conform to the stipulations of this document as outlined in the appropriate CPSs.

RA Representations and Warranties
  1. An RA or LRA who performs registration functions as described in this policy shall conform to the stipulations of this policy, and comply with the appropriate CPS approved by the PMA and PMO for use with this policy.

    1. RAs or LRAs performing registration functions for any IRS PKI CA mapped to the FPKIPA shall also comply with the requirements of the Treasury—FBCA MOA.

    2. An RA or LRA found to have acted in a manner inconsistent with these obligations is subject to loss of RA or LRA privilege, and potentially adverse administrative or disciplinary action.

  2. This policy distributes PKI duties between the CAs and RAs and duties may vary among implementations of this Certificate Policy. For example, the RAs may merely collect information for a CA, or it may build the certificate for a CA to sign.

    1. CAs are ultimately responsible for ensuring that they sign only certificates generated and managed in accordance with this policy.

    2. A CA shall ensure that only those who understand the associated Certificate Policy requirements, and who agree to abide by them perform certificate generation, management, and revocation functions.

  3. Security requirements imposed on the TRCA are likewise imposed on any subordinate CAs, RAs and LRAs to the extent that the CAs, RAs and LRAs are responsible for the information collected.

    1. The particular assurance level asserted by a CA defines the specific information collected.

    2. A CMA found to have acted in a manner inconsistent with these obligations is subject to action.

  4. All CMAs supporting this policy shall conform to the stipulations of this document, as outlined in the appropriate CPSs.

Subscriber Representations and Warranties
  1. For Medium, (all policies), Medium Hardware, PIV-I, and High Assurance levels, a Subscriber shall be required to sign a document containing the requirements the Subscriber shall meet respecting protection of the private key and use of the certificate before being issued the certificate.

    1. For Basic Assurance level, the Subscriber shall be required to acknowledge his or her obligations respecting protection of the private key and use of the certificate before being issued the certificate. Subscriber documents shall be digitally signed, wherever possible.

  2. Subscribers of Entity CAs at Basic, Medium (all policies), PIV-I, , and High Assurance Levels shall agree to and are obligated to perform the following:

    1. Accurately represent themselves in all communications with the PKI authorities and other Subscribers.

    2. Protect their private keys at all times, in accordance with this policy, as stipulated in their certificate acceptance agreements and local procedures.

    3. Comply with the requirements of this CP and the appropriate CPS, as well as the applicable requirements of the Treasury/FPKIPA MOA .

    4. Notify, in a timely manner, the CMA that issued their certificates upon suspicion of loss or compromise of their private keys. Such notification shall be made directly or indirectly through mechanisms consistent with the CA’s CPS.

    5. Abide by all the terms, conditions, and restrictions levied on the use of their private keys and certificates.

    6. Use certificates provided by the Department of the Treasury PKI only for transactions related to Department of the Treasury business.

  3. PKI Sponsors assume the obligations of Subscribers for the certificates associated with their organizations and hardware components.

  4. If the PKI Sponsor for a device is not physically located near the sponsored device, and/or does not have sufficient administrative privileges on the sponsored device to protect the device’s private key and ensure that the device’s certificate is only used for authorized purposes, the device sponsor may delegate these responsibilities to an authorized administrator for the device.

    1. The delegation shall be documented and signed by both the device sponsor and the authorized administrator for the device.

    2. Delegation does not relieve the device sponsor of his or her accountability for these responsibilities.

Relying Parties Representations and Warranties
  1. This CP does not specify the steps that an external relying party should take to determine whether to rely upon a certificate.

    1. The relying party decides, pursuant to its own policies, what steps to take.

    2. The PKI CAs merely provide the tools (i.e., certificates, CRLs, and OCSAs) needed to perform the trust path creation, validation, and CP mappings that the relying party may wish to employ in its determination.

Representations and Warranties of Other Participants
  1. All CAs that issue certificates under this policy are obligated to post all CA certificates and all CRLs in a directory that is publicly accessible through the Active Directory and/or Lightweight Directory Access Protocol.

    1. To promote consistent access to certificates and CRLs, the repository shall implement access controls to prevent modification or deletion of information.

  2. Posted certificates and CRLs may be replicated in additional repositories for performance enhancement.

    1. The TRCA and other CAs operating in accordance with this CP may operate such repositories.

  3. All repositories that support a CA in posting information as required by this policy are obligated to accomplish the following:

    1. Maintain availability as required by the certificate l stipulations of this policy.

    2. Provide access control mechanisms sufficient to protect repository information .

    3. Provide a repository service that accepts communications using the Active Directory and/or LDAP.

Disclaimers of Warranties

  1. CAs operating under this policy may not disclaim any responsibilities described herein.

Limitation of Liability

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

Indemnities

  1. This CP makes no stipulation.

Individual Notices and Communications with Participants

  1. The IRS PMA shall establish appropriate procedures for communications with CAs cross certified with this CP via MOAs/MOUs as applicable.

    1. For communications with subordinate CAs and all other communications, this CP makes no further stipulation.

Amendments

  1. The amendment stipulations in the following subsections apply.

Procedure for Amendment
  1. The IRS PMA shall review this CP at least once every year, and shall communicate approved corrections, updates, or suggested changes to this CP to the FPKIPA and cross certified Entity Principal CAs. Such communication shall include a description of the change, a change justification, and contact information for the person requesting the change.

    Note:

    Changes that occur as the result of FPKIPA-approved changes to the FBCA and/or FCPF certificate policy are not included in this process. Such changes are an integral part of maintaining the TCA’s cross certification, and are not subject to further review once approved by the FPKIPA. The PMA shall record these changes as a part of the permanent records of the IRS PKI CP.

  2. Non-Federal policy changes under consideration by the IRS PMA/PMO shall be disseminated to interested parties. Interested parties may provide their comments to the IRS PMA.

  3. All Federal CP change proposals approved, at the Federal PKI Policy Authority level, will be adapted as approved into the current version of the IRS CP by virtue of that voting process.

Notification Mechanism and Period
  1. The IRS PMA shall make this CP and any subsequent changes publicly available within 30 days of approval.

Circumstances Under Which OID Shall Be Changed
  1. The IRS PKI CA will change certificate OIDs if the FPKI Policy Authority determines that a change in the CP reduces the level of assurance provided.

Dispute Resolution Provisions

  1. Any dispute arising with respect to this policy or certificates issued under this policy shall be resolved by the Parties.

  2. The PMA decides any disputes over the interpretation or applicability of the IRS PKI CP.

Governing Law

  1. United States Federal law (statute, case law, or regulation) govern the construction, validity, performance, and effect of certificates issued under this CP for all purposes.

    1. Where an inter-governmental dispute occurs, resolution will be according to the terms of the MOA

Compliance with Applicable Law

  1. All CAs shall comply with applicable law.

Miscellaneous Provisions

  1. The miscellaneous provisions defined in the following subsections apply.

Entire Agreement
  1. This CP makes no stipulation.

Assignment
  1. This CP makes no stipulation.

Severability
  1. If it is determined that one section of this policy is incorrect or invalid, the other sections shall remain in effect until the next policy update.

    1. Responsibilities, requirements, and privileges of this document merge into the newer edition upon release of that newer edition.

Enforcement (Attorney Fees/Waiver of Rights)
  1. This CP makes no stipulation.

Force Majeure
  1. This CP makes no stipulation.

Other Provisions

  1. This CP makes no stipulation.

PIV-Interoperable Smart Card Requirements

(1) The intent of PIV-I is to enable issuers to issue cards that are technically interoperable with Federal PIV Card readers and applications, and that may be trusted for particular purposes through a decision of the IRS.

(2) Reliance on PIV-I Cards requires compliance with technical specifications and specific trust elements

(3) The following requirements shall apply to PIV-I Cards:

  1. To ensure interoperability with Federal systems, PIV-I Cards shall use a smart card platform that is on GSA’s FIPS 201 Evaluation Program Approved Product List (APL) and uses the PIV application identifier (AID).

  2. PIV-I Cards shall conform to NIST SP 800-73. Interfaces for Personal Identity Verification - Part 1 PIV Card Application Namespace , Data Model, and Representation.

  3. The mandatory X.509 Certificate for Authentication shall be issued under treasury-pivi-hardware policy OID.

  4. All certificates issued under treasury-pivi-hardware, treasury-pivi-contentSigning, and treasurypivi-cardAuth shall conform to [PIV-I Profile].

  5. PIV-I Cards shall contain an asymmetric X.509 Certificate for Card Authentication that
    - conforms to [PIV-I Profile];
    - conforms to [NIST SP 800-73]; and
    - is issued under the treasury-pivi-cardAuth policy.

  6. PIV-I Cards shall contain an electronic representation (as specified in SP 800-73 and SP 800-76) of the Cardholder Facial Image printed on the card.

  7. The X.509 Certificates for Digital Signature and Key Management described in NIST SP 800-73 are optional for PIV-I Cards.

  8. Visual distinction of a PIV-I Card from that of a Federal PIV Card is required to ensure no suggestion of attempting to create a fraudulent Federal PIV Card. At a minimum, images or logos on a PIV-I Card shall not be placed entirely within Zone 11, Agency Seal, as defined by [FIPS 201].

  9. The PIV-I Card physical topography shall include, at a minimum, the following items on the front of the card:
    - Cardholder facial image;
    - Cardholder full name;
    - Organizational Affiliation, if exists; otherwise the issuer of the card; and
    - Card expiration date.

  10. PIV-I Cards shall have an expiration date not to exceed 6 years of issuance.

  11. Expiration of the PIV-I Card should not be later than expiration of PIV-I Content Signing certificate on the card.

  12. The digital signature certificate that is used to sign objects on the PIV-I Card (e.g., CHUID, Security Object) shall contain the treasury-pivi-contentSigning policy OID. The PIV-I Content Signing certificate shall conform to [PIV-I Profile]

  13. The PIV-I Content Signing certificate and corresponding private key shall be managed within a trusted Card Management System as defined by Exhibit 10.8.52-2

  14. At issuance, the RA shall activate and release the PIV-I Card to the subscriber only after a successful 1:1 biometric match of the applicant against the biometrics collected in Section 10.8.52.5.2.3.1

  15. PIV-I Cards may support card activation by the card management system to support card personalization and post-issuance card update.
    - To activate the card for personalization or update, the card management system shall perform a challenge response protocol using cryptographic keys stored on the card in accordance with NIST SP800-73; Cardholder facial image;
    - When cards are personalized, card management keys shall be set to be specific to each PIV-I Card. That is, each PIV-I Card shall contain a unique card management key;
    - Card management keys shall meet the algorithm and key size requirements stated in NIST SP 800-78, Cryptographic Algorithms and Key Sizes for Personal Identity Verification. .

PIV-I Card Management System Requirements

PIV-I Cards are issued and managed through information systems called Card Management Systems (CMSs). The complexity and use of these trusted systems may vary. Nevertheless, Entity CAs have a responsibility to ensure a certain level of security from the CMSs that manage the token on which their certificates reside, and to which they issue certificates for the purpose of signing PIV-I Cards. This exhibit provides additional requirements to those found above that apply to CMSs that are trusted under this Certificate Policy.

The Card Management Master Key shall be maintained in a FIPS 140-2 Level 2 Cryptographic Module and conform to [NIST SP 800-78] requirements. Diversification operations shall also occur on the Hardware Security Module (HSM). Use of these keys requires PIV-I Hardware or commensurate. Activation of the Card Management Master Key shall require strong authentication of Trusted Roles. Card management shall be configured such that only the authorized CMS can manage issued cards.

The PIV-I identity proofing, registration and issuance process shall adhere to the principle of separation of duties to ensure that no single individual has the capability to issue a PIV-I credential without the cooperation of another authorized person.

A formal configuration management methodology shall be used for installation and ongoing maintenance of the CMS. Any modifications and upgrades to the CMS shall be documented and controlled. There shall be a mechanism for detecting unauthorized modification to the CMS.

Summary of Available Policies (Certificate types)

The table below provides a high-level, informational summary of the types of certificates that Treasury issues to Subscribers. This table in non-normative and does not alter or negate any other policy statement found within this document

Certificate Policy/ OID Description Identity Proofing
Rudimentary/ treasury-level 1 ::= {2 16 840 1 101 3 2 1 5 2} This level provides the lowest degree of assurance concerning identity of the individual. This level is relevant to environments in which the risk of malicious activity is considered low. It is not suitable for transactions requiring authentication, and is generally insufficient for transactions requiring confidentiality, but may be used for the latter where certificates having higher levels of assurance are unavailable. This level requires the lowest degree of identity proofing and in-person proofing is not required. There is no identification requirement and the applicant may apply and receive a certificate by providing his or her e-mail address.
Basic - Individual / treasury-level 2 ::= {2 16 840 1 101 3 2 1 5 3 This level provides a basic level of assurance relevant to environments where there are risks and consequences of data compromise, but which are not considered to be of major significance. This may include access to private information where the likelihood of malicious access is not high. For Basic – Individual, identity may be established by in person proofing before a Registration Authority or Trusted Agent; or remotely verifying information provided by applicant including ID number and account number through record checks either with the applicable agency or institution or through credit bureaus or similar databases, and confirms that personal information in records are consistent with the application and sufficient to identify a unique individual. Address confirmation: a) Issue credentials in a manner that confirms the address of record supplied by the applicant; or b) Issue credentials in a manner that confirms the ability of the applicant to receive telephone communications at a number associated with the applicant in records, while recording the applicant’s voice.
Medium S/W/ treasury-level 7::= {2 16 840 1 101 3 2 1 5 7} This level is relevant to environments where risks and consequences of data compromise are moderate. This may include transactions having moderate monetary value or risk of fraud, or involving access to private information where the likelihood of malicious access is moderate. It is similar to Medium H/W except that the private key can be kept in software-based security modules. For Medium S/W level of assurance, the Identity shall be established by in-person proofing before the registration Authority or the Trusted Agent; information provided shall be verified to ensure legitimacy. A trust relationship between the Trusted Agent and the applicant which is based on an in-person antecedent may suffice as meeting the in-person identity proofing requirement. Credentials required are one Federal Government-issued Picture I.D., one REAL ID Act compliant picture ID1, or two (2) Non-Federal Government I.D.s, one of which shall be a photo I.D. (e.g., Non-REAL ID Act compliant Drivers License). Any credentials presented must be unexpired. Clarification on the trust relationship between the Trusted Agent and the applicant, which is based on an in-person antecedent identity proofing event, can be found in the “FBCA Supplementary Antecedent, In-Person Definition” document.
Medium H/W/ treasury-level 3::= {2 16 840 1 101 3 2 1 5 4} This level is relevant to environments where threats to data are high or the consequences of the failure of security services are high. This may include very high value transactions or high levels of fraud risk. The private key shall reside on a FIPS 140 Level 2 hardware security module For the medium H/W level of assurance, the Identity shall be established by in-person proofing before the Registration Authority or the Trusted Agent; information provided shall be verified to ensure legitimacy. A trust relationship between the Trusted Agent and the applicant which is based on an in-person antecedent may suffice as meeting the in-person identity proofing requirement. Credentials required are one Federal Government-issued Picture I.D., one REAL ID Act compliant picture ID1, or two (2) Non-Federal Government I.D.s, one of which shall be a photo I.D. (e.g., Non-REAL ID Act compliant Drivers License). Any credentials presented must be unexpired. Clarification on the trust relationship between the Trusted Agent and the applicant, which is based on an in-person antecedent identity proofing event, can be found in the “FBCA Supplementary Antecedent, In-Person Definition” document.
High/ treasury-level 5::= {2 16 840 1 101 3 2 1 5 5} This level is reserved for use by Government employees and is appropriate for those environments where the threats to data are high, or the consequences of the failure of security services are high. This may include very high value transactions or high levels of fraud risk For this level of assurance, identity established by in-person appearance before the Registration Authority or Trusted Agent; information provided shall be checked to ensure legitimacy Credentials required are either one Federal Government-issued Picture I.D., or two (2) Non-Federal Government I.D.s, one of which shall be a photo I.D. (e.g., Drivers License)
PIV-I Hardware/ treasury-pivi-hardware::= TBD This policy is reserved for use on a PIV-I Card and provides strong assurance of security. Depending on the key usage and PIV-I Card container, the certificate could be used for authentication, digital signature, or encryption. For PIV-I Hardware, credentials required are two (2) identity source documents in original form. The identity source documents must come from the list of acceptable documents included in Form I-9, OMB No. 1115-0136, Employment Eligibility Verification. At least one document shall be a valid State or Federal Government-issued picture identification (ID). For PIV-I, the use of an in-person antecedent is not applicable.
PIV-I Card Authentication/ treasury-pivi-cardAuth::= TBD This level is used to uniquely identify a PIV-I card – not the cardholder – for the purposes granting the cardholder physical access to high-volume, low-risk areas or in combination with other authentication mechanisms for access to high-risk areas. For PIV-I Card Authentication, credentials required are two (2) identity source documents in original form. The identity source documents must come from the list of acceptable documents included in Form I-9, OMB No. 1115-0136, Employment Eligibility Verification. At least one document shall be a valid State or Federal Government-issued picture identification (ID).
For PIV-I, the use of an in-person antecedent is not applicable.
PIV-I Content Signing/ treasury-pivi-contentSigning::= TBD This policy is reserved for use by any CMS that manages PIV-I cards to sign containers on the cards. Special requirements are placed on the CMS to ensure that the keys are highly protected and secure. For PIV-I content signing; sponsor credentials required are two (2) identity source documents in original form. The identity source documents must come from the list of acceptable documents included in Form I-9, OMB No. 1115-0136, Employment Eligibility Verification. At least one document shall be a valid State or Federal Government-issued picture identification (ID). For PIV-I, the use of an in-person antecedent is not applicable
Common Software / id-fpki-common-policy ::= {2 16 840 1 101 3 2 1 3 6} This level is reserved for use by Government employees and contractors. It is appropriate for unclassified data environments. The applicant presents a government issued ID to an RA or a Trusted Agent. The ID is either verified against a database or is corroborated by a second form of identification. A biometric of the applicant must be captured.
Common Hardware / id-fpki-common-hardware ::= {2 16 840 1 101 3 2 1 3 7} This level is reserved for use by Government employees and contractors. It is appropriate for unclassified data environments. The applicant presents a government issued ID to an RA or a Trusted Agent. The ID is either verified against a database or is corroborated by a second form of identification. A biometric of the applicant must be captured.
Common Devices / id-fpki-common-devices ::= {2 16 840 1 101 3 2 1 3 8} This level is reserved for use by Government sponsored devices. It is appropriate for unclassified data environments. The applicant presents a government issued ID to an RA or a Trusted Agent. The ID is either verified against a database or is corroborated by a second form of identification. A biometric of the applicant must be captured.
Common Hardware Devices / id-fpki-common-devicesHardware ::= {2 16 840 1 101 3 2 1 3 36} This level is reserved for use by Government sponsored devices. It is appropriate unclassified for data environments. The applicant presents a government issued ID to an RA or a Trusted Agent. The ID is either verified against a database or is corroborated by a second form of identification. A biometric of the applicant must be captured.
Common Authentication / id-fpki-common-authentication ::= {2 16 840 1 101 3 2 1 3 13} This level is reserved for use by Government employees and contractors. It is appropriate for unclassified data environments. The applicant presents a government issued ID to an RA. The ID is either verified against a database or is corroborated by a second form of identification. A biometric of the applicant must be captured.
Common High / id-fpki-common-high ::= {2 16 840 1 101 3 2 1 3 16} This policy is reserved for subscribers who are Federal employees. It is suitable for high-value transactions where there is a desire for assurance that the user is a Federal employee. At id-fpki-common-High, the applicant shall appear at the RA in person. The applicant presents a government issued ID that is either verified against a database or is corroborated by a second form of identification. A biometric of the applicant must be captured.
Common Card Authentication / id-fpki-common-cardAuth ::= {2 16 840 1 101 3 2 1 3 17} This level is used to uniquely identify a PIV card – not the cardholder – for the purposes granting the cardholder physical access to high-volume, low-risk areas or in combination with their authentication mechanisms for access to high-risk areas. The applicant presents a government issued ID to an RA. The ID is either verified against a database or is corroborated by a second form of identification. A biometric of the applicant must be captured.

Glossary and Acronyms

Term Definition or description
Access Control Process of granting access to information system resources only to authorized users, programs, processes, or other systems.
Activation Data Private data, other than keys, that are required to access cryptographic modules (i.e., unlock private keys for signing or decryption events).
AES Advanced Encryption Standard
Affiliated Organization Organizations that authorize affiliation with Subscribers of PIV-I certificates
AIS Automated Information System
AO Authorizing Official
Attribute Authority An Entity, recognized by the FPKIPA or comparable Entity body as having the authority to verify the association of attributes to an identity.
Authentication Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual’s identity.
C4CA Citizen and Commerce Class Common Certification Authority
CA Facility The collection of equipment, personnel, procedures, and structures that are used by a Certification Authority to perform certificate issuance and revocation.
CCR Configuration Change Request
Certificate A digital representation of information, which at least (1) identifies the certification authority issuing it, (2) names or identifies its Subscriber, (3) contains the Subscriber's public key, (4) identifies its operational period, and (5) is digitally signed by the certification authority issuing it. [ABADSG] As used in this CP, the term “Certificate” refers to certificates that expressly reference the OID of this CP in the “Certificate Policies” field of an X.509 v.3 certificate.
Certificate Authority (CA) A trusted entity in a public key infrastructure (PKI) that issues and revokes certificates exacting compliance to a PKI policy. A certificate issued by a CA contains the subscriber’s name, the name of the CA, the subscriber’s public key, and it is signed by the CA.
CA Certificate The certificate of the Certification Authority (CA). This certificate is used to verify signature on certificates issued by the CA.
Certificate Management Authority (CMA) Either a Certification Authority or a Registration Authority.
Certificate Policy (CP) A specialized form of administrative policy tuned to electronic transactions performed during certificate management. A Certificate Policy addresses all aspects associated with the generation, production, distribution, accounting, compromise recovery, and administration of digital certificates. Indirectly, a Certificate Policy can also govern the transactions conducted using a communications system protected by a certificate-based security system. By controlling critical certificate extensions, such policies and associated enforcement technology can support provision of the security services required by particular applications.
Certification Practice Statement (CPS) The statement of the practices which a Certification Authority employs in issuing certificates to a subscriber. This includes certificate application, use and revocation or suspension of certificates.
Certificate Revocation List (CRL) A list of revoked public key certificates created and digitally signed by a Certification Authority.
Certificate Status Authority A trusted Entity that provides on-line verification to a Relying Party of a subject certificate's trustworthiness, and may also provide additional attribute information for the subject certificate.
Confidentiality Preserving authorized restrictions on information access and disclosure, (including means for protecting personal privacy and proprietary information) from unauthorized individuals, entities, or processes.
Contingency Plan Management policy and procedures designed to maintain or restore business operations, including computer operations, possibly at an alternate location, in the event of emergencies, system failures, or disaster.
Credentials An object or data structure that authoritatively binds an identity (and optionally, additional attributes) to a token possessed and controlled by a Subscriber.
Cross Certificate A certificate used to establish a trust relationship between two Certification Authorities.
Cryptography The discipline that embodies principles, means, and methods for providing information security, including confidentiality, data integrity, non-repudiation, and authenticity.
Cryptographic module The set of hardware, software, firmware, or some combination thereof that implements cryptographic logic or processes, including cryptographic algorithms, and is contained within the cryptographic boundary of the module.
CSA Certificate Status Authority
CSS Certificate Status Server
DC Domain Component
DH Diffie Hellman
Digital Signature The result of a transformation of a message by means of a cryptographic system using keys such that a Relying Party can determine: (1) whether the transformation was created using the private key that corresponds to the public key in the signer’s digital certificate; and (2) whether the message has been altered since the transformation was made.
Disaster Recovery Plan A written plan for processing critical applications in the event of a major hardware or software failure or destruction of facilities.
DN Distinguished Name
DSS Digital Signature Standard
Dual Use Certificate A certificate that is intended for use with both digital signature and data encryption services.
EA Enterprise Architecture
ECDSA Elliptic Curve Digital Signature Algorithm
End Entity Certificate (EEC) A certificate belonging to a non-CA entity, e.g. you, me or the computer, firewall.
EOps Enterprise Operations
ESP Enterprise Standards Profile
FBCA Federal Bridge Certificate Authority
FBCA Operational Authority (FBCA OA) The Federal Public Key Infrastructure Operational Authority is the organization selected by the Federal Public Key Infrastructure Policy Authority to be responsible for operating the Federal Bridge Certification Authority.
FCPCA Federal Common Policy Certification Authority
Federal Public Key Infrastructure Policy Authority (FPKIPA) The FPKIPA is a federal government body responsible for setting, implementing, and administering policy decisions regarding inter-Entity PKI interoperability that uses the FBCA.
FIPS Federal Information Processing Standard
FTCA Federal Tort Claims Act
FTP File Transfer Protocol
GAO Government Accountability Office
HSPD-12 Homeland Security Presidential Directive 12
HTTP Hypertext Transfer Protocol
Identification The process of verifying the identity of a user, process, or device, usually as a prerequisite for granting access to resources in an information system.
Integrity The prevention of the unauthorized/improper modification or destruction of information; includes ensuring information non-repudiation and authenticity.
Intermediate CA: A CA that is subordinate to another CA, and has a CA subordinate to itself.
IP Internet Protocol
IT Information Technology
Key Escrow The retention of the private component of the key pair associated with a Subscriber’s encryption certificate to support key recovery.
KRP Key Recovery Policy
KRPS Key Recovery Practices Statement
Lightweight Directory Access Protocol (LDAP) The Lightweight Directory Access Protocol is an application protocol for reading and editing directories over an IP network. A directory in this sense is an organized set of records: for example, a telephone directory is an alphabetical list of persons and organizations with an address and phone number in each "record".
Local Registration Authority (LRA) A Registration Authority with responsibility for a local community
Memorandum of Agreement Agreement between the FPKIPA and an Entity allowing interoperability between the Entity Principal CA and the FBCA.
MOU Memorandum of Understanding
Naming Authority An organizational Entity responsible for assigning Distinguished Names (DNs) and for assuring that each DN is meaningful and unique within its domain.
NPE Non Person Entities
Non-repudiation Assurance that the sender is provided with proof of delivery and that the recipient is provided with proof of the sender's identity so that neither can later deny having processed the data.
  • Technical non-repudiation refers to the assurance a user has, that if a public key is used to validate a digital signature, that signature had to have been made by the corresponding private signature key.

  • Legal non-repudiation refers to how well possession or control of the private signature key can be established.

Object Identifier (OID) A specialized formatted number that is registered with an internationally recognized standards organization. The unique alphanumeric/numeric identifier registered under the ISO registration standard to reference a specific object or object class. In the federal government PKI, they are used to identify uniquely each of the policies and cryptographic algorithms supported.
OSCP Online Certificate Status Protocol
PGLD Privacy, Governmental Liaison and Disclosure
PIN Personal Identification Number
PIT Part-time/Intermittent/Temporary
PIV Personal Identity Verification
PKI Sponsor Fills the role of a Subscriber for non-human system components that are named as public key certificate subjects, and is responsible for meeting the obligations of Subscribers as defined throughout this CP.
Plan of Action and Milestones (POA&M) A document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks and scheduled completion dates for the milestones.
PM Program Manager
PMO Program Management
Policy Management Authority (PMA) Entity established to oversee the creation and update of Certificate Policies, review Certification Practice Statements, review the results of CA audits for policy compliance, evaluate non-domain policies for acceptance within the domain, and generally oversee and manage the PKI certificate policies. For the FBCA, the PMA is the FPKIPA.
Principal CA The Principal CA is a CA designated by an Entity to interoperate with the FBCA.
Private Key (1) The key of a signature key pair used to create a digital signature. (2) The key of an encryption key pair that is used to decrypt information. This key is accessible only to the owner.
Private Key cryptography It is a cryptographic approach which involves the use of asymmetric key algorithms. The asymmetric key algorithms are used to create a mathematically related key pair: a secret private key and a published public key. Use of these keys allows protection of the authenticity of a message by creating a digital signature of a message using the private key, which can be verified using the public key. It also allows protection of the confidentiality and integrity of a message, by public key encryption, encrypting the message using the public key, which can only be decrypted using the private key.
Public key (1) The key of a signature key pair used to validate a digital signature. (2) The key of an encryption key pair that is used to encrypt information. In both cases, this key is made publicly available normally in the form of a digital certificate.
Public Key Infrastructure (PKI) A set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates.
Registration Authority (RA) Entity responsible for identification and authentication of certificate subjects that has automated equipment for the communication of applicant data to Certification Authorities and does not sign or directly revoke certificates.
Relying Party A relying party is the entity that relies on the validity of the binding of the subscriber’s name to a public key. The relying party is responsible for deciding whether or how to check the validity of the certificate by checking the appropriate certificate status information. A relying party may use information in the certificate (such as CP identifiers) to determine the suitability of the certificate for a particular use.
Renew (a certificate) The act or process of extending the validity of the data binding asserted by a public key certificate by issuing a new certificate.
Repository A trustworthy system for storing and retrieving certificates or other information relevant to certificates.
Root CA In a hierarchical PKI, the CA whose public key serves as the most trusted datum (i.e., the beginning of trust paths) for a security domain.
Rekey (a certificate) To change the value of a cryptographic key that is being used in a cryptographic system application.
SBU Sensitive but Unclassified
Signature Certificate A public key certificate that contains a public key intended for verifying digital signatures rather than encrypting data or performing any other cryptographic functions.
SOP Standard Operating Procedure
SSL/TLS Secure Socket Layer/Transport Layer Security
SSP Shared Service Provider.
Subordinate CA In a hierarchical PKI, a CA whose certificate signing key is certified by another CA, and whose activities are constrained by that other CA. (see superior CA).
Subscriber An entity that (1) is the subject named or identified in a certificate issued to such an entity, and (2) holds a private key that corresponds to a public key listed in that certificate.
Subordinate CA When there are multiple CAs in a PKI, the CAs are structured in a hierarchy or chain. The CA above another CA in a chain is called an root CA; a CA below another CA in the chain is called a subordinate CA. A CA can also be subordinate to a root outside of the Certificate System deployment; for example, a CA which functions as a root CA within the Certificate System deployment can be subordinate to a third-party CA.
Superior CA In a hierarchical PKI, a CA who has certified the certificate signature key of another CA, and who constrains the activities of that CA. (See subordinate CA).
Technical non-repudiation The contribution public key mechanisms make to the provision of technical evidence supporting a non-repudiation security service.
TIGTA Treasury Inspector General Tax Administration
TRCA Treasury Root Certificate Authority.
Trust List Collection of Trusted Certificates used by Relying Parties to authenticate other certificates.
Trusted Agent Entity authorized to act as a representative of an Entity in confirming Subscriber identification during the registration process. Trusted Agents do not have automated interfaces with Certification Authorities.
Trusted Certificate A certificate that is trusted by the Relying Party on the basis of secure and authenticated delivery. The public keys included in trusted certificates are used to start certification paths. Also known as a "trust anchor.”
Trusted Timestamp A digitally signed assertion by a trusted authority that a specific digital object existed at a particular time.
Two-Person Control Continuous surveillance and control of "positive control" material at all times by a minimum of two authorized individuals, each capable of detecting incorrect and/or unauthorized procedures with respect to the task being performed and each familiar with established security and safety requirements.
Update (a certificate) The act or process by which data items bound in an existing public key certificate, especially authorizations granted to the subject, are changed by issuing a new certificate.
User credentials The combination of a user certificate and its corresponding private key.
WWW World Wide Web
Zeroize A method of erasing electronically stored data by altering the contents of the data storage so as to prevent the recovery of the data.

References

IRS

  • IRM 10.8.1 - Information Technology (IT) Security, Policy and Guidance

  • IRM 10.8.2 - Information Technology (IT) Security, Roles and Responsibilities

  • IRM 10.8.3 - Information Technology (IT) Security, Audit Logging Security Standards

  • IRM 10.8.10 - Information Technology (IT) Security, Linux and Unix Security Policy

  • IRM 10.8.20 - Information Technology (IT) Security, Windows Security Policy

  • IRM 10.8.22 - Information Technology (IT) Security, Web Server Security Policy

Treasury

  • Department of Treasury Public Key Infrastructure(PKI) X.509 Certificate Policy, Version (RFC 3647) 2.8, March 26, 2015

NIST

  • FIPS 199, Standards for Security Categorization of Federal Information and Information Systems, February, 2004

  • FIPS 140-2, Security Requirements for Cryptographic Modules, May 25, 2001.

  • FIPS 186-4, Digital Signature Standard, July 2013

  • FIPS 201-2, Personal Identity Verification (PIV) of Federal Employees and Contractors, August, 2013

  • NIST SP 800-57, Part 3, Rev. 1 Recommendation for key Management, Part 3 Application-Specific Key Management Guidance, Ja5nuary 2015

  • NIST SP 800-73-4, Interfaces for Personal Identity Verification, May 2015

  • NIST SP 800-76-2, Biometric Data Specification for Personal Identity Verification, July 2013

  • NIST 800-78-4, Cryptographic Algorithms and Key Sizes for Personal Identification Verification (PIV), May 2015

Other Documents

  • Certificate Policy (CP) for IRS Secure Messaging Public Key Infrastructure (PKI) Department of the Treasury v2.1, August 22, 2001

  • Certificate Practice Statement (CPS) for the IRS Secure Enterprise Messaging System (SEMS) Department of the Treasury, September, 2001

  • RFC 3647 - Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework

  • X.509 Certificate Policy For The U.S. Federal PKI Common Policy Framework, Version 3647 - 1.17, December 9, 2011

≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡