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

Manual Transmittal

July 5, 2019

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 IRM is focused on IRS requirements, roles, and responsibilities regarding Only Locally Trusted (OLT) certificates.

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

Effect on Other Documents

IRM 10.8.52 dated August 18, 2017 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; and IRM 10.8.2, Information Technology Security Roles and Responsibilities. .
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

(07-05-2019)


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: Chief Information Officer

  4. Program Owner: Cybersecurity Architecture and Implementation (an organization within Cybersecurity)

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

Scope

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

  2. The IRS shall ensure that the PKI products and versions selected are in accordance with the IRS Enterprise Architecture (EA) Enterprise Standards Profile (ESP), which dictates the official products and versions of software within the IRS.

  3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  4. While certificates issued under the Treasury Root Certification Authority (TRCA) are appropriate for most purposes, there are some implementations which cannot meet the specific requirements for such certificates but still require Public Key Infrastructure (PKI) services. (IRS-defined)

  5. Such PKIs are permitted under Department of Treasury (Treasury) policy as long as the certificates issued by the PKI are intended to be used entirely within the confines of a specifically identified local environment and are not intended to be trusted by any entity outside of that environment. Although intended primarily for non-person entities (NPE), there are instances where a local PKI may issue certificates for use by individuals. Local may be Treasury-wide or restricted to one or more Treasury bureaus. (IRS-defined)

  6. A PKI operated under this certificate policy is operated in consonance with and augments the information system security requirements in Treasury Department Publication (TD P) 85-01, "Treasury IT Security Program." (IRS-defined)

  7. 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: (IRS-defined)

    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.

  5. This policy specifies the requirements for the operation of an “only locally trusted” (OLT) PKI. It defines the requirements for the creation and management of Version 3 X.509 public-key certificates for use in Treasury applications. This IRM supplements the “United States Department of the Treasury X.509 Certificate Policy.”

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 Minimum Security Requirements for Federal Information and Information Systems, mandates the use of National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 Security and Privacy Controls for Federal Information Systems and Organizations, 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 Public Key Infrastructure(TPKI).

    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 TPKI and all Treasury CAs assigned by the Treasury Root Certification Authority (TRCA).

    5. Internal Auditing and compliance oversight of TPKI 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 TPKI 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.

  5. The Policy Management Authority (PMA) for OLT PKIs is the Treasury PMA. (IRS-defined)

    1. Each OLT PKI shall identify a person or organization as overall responsible for the implementation and operation of the OLT PKI – OLT Management Authority (MA).

    2. The OLT MA is responsible for developing a certificate practice statement (CPS) for the OLT PKI and obtaining approval of the CPS from the Treasury PMA prior to beginning operation of the OLT PKI. The CPS will address all the applicable sections of the [TREASURYCP].

    3. An OLT PKI may be comprised of a single issuing CA (self-signed) or multiple issuing CAs with CA signing certificates issued by a locally implemented Root CA.

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

  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 revision of Certification 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 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 other 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.

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. TRCA shall not be part of an OLT PKI. Where an OLT PKI only supports a single Treasury Bureau, the root (if separate from the issuing CA) shall be operated to meet the requirements of this addendum, except that the Root shall be maintained offline. If there is a need for an OLT PKI to span multiple Treasury organizations, the organizations requiring the PKI shall work with the Treasury PMA to determine the appropriate place to operate the Root. A Root operated in support of multiple organizations shall be operated offline and conform to the requirements for Treasury Medium. In the future, it is anticipated that all Treasury OLT PKIs will be consolidated into a single PKI operated under a single Treasury Root CA.(IRS-defined)

  2. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

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

Certificate Usage

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

  2. 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. NPE Certificates issued by an OLT PKI support PK-enabled applications with a locally defined environment. Examples include: (IRS-defined)

    • Performing device authentication to the local domain;

    • Signing and key encypherment of data retained locally;

    • A web server only accessed from within the local domain; and

    • Device-to-device authentication internal to the domain.

  2. OLT certificates are only issued by an OLT PKI to individuals for use cases specifically approved by the OLT PMA. The OLT MA provides the details of the specific use case to the OLT PMA. Examples of use cases include: (IRS-defined)

    • Certificates for people who perform administrative functions; and

    • Signing of code that is only intended for local use.

  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.

  6. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

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.

  5. Certificates issued by an OLT PKI shall not be used in any circumstance where the certificate needs to be trusted outside the local environment for which the PKI is established. Examples include: (IRS-defined)

    • A PK-enabled web server accessed from outside the local domain.

  6. Certificates issued by an OLT PKI to individuals shall not be used for any purpose not specifically approved by the OLT PMA.(IRS-defined)

Identification and Authentication

  1. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy `for additional requirements.

  2. Refer to IRM 10.8.1 for additional Identification and Authentication requirements

Naming

  1. The following sections detail the requirements for certificate naming, as found in the Treasury CP, apply. In addition to the Naming guidance defined within this IRM requirements for the following control areas shall be implemented in accordance with Department of the Treasury PKI X.509 Certificate Policy.

    • Need for Names to be Meaningful

    • Anonymity of Pseudonymity of Subscribers

    • Recognition, Authentication, and Role of Trademarks

    • Initial Identity Validation

    • Method to Prove Possession of Private Key

    • Authentication of Organization Identity

    • Validation of Authority

    • Criteria for Interoperation

Types of Names
  1. In order to ensure uniqueness of the names across OTL PKIs, each OLT MA shall obtain approval for the OLT PKI namespace from the Treasury PMA. This approval shall consider both the PKI namespace and Domain Name Service (DNS) names. (IRS-defined)

  2. OLT PKIs may use either Domain component or X.500 Domain Names (DNs). . (IRS-defined)

  3. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements

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. Name uniqueness for NPE certificates is enforced within the OLT PKI’s approved CA namespace by use of approved DNS names for end entities. Name uniqueness for individuals is enforced by the RA by verifying that there are no name collisions for previously issued certificates issued within the OLT PKI to another individual. (IRS-defined)

  2. Uniqueness across Treasury is enforced by separation of namespaces among OLT PKIs. (IRS-defined)

  3. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements

Authentication of Individual Identity

  1. The authentication of individual identity requirements defined in the following subsections, as found in the Treasury CP, apply. In addition to the Authentication of Individual Identity requirements defined within this IRM requirements for the following control areas shall be implemented in accordance with the Department of the Treasury PKI (X.509) Certificate Policy.

    • Authentication of Human Subscribers for Group Certificates

    • Authentication of Human Subscribers for Role-based Certificates

Authentication of Human Subscribers
  1. A CA Operator authenticates an individual to receive a PKI certificate from an OLT PKI by (IRS-defined):

    1. Receiving an email, digitally signed by the individual using a signing certificate issued by the Treasury PKI

    2. Performing face-to-face identity proofing (directly, or through an approved Trusted Agent or Notary) as required for Basic Assurance in Section 3.2.3.1 of the Treasury CP.

  2. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements

Authentication of Devices
  1. OLT certificates may be issued on the basis of electronically authenticated entity subscriber requests using Certificate enrollment protocols that support automated and semi-automated mechanisms for authenticating these requests. (IRS-defined)

    • PKI Sponsor may request enrollment using digitally-signed e-mail using a PIV certificate.

    • Microsoft’s auto-enrollment protocol includes limited support for authenticating requests from devices. This authentication is deemed sufficient for issuance of IPSec, Domain Controller, and workstation device certificates.

    • Network Device Enrollment Services (NDES) enrollment shall be authenticated using credentials of the subscribing device submitting its request for a certificate to the NDES Server.

    • Web Enrollment shall be authenticated using the PIV credentials of the administrator submitting the request for device certificates to the Web Enrollment Server.

  2. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

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

Identification and Authentication For Re-key Request

  1. The identification and authentication for re-key request requirements in the following subsections, as found in the Treasury CP, apply. In addition to the Identification and Authentication for Re-key Request guidance defined within this IRM requirements for the following control areas shall be implemented in accordance with Department of the Treasury PKI X.509 Certificate Policy.

    • Certificate Renewal

    • Identification and Authentication for Revocation Request

Identification and Authentication for Routine Rekey
  1. OLT end entity certificates may be rekeyed through use of the current private key or via the initial enrollment method. (IRS-defined)

  2. OLT maximum end entity certificate and key life is 3 years. (IRS-defined)

  3. OLT end entity certificates may be re-keyed indefinitely. (IRS-defined)

  4. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

Certificate Renewal
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

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. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

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.

Certificate Lifecycle

  1. The Certificate Lifecycle requirements in the following subsections, as found in the Treasury CP, apply. In addition to the Certificate Lifecycle guidance defined within this IRM requirements for the following control areas shall be implemented in accordance with Department of the Treasury PKI X.509 Certificate Policy

    • Application

    • Submission of Certificate Application

    • Enrollment Process and Responsibilities

    • Certificate Acceptance

    • Conduct Constituting Certificate Acceptance

    • Publication of the Certificate by the CA

    • Notification of Certificate Issuance by the CA to Other Entities

    • Key Pair and Certificate Usage

    • Subscriber Private Key and Certificate Usage

    • Certificate Renewal

    • Circumstance for Certificate Renewal

    • Who May Request Renewal

    • Processing Certificate Renewal Requests

    • Notification of New Certificate Issuance to Subscriber

    • Conduct Constituting Acceptance of a Renewal Certificate

    • Publication of the Renewal Certificate by the CA

    • Notification of Certificate Issuance by the CA to Other Entities

    • Certificate Re-key

    • Circumstances for Certificate Re-key

    • Who May Request Certification of a New Public Key

    • Processing Certificate Rekeying Requests

    • Notification of New Certificate Issuance to Subscriber

    • Conduct Constituting Acceptance of a Rekeyed Certificate

    • Publication of the Rekeyed Certificate to the CA

    • Notification of Certificate Issuance by the CA to Other Entities

    • Certificate Modification

    • Circumstances for Certificate Modification

    • Who May Request Certificate Modification

    • Processing Certificate Modification Requests

    • Notification of New Certificate Issuance to Subscriber

    • Conduct Constituting Acceptance of Modified Certificate

    • Publication of the Modified Certificate by the CA

    • Notification of Certificate Issuance by the CA to Other Entities

    • Certificate Revocation and Suspension

    • Circumstances for Revocation

    • Who can request revocation

    • Procedure for revocation request

    • Revocation Request Grace Period

    • Time Within Which CA Shall Process the Revocation

    • Request Revocation Checking Requirements for Relying Parties

    • CRL Issuance Frequency

    • Online Revocation/Status Checking Availability

    • Online Revocation Checking Requirements

    • Other Forms of Revocation Advertisements Available

    • Special Requirements Related to Key Compromise

    • Circumstances for Suspension

    • Those Authorized to Request Suspension

    • Requirement for Suspension

    • Limits on Suspension Period

    • Certificate Status Services

    • Operational Characteristics

    • Service Availability

    • Optional Features

    • End of Subscription

    • Key Escrow and Recovery

    • Key Escrow and Recovery Policy and Practices

    • Session Key Encapsulation and Recovery Policy and Practices

  2. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Certificate Application Processing

  1. The Certificate Application Processing requirements in the following subsections, as found in the Treasury CP, apply. In addition to the Certificate Application Processing guidance defined within this IRM, requirements for the following control areas shall be implemented in accordance with Department of the Treasury PKI X.509 Certificate Policy.

    • Approval or Rejection of Certificate Application

    • Time to Process Certificate Applications

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

  2. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Certificate Issuance

  1. The certificate issuance requirements in the following subsections, as found in the Treasury CP, apply. In addition to the Certificate Issuance guidance defined within this IRM, requirements for the following control areas shall be implemented in accordance with Department of the Treasury PKI X.509 Certificate Policy.

    • CA Actions During Certificate Issuance

    • Notification to Subscriber of Certificate Issuance

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.

Facility Management and Operations Controls

  1. 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. In addition to the Facility Management and Operations Controls guidance defined within this IRM, as found in the Treasury CP, requirements for the following control areas shall be implemented in accordance with Department of the Treasury PKI X.509 Certificate Policy.

    • Physical Controls

    • Physical Access

    • Physical Access for RA Equipment

    • Physical Access for CSS Equipment

    • Documentation Supplied to Personnel

    • Audit Logging Requirements

    • Audit Log Backup Requirements

    • Audit Collection System

    • Notification to Event-Causing Subject

    • Vulnerability Assessments

    • Archive Backup Procedures

    • Archive Collection System

    • Key Changeover

    • Computing Resources, Software, and/or Data Are Corrupted

    • Entity (CA) Requirements

    • Business Continuity Capabilities After a Disaster

Procedural Controls

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Number of Persons Required per Task
  1. There are no tasks associated with the OLT PKI that require multi-person control.

Identification and Authentication for Each Role
  1. Trusted roles are required to authenticate to the CA prior to performing any tasks on the CA. No individual shall have more than one identity on the CA.

Separation of Roles
  1. A single individual may assume both the Officer and Administrator roles. No one individual shall assume both a CA Operator role and an Auditor role.

Personnel Controls

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Background, Qualifications, Experience, and Security Clearance Requirements
  1. Persons filling trusted roles in an OLT PKI are selected on the basis of loyalty, trustworthiness, and integrity. Trusted persons may be Department of the Treasury direct-hire personnel or contractors. Only U.S. Citizens may fill trusted roles. Persons filling trusted roles shall:

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

    • Have not been previously relieved of CA-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 OLT MA.

Background Check Controls
  1. OLT Trusted Roles shall pass, at a minimum, a background investigation covering the following areas:

    • Employment

    • Education

    • Place of Residence

    • Law Enforcement

    • References

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

  3. A competent adjudication authority shall perform adjudication of the background investigation.

Training Requirements
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Retraining Frequency and Requirements
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Job Rotation Frequency and Sequence
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Sanctions for Unauthorized Actions
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

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. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Audit Logging Requirements

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

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

    Auditable Events (Logged either electronically or manually) OLT PMA Auditor/or Script Required
    SECURITY AUDIT
    Any changes to the Audit parameters, e.g., audit frequency, type of event audited X  
    Any attempt to delete or modify the Audit logs X  
    Obtaining a third-party time-stamp X  
    IDENTIFICATION AND AUTHENTICATION
    Successful and unsuccessful attempts to assume a role X  
    The value of maximum authentication attempts is changed X  
    Maximum authentication attempts unsuccessful authentication attempts occur during user login X  
    An Administrator unlocks an account that has been locked as a result of unsuccessful authentication attempts X  
    An Administrator changes the type of authenticator, e.g., from password to biometrics X  
    LOCAL DATA ENTRY
    All security-relevant data that is entered in the system X  
    REMOTE DATA ENTRY
    All security-relevant messages that are received by the system X  
    DATA EXPORT AND OUTPUT
    All successful and unsuccessful requests for confidential and security-relevant information X  
    KEY GENERATION
    Whenever the CA generates a key. (Not mandatory for single session or one-time symmetric keys) X X
    PRIVATE KEY LOAD AND STORAGE
    The loading of Component private keys X X
    All access to certificate subject private keys retained by the CA, RA, or LRA for key recovery purposes X  
    TRUSTED PUBLIC KEY ENTRY, DELETION, AND STORAGE
    All changes to the trusted public keys, including additions and deletions X X
    SECRET KEY STORAGE
    The manual entry of secret keys used for authentication    
    PRIVATE AND SECRET KEY EXPORT
    The export of private and secret keys (keys used for a single session or message are excluded) X X
    CERTIFICATE REGISTRATION
    All certificate requests and handling X  
    CERTIFICATE REVOCATION
    All certificate revocation requests and handling X  
    ESCROWED KEY RECOVERY REQUESTS
    All escrowed key recovery requests and handling` X  
    CERTIFICATE STATUS CHANGE APPROVAL
    The approval or rejection of a certificate status change request X  
    CA, RA or LRA CONFIGURATION
    Any security-relevant changes to the configuration of the CA or the RA X  
    ACCOUNT ADMINISTRATION
    Roles and users are added or deleted The access control privileges of a user account or a role are modified X  
    The access control privileges of a user account or a role are modified X  
    CERTIFICATE PROFILE MANAGEMENT
    All changes to the certificate profile X  
    CERTIFICATE REVOCATION LIST PROFILE MANAGEMENT
    All changes to the certificate revocation list profile X  
    MISCELLANEOUS
    Appointment of an individual to a Trusted Role X  
    Installation of the Operating System X  
    Installation of CA,, RA, or LRA Application X  
    Installing hardware cryptographic modules    
    Removing hardware cryptographic modules    
    Destruction of cryptographic modules X  
    System Startup X  
    Designation of personnel for multiparty control X  
    Logon Attempts on CA, RA, or LRA Applications X  
    Receipt of Hardware / Software    
    Attempts to set passwords X  
    Attempts to modify passwords X  
    Backing up CA, RA. or LRA internal database X  
    Restoring* CA, RA, LRA internal database (*Auditor present with scripts for COOP Drills and Designated CA Disaster Recovery Events only. Auditor not required for high availability or normal switch over of services between facilities)   X
    File manipulation (e.g., creation, renaming, moving)    
    Posting of any material to a repository    
    Access to CA, RA, or LRA internal database    
    All certificate compromise notification requests X  
    Loading tokens with certificates    
    Shipment of Tokens X  
    Zeroize tokens X  
    Rekey of the CA X X
    CONFIGURATION CHANGES TO THE CA SERVER, RA, OR LRA INVOLVING
    Hardware X  
    Software X  
    Operating System X  
    Patches X  
    Security Profiles    
    PHYSICAL ACCESS/ SITE SECURITY
    Personnel Access to room housing CA    
    Access to the CA server    
    Known or suspected violations of physical security X  
    ANOMALIES
    Software Error conditions X  
    Software check integrity failures X  
    Receipt of improper messages    
    Misrouted messages    
    Network attacks (suspected or confirmed) X  
    Equipment failure X  
    Electrical Power Outages    
    Uninterruptible Power Supply (UPS) failure    
    Obvious and significant network service or access failures    
    Violations of Certificate Policy X  
    Violations of Certification Practice Statement X  
    Resetting Operating System clock X  
Frequency of Processing Log
  1. OLT CA audit logs shall be reviewed for cause or as mandated by Treasury security policy. The review shall be performed by a security Auditor appointed by the OLT MA.

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. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Audit Collection System
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Notification to Event-Causing Subject
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Vulnerability Assessments
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

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 Records Archived
  1. Data to be Archived OLT
    CA accreditation (if applicable) X
    Certificate Policy and Certification Practice Statement X
    Any contractual agreements (as appropriate) to which the CMA is bound, and other agreements concerning operations of the CA X
    System and equipment configuration X
    Modifications and updates to system, configuration, documentation (e.g., CPS), and contractual agreements X
    Certificate issuance, suspension, restoration and key recovery requests X
    Certificate Revocation requests X
    Documentation of receipt and acceptance of certificates X
    Documentation of receipt of tokens X
    All certificates issued or published X
    Record of CA Rekey and/or notification of cross-certified CA Rekey in accordance with applicable MOAs X
    All CRLs issued and/or published X
    All Audit Logs, and security audit data and reports X
    Other data or applications to verify archive contents X
    All CA operations communications and documentation to the PMA, PKI PA, other CMAs, and compliance auditors X
    Compliance Auditor reports X
Retention Period for Archive
  1. Archive records shall be retained as specified in the General Records Schedule established by the National Archives and Records Administration or an agency specific schedule as applicable.

Protection of Archive
  1. OLT Archive data shall be protected in accordance with Treasury records retention policies and procedures.

Archive Backup Procedures
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

  2. 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. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

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

Key Changeover

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Compromise and Disaster Recovery

  1. In the event an OLT PKI CA is suspected of being compromised or otherwise unable to operate, the OLT MA shall declare the CA revoked and immediately reestablish the CA and subordinate CAs if applicable. Subscribers will be required to obtain new certificates

  2. 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. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Entity (CA) Requirements
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Business Continuity Capabilities After a Disaster
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

CA and RA Termination

  1. If an OLT CA is terminated for convenience prior to the expiration of its signing certificate, the CA shall be considered compromised and, if required, replaced as specified in Section 5.7 of the Treasury PKI x509 Certificate Policy

Site Location and Construction

  1. The location and construction of the facility housing OLT PKI CA equipment shall be consistent with the security provided to the servers that provide network security and administration support (e.g., Microsoft Domain Controller) to the local environment. (IRS-defined)

  2. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

Physical Access for CA Equipment

  1. OLT CAs shall be physically protected to be consistent with the security provided to the servers that provide network security and administration support (e.g., Microsoft Domain Controller) to the local environment. (IRS-defined)

  2. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

Physical Access for RA Equipment

  1. OLT CAs shall be physically protected to be consistent with the security provided to the servers that provide network security and administration support (e.g., Microsoft Domain Controller) to the local environment. (IRS-defined)

  2. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

Power and Air Conditioning

  1. OLT CAs shall have environmental controls (e.g., air, power, etc.) equivalent to that provided to the servers that provide network security and administration support (e.g., Microsoft Domain Controller) to the local environment. (IRS-defined)

  2. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

Water Exposures

  1. OLT CAs shall have environmental controls (e.g., air, power, etc.) equivalent to that provided to the servers that provide network security and administration support (e.g., Microsoft Domain Controller) to the local environment. (IRS-defined)

  2. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

Fire Prevention and Protection

  1. OLT CAs shall have environmental controls (e.g., air, power, etc.) equivalent to that provided to the servers that provide network security and administration support (e.g., Microsoft Domain Controller) to the local environment. (IRS-defined)

  2. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

Media Storage

  1. OLT CAs shall have environmental controls (e.g., air, power, etc.) equivalent to that provided to the servers that provide network security and administration support (e.g., Microsoft Domain Controller) to the local environment. (IRS-defined)

  2. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

Waste Disposal

  1. OLT CAs shall have environmental controls (e.g., air, power, etc.) equivalent to that provided to the servers that provide network security and administration support (e.g., Microsoft Domain Controller) to the local environment. (IRS-defined)

  2. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

Off-Site Backup

  1. OLT CAs shall have environmental controls (e.g., air, power, etc.) equivalent to that provided to the servers that provide network security and administration support (e.g., Microsoft Domain Controller) to the local environment. (IRS-defined)

  2. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

Procedural Controls

  1. Unless stated otherwise, the requirements in this section apply equally to all PKI CAs. In addition to the Procedural Controls guidance defined within this IRM, as found in the Treasury CP, requirements for the following control areas shall be implemented in accordance with Department of the Treasury PKI X.509 Certificate Policy.

    • Training Requirements

    • Retraining Frequency and Requirements

    • Job Rotation Frequency and Sequence

    • Sanctions for Unauthorized Access

Number of Persons Required Per Task
  1. There are no tasks associated with the OLT PKI that require multi-person control. (IRS-defined)

Identification and Authentication for Each Role
  1. Trusted roles are required to authenticate to the CA prior to performing any tasks on the CA. No individual shall have more than one identity on the CA. (IRS-defined)

  2. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

Separation of Roles
  1. A single individual may assume both the Officer and Administrator roles. No one individual shall assume both a CA Operator role and an Auditor role. (IRS-defined)

  2. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

Personnel Controls

  1. The following personnel controls within the following sections, as found in the Treasury CP, apply. In addition to the Personnel Controls guidance defined within this IRM, requirements for the following control areas shall be implemented in accordance with Department of the Treasury PKI X.509 Certificate Policy.

    • Training Requirements

    • Retraining Frequency and Requirements

    • Job Rotation Frequency and Sequence

    • Sanctions for Unauthorized Access

    • Documentation Supplied to Personnel

Background, Qualifications, Experience and Security Clearance Requirements
  1. Persons filling trusted roles in an OLT PKI are selected on the basis of loyalty, trustworthiness, and integrity. Trusted persons may be Department of the Treasury direct-hire personnel or contractors. Only US Citizens may fill trusted roles. Persons filling trusted roles shall (IRS-defined):

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

    • Have not been previously relieved of CA-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 OLT MA.

  2. For additional personnel security requirements, refer to IRM 10.8.1 and the 10.23 Personnel Security IRM series for additional personnel security guidance. (IRS-defined)

Background Check Controls

  1. OLT Trusted Roles shall pass, at a minimum, a background investigation covering the following areas (IRS-defined):

    • Education

    • Place of Residence

    • Law Enforcement

    • References

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

  3. A competent adjudication authority shall perform adjudication of the background investigation. (IRS-defined)

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.

Audit Logging Requirements

  1. The following audit logging controls within the following sections, as found in the Treasury CP, apply. In addition to the Audit Logging Requirements guidance defined within this IRM requirements for the following control areas shall be implemented in accordance with Department of the Treasury PKI X.509 Certificate Policy.

    • Audit Log Backup Requirements

    • Audit Collection System

    • Notification to Event-causing Subject

    • Vulnerability Assessments

Types of Events Recorded
  1. Audit Logging requirements are defined in IRM 10.8.1 and the table below

    Auditable Events (Logged either electronically or manually) OLT PMA Auditor/or Script Required
    SECURITY AUDIT
    Any changes to the Audit parameters, e.g., audit frequency, type of event audited X  
    Any attempt to delete or modify the Audit logs X  
    Obtaining a third-party time-stamp X  
    IDENTIFICATION AND AUTHENTICATION
    Successful and unsuccessful attempts to assume a role X  
    The value of maximum authentication attempts is changed X  
    Maximum authentication attempts unsuccessful authentication attempts occur during user login X  
    An Administrator unlocks an account that has been locked as a result of unsuccessful authentication attempts X  
    An Administrator changes the type of authenticator, e.g., from password to biometrics X  
    LOCAL DATA ENTRY
    All security-relevant data that is entered in the system X  
    REMOTE DATA ENTRY
    All security-relevant messages that are received by the system X  
    DATA EXPORT AND OUTPUT
    All successful and unsuccessful requests for confidential and security-relevant information X  
    KEY GENERATION
    Whenever the CA generates a key. (Not mandatory for single session or one-time symmetric keys) X X
    PRIVATE KEY LOAD AND STORAGE
    The loading of Component private keys X X
    All access to certificate subject private keys retained by the CA, RA, or LRA for key recovery purposes X  
    TRUSTED PUBLIC KEY ENTRY, DELETION, AND STORAGE
    All changes to the trusted public keys, including additions and deletions X X
    SECRET KEY STORAGE
    The manual entry of secret keys used for authentication    
    PRIVATE AND SECRET KEY EXPORT
    The export of private and secret keys (keys used for a single session or message are excluded) X X
    CERTIFICATE REGISTRATION
    All certificate requests and handling X  
    CERTIFICATE REVOCATION
    All certificate revocation requests and handling X  
    ESCROWED KEY RECOVERY REQUESTS
    All escrowed key recovery requests and handling` X  
    CERTIFICATE STATUS CHANGE APPROVAL
    The approval or rejection of a certificate status change request X  
    CA, RA or LRA CONFIGURATION
    Any security-relevant changes to the configuration of the CA or the RA X  
    ACCOUNT ADMINISTRATION
    Roles and users are added or deleted The access control privileges of a user account or a role are modified X  
    The access control privileges of a user account or a role are modified X  
    CERTIFICATE PROFILE MANAGEMENT
    All changes to the certificate profile X  
    CERTIFICATE REVOCATION LIST PROFILE MANAGEMENT
    All changes to the certificate revocation list profile X  
    MISCELLANEOUS
    Appointment of an individual to a Trusted Role X  
    Installation of the Operating System X  
    Installation of CA,, RA, or LRA Application X  
    Installing hardware cryptographic modules    
    Removing hardware cryptographic modules    
    Destruction of cryptographic modules X  
    System Startup X  
    Designation of personnel for multiparty control X  
    Logon Attempts on CA, RA, or LRA Applications X  
    Receipt of Hardware / Software    
    Attempts to set passwords X  
    Attempts to modify passwords X  
    Backing up CA, RA. or LRA internal database X  
    Restoring* CA, RA, LRA internal database (*Auditor present with scripts for COOP Drills and Designated CA Disaster Recovery Events only. Auditor not required for high availability or normal switch over of services between facilities)   X
    File manipulation (e.g., creation, renaming, moving)    
    Posting of any material to a repository    
    Access to CA, RA, or LRA internal database    
    All certificate compromise notification requests X  
    Loading tokens with certificates    
    Shipment of Tokens X  
    Zeroize tokens X  
    Rekey of the CA X X
    CONFIGURATION CHANGES TO THE CA SERVER, RA, OR LRA INVOLVING
    Hardware X  
    Software X  
    Operating System X  
    Patches X  
    Security Profiles    
    PHYSICAL ACCESS/ SITE SECURITY
    Personnel Access to room housing CA    
    Access to the CA server    
    Known or suspected violations of physical security X  
    ANOMALIES
    Software Error conditions X  
    Software check integrity failures X  
    Receipt of improper messages    
    Misrouted messages    
    Network attacks (suspected or confirmed) X  
    Equipment failure X  
    Electrical Power Outages    
    Uninterruptible Power Supply (UPS) failure    
    Obvious and significant network service or access failures    
    Violations of Certificate Policy X  
    Violations of Certification Practice Statement X  
    Resetting Operating System clock X  
Frequency of Processing Log
  1. OLT CA audit logs shall be reviewed for cause or as mandated by Treasury security policy, at a minimum. The review shall be performed by a security Auditor appointed by the OLT MA. (IRS-defined)

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

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 Records Archived
  1. Archive requirements are defined in the table below. For addition requirements, refer to IRM 10.8.1

    Data to be Archived OLT
    CA accreditation (if applicable) X
    Certificate Policy and Certification Practice Statement X
    Any contractual agreements (as appropriate) to which the CMA is bound, and other agreements concerning operations of the CA X
    System and equipment configuration X
    Modifications and updates to system, configuration, documentation (e.g., CPS), and contractual agreements X
    Certificate issuance, suspension, restoration and key recovery requests X
    Certificate Revocation requests X
    Documentation of receipt and acceptance of certificates X
    Documentation of receipt of tokens X
    All certificates issued or published X
    Record of CA Rekey and/or notification of cross-certified CA Rekey in accordance with applicable MOAs X
    All CRLs issued and/or published X
    All Audit Logs, and security audit data and reports X
    Other data or applications to verify archive contents X
    All CA operations communications and documentation to the PMA, PKI PA, other CMAs, and compliance auditors X
    Compliance Auditor reports X
Retention Period for Archive
  1. Archive records shall be retained as specified in the General Records Schedule established by the National Archives and Records Administration or an agency specific schedule as applicable. (IRS-defined)

Protection of Archive
  1. OLT Archive data shall be protected in accordance with Treasury records retention policies and procedures. (IRS-defined)

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

Requirements to Obtain and Verify Archive Information
  1. Refer to the 1.15.x series for record retention requirements. (IRS-defined)

Compromise and Disaster Recovery

  1. In the event an OLT PKI CA is suspected of being compromised or otherwise unable to operate, the OLT MA shall declare the CA revoked and immediately reestablish the CA and subordinate CAs if applicable. Subscribers will be required to obtain new certificates. (IRS-defined)

  2. Refer to IRM 10.8.1, IRM 10.8.60 IT 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.

CA and RA Termination

  1. If an OLT CA is terminated for convenience prior to the expiration of its signing certificate, the CA shall be considered compromised and, if required, replaced as specified in Section 5.7 of the Treasury PKI x509 Certificate Policy. (IRS-defined)

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. In addition to the Technical Security Controls guidance defined within this IRM, as found in the Treasury CP, requirements for the following control areas shall be implemented in accordance with Department of the Treasury PKI X.509 Certificate Policy.

    • Key Pair Generation and Installation

    • Key Pair Generation

    • Subscriber Key Pair Generation

    • Private Key Delivery to Subscriber

    • Public Key Delivery to Certificate Issuer

    • CA Public Key Delivery to Relying Parties

    • Key Sizes

    • Public Key Parameters Generation and Quality Checking

    • Key Usage Purposes (as per X.509 v3 Key Usage field)

    • Private Key Backup

    • Backup of TRCA and Subordinate CA Private Signature Keys

    • Backup of Subscriber Private Signature Key

    • Backup of Certificate Status Servers (CSS) Private Key

    • Backup of Device Private Keys

    • Private Key Archival

    • Private Key Transfer into or from a Cryptographic Module

    • Private Key Storage on Cryptographic Module

    • Requirements for Activating Private Keys

    • Requirements for Deactivating Private Keys

    • Requirements for Destroying Private Keys

    • Other Aspects of Key Management

    • Certificate Operational Periods/Key Usage Periods

    • Activation Data

    • Activation Data Generation and Installation

    • Activation Data Protection

    • Other Aspects of Activation Data

    • Specific Computer Security Technical Requirements

    • Computer Security Rating System Development Controls

    • Security Management Controls

    • Lifecycle Security Ratings

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

CA Key Pair Generation

  1. An OLT CA shall generate cryptographic keying material used to sign certificates, CRLs or status information in FIPS 140 validated cryptographic modules. (IRS-defined)

  2. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

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 minimum level of FIPS validation for an OLT CA is Level 1 (Hardware or Software). At some time in the future, there may be a requirement to move to Level 2 (Hardware) and OLT CAs are encouraged to use a Level 2 or higher module if possible. (IRS-defined)

  2. Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

Private Key Multi-Person Control
  1. No multiparty control is required (IRS-defined)

Private Key Escrow
  1. The following private key escrow requirements, as found in the Treasury CP, apply. In addition to the Private Key Escrow guidance defined within this IRM requirements for the following control areas shall be implemented in accordance with Department of the Treasury PKI X.509 Certificate Policy.

    • Escrow of TRCA and Subordinate CA Private Signature Keys

    • Escrow of CA Encryption Keys

    • Escrow of Subscriber Private Signature Keys

    • Escrow of Subscriber Private Encryption and Dual Use Keys

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.

Public Key Archival

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

Computer Security Controls

  1. Computer security controls for OLT PKI CA equipment shall be consistent with the security provided to the servers that provide network security and administration support (e.g., Microsoft Domain Controllers) to the local environment. (IRS-defined)

Life-Cycle Security Controls

  1. PKI systems shall comply with IRM 10.8.1 requirements for System and Service Acquisition.

  2. Life-cycle security controls for OLT PKI CA equipment shall be consistent with the security provided to the servers that provide network security and administration support (e.g., Microsoft Domain Controller) to the local environment. (IRS-defined)

Network Security Controls

  1. Network security controls for OLT PKI CA equipment shall be consistent with the security provided to the servers that provide network security and administration support (e.g., Microsoft Domain Controller) to the local environment. (IRS-defined)

  2. (2) Refer to Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy for additional requirements.

Activation Data

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Activation Data Generation and Installation
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Activation Data Protection
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Other Aspects of Activation Data
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Computer Security Controls

  1. Computer security controls for OLT PKI CA equipment shall be consistent with the security provided to the servers that provide network security and administration support (e.g., Microsoft Domain Controllers) to the local environment.

  2. The computer security control requirements in the following subsections apply.

Specific Computer Security Technical Requirements
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Computer Security Rating
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Life-Cycle Security Controls

  1. PKI systems shall comply with IRM 10.8.1 requirements for System and Service Acquisition.

  2. Life-cycle security controls for OLT PKI CA equipment shall be consistent with the security provided o the servers that provide network security and administration support (e.g., Microsoft Domain Controller) to the local environment.

System Development Controls
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Security Management Controls
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Lifecycle Security Ratings
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Network Security Controls

  1. Network security controls for OLT PKI CA equipment shall be consistent with the security provided to the servers that provide network security and administration support (e.g., Microsoft Domain Controller) to the local environment.

Certificate, CARL/CRL, and OCSP Profiles Format

  1. The profile format requirements in the following subsections, as found in the Treasury CP, apply. In addition to the Certificate, CARL/CRL, and OCSP Profiles Format guidance defined within this IRM requirements for the following control areas shall be implemented in accordance with Department of the Treasury PKI X.509 Certificate Policy.

    • Version Numbers

    • Certificate Extensions

    • Algorithm Object Identifiers

    • Name Forms

    • Name Constraints

    • Certificate Policy Object Identifier

    • Usage of Policy Constraints Extension

    • Policy Qualifiers Syntax and Semantics

    • Processing Semantics for the Critical Certificate Policy Extension

    • Online Certificate Status Profile (OSCP)

    • Version Number and Entry Extensions

    • OSCP Extensions

Certificate Profile

  1. OLT PKI certificate should conform to [FPKI-Prof] but may deviate as necessary to meet operational requirements. The OLT MA shall provide a copy of certificate profiles that deviate from [FPKI-Prof] to the Treasury PMA prior to implementing the profile in operational certificates. (IRS-defined)

CRL Profile

  1. The following CRL policy requirements, as found in the Treasury CP, apply. In addition to the CRL Profile guidance defined within this IRM requirements for the following control areas shall be implemented in accordance with Department of the Treasury PKI X.509 Certificate Policy.

    • Version Numbers

    • CRL Entry Extensions

Compliance Audits and Other Assessments

  1. The following Compliance Audits and Other Assessments policy requirements, as found in the Treasury CP, apply. In addition to the Compliance Audits and Other Assessments guidance defined within this IRM requirements for the following control areas shall be implemented in accordance with Department of the Treasury PKI X.509 Certificate Policy.

    • Identity and Qualifications of Assessor

    • Assessor’s Relationship to Assessed Entity

    • Actions Taken as a Result of Deficiency

    • Communication Results

Frequency of Audits or Assessments

  1. OLT PKI CAs shall undergo a compliance audit by a PMA approved auditor at least every 3 years. (IRS-defined)

Topics Covered by Assessment

  1. The OLT PKI compliance audit shall cover those aspects of PKI operations of the OLT CA not covered by the security review. (IRS-defined)

Other Business and Legal Matters

  1. The other business and legal matters in the following subsections, as found in the Treasury CP, apply. In addition to the Other Business and Legal Matters guidance defined within this IRM requirements for the following control areas shall be implemented in accordance with Department of the Treasury PKI X.509 Certificate Policy.

    • Fees

    • Certificate Issuance/Renewal Fees

    • Certificate Access Fees

    • Revocation or Status Information Access Fee

    • Fees for Other Services Refund Policy

    • Financial Responsibility

    • Issuance Coverage

    • Other Assets

    • Insurance/Warranty Coverage for End-Entities

    • Confidentiality of Business Information

    • Scope of Confidential Information

    • Information Not Within the Scope of Confidential

    • Information Responsibility to Protect Confidential

    • Information Privacy of Personal Information

    • Information Treated as Private

    • Information not Deemed Private

    • Notice and Consent to Use Private Information

    • Disclosure Pursuant to Judicial/Administrative Process

    • Other Information Disclosure Circumstances

    • Intellectual Property Rights Representations and Warranties

    • CA Representations and Warranties

    • RA Representations and Warranties

    • Subscriber Representations and Warranties

    • Relying Parties Representations and Warranties

    • Representations and Warranties of Other Participants

    • Disclaimers of Warranties

    • Limitation of Liability

    • Indemnities

    • Individual Notices and Communications with Participants

    • Amendments

    • Procedure for Amendment

    • Notification Mechanism and Period

    • Dispute Resolution Provisions

    • Governing Law

    • Other Provisions

    • Miscellaneous Provisions

    • Entire Agreement

    • Assignment

    • Severability Enforcement (Attorney Fees/Waiver of Rights)

    • Force Majeure

Privacy Plan

  1. See IRM 10.8.1 and IRM 10.5.1, Privacy and Information Protection for privacy plan requirements

Responsibility to Protect Private Information

  1. See IRM 10.5.1 for privacy protection responsibilities and requirements.

Compliance with Applicable Law

  1. All CAs shall comply with applicable law.

Financial Responsibility

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Issuance Coverage
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Other Assets
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Insurance/Warranty Coverage for End-Entities
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Confidentiality of Business Information

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Scope of Confidential Information
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Information Not Within the Scope of Confidential Information
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Responsibility to Protect Confidential Information
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Privacy of Personal Information

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

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. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Information not Deemed Private
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

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. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Disclosure Pursuant to Judicial/Administrative Process
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

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. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

CA Representations and Warranties
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

RA Representations and Warranties
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Subscriber Representations and Warranties
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Relying Parties Representations and Warranties
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Representations and Warranties of Other Participants
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Disclaimers of Warranties

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Limitation of Liability

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Indemnities

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Individual Notices and Communications with Participants

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Amendments

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Procedure for Amendment
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

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. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Dispute Resolution Provisions

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Governing Law

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

  2. 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. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Miscellaneous Provisions

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Entire Agreement
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

  2. This CP makes no stipulation.

Assignment
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Severability
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Enforcement (Attorney Fees/Waiver of Rights)
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Force Majeure
  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

Other Provisions

  1. For more information see Department of the Treasury Public Key Infrastructure (PKI) X.509 Certificate Policy.

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

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

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

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

(4) 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
{joint-iso-ccitt (2) country (16) us (840) organization (1) gov (101) csor (3) pki (2) cert-policy (1) treasury-policies (5) id-treacertpcy-internalnpe (9)} OID for Device Certificate Identity for a Non-Person Entity
{joint-iso-ccitt (2) country (16) us (840) organization (1) gov (101) csor (3) pki (2) cert-policy (1) treasury-policies (5) treasury-certpcy-internalperson (14)} OID for a Person Certificate Identity for an individual
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     

(2) This policy addendum specifies a single level of assurance, defined in subsequent sections as “OLT.” This level of assurance has an object identifier (OID) that will be asserted in certificates issued by CAs who comply with the policy stipulations herein. The OID will be registered under the id-infosec arc as (IRS-defined):

{joint-iso-ccitt (2) country (16) us (840) organization (1) gov (101) csor (3) pki (2) cert-policy (1) treasury-policies (5) id-treacertpcy-internalnpe (9)}, or {joint-iso-ccitt (2) country (16) us (840) organization (1) gov (101) csor (3) pki (2) cert-policy (1) treasury-policies (5) treasury-certpcy-internalperson (14)},

Note:

The above requirement is intended for planning purposes only and will become effective at a future date based on the effective date of the Treasury X.509 Certificate Policy addendum

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
   
AIS Automated Information System
AO Authorizing Official
   
Authentication Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual’s identity.
   
   
   
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
   
End Entity Certificate (EEC) A certificate belonging to a non-CA entity, e.g. you, me or the computer, firewall.
EOps Enterprise Operations
Encypherment Convert (a message or piece of text) into a coded form
ESP Enterprise Standards Profile
   
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
   
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.
   
   
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
   
   
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.
OLT Only Locally Trusted
OSCP Online Certificate Status Protocol
   
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.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

  • IRM 10.8.32 - Information Technology (IT) Security, International Business Machines (IBM) Mainframe System Security Requirements

Treasury

  • Department of Treasury Public Key Infrastructure(PKI) X.509 Certificate Policy, Version 2.9, March 15, 2017

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, January 2015

  • NIST SP 800-73-4, Interfaces for Personal Identity Verification, May 2015 (Update 02-08-2016)

  • 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

  • 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 1.24, May 7, 2015