10.8.52  PKI Security Policy

Manual Transmittal

July 24, 2013

Purpose

(1) This transmits revised Internal Revenue Manual (IRM) 10.8.52, Information Technology (IT) Security, PKI Security Policy.

Background

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.

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

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

Material Changes

(1) The following sections have been updated/clarified with this version of policy:

  1. Restructured Manual Transmittal, introductory sections, Risk Acceptance and Risk-Based Decisions section, and Glossary and Acronyms (combined) to match standardized Security Policy language.

  2. Updated links throughout the document to reflect new organizational links.

  3. Effective July 1, 2012, the Modernization and Information Technology Service (MITS) organization changed its name to IRS Information Technology (IT). All instances of MITS within this IRM have been updated to IRS Information Technology organization to reflect the change. (Link to IT website communication is: http://it.web.irs.gov/ProceduresGuidelines/ITNameChange.htm)

(2) The following sections have been revised with this version of policy:

  • 10.8.52.1.1, Purpose

  • 10.8.52.1.2, Authority

  • 10.8.52.1.3, Scope

  • 10.8.52.1.4, Risk Acceptance and Risk Based Decisions

  • 10.8.52.2, Roles and Responsibilities

  • 10.8.52.2.1, Treasury Policy Management Authority (PMA)

  • 10.8.52.2.2, IRS PKI Program Management Office (PMO)

  • 10.8.52.2.3, PKI Operations Program Manager

  • 10.8.52.2.5, PKI Operational Staff

  • 10.8.52.2.6, Registration Authority/Local Registration Authority

  • 10.8.52.2.7, Subscribers

  • 10.8.52.2.8, Relying Parties

  • 10.8.52.3.2.1, Treasury and IRS Root Certification Authority

  • 10.8.52.3.2.2, Treasury and IRS Subordinate Certification Authorities

  • 10.8.52.3.2.3, Certificate Status Servers

  • 10.8.52.4.2, Certificate Lifecycle Operational Requirements

  • 10.8.52.4.2.6, Certificate Renewal, and subsections

  • 10.8.52.4.2.7, Certificate Rekey

  • 10.8.52.4.2.8, Certificate Modification, and subsections

  • 10.8.52.4.2.9, Certificate Revocation and Suspension

  • 10.8.52.5.1, Personnel Security – Background Investigations

  • 10.8.52.5.2.1, Physical Security

  • 10.8.52.5.2.2, Environmental Controls

  • 10.8.52.6.1.3, CA Key Pair Generation

  • 10.8.52.6.1.4, Subscriber Key Pair Generation

  • 10.8.52.6.1.6, Public Key Delivery to Certificate Issuer

  • 10.8.52.6.1.7, Key Sizes

  • 10.8.52.6.1.8, Key Changeover

  • 10.8.52.6.1.9, Public Key Parameters Generation and Quality Checking

  • 10.8.52.6.1.10, Key Usage Purposes (as per X.509 v3 key usage field)

  • 10.8.52.6.1.15, CA Public Key Delivery to Relying Parties

  • 10.8.52.6.2.1, Naming, and subsections

  • 10.8.52.6.2.2, Initial Identity Validation, and subsections

  • 10.8.52.6.2.3, Identification and Authentication for Routine Rekey, and subsections

  • 10.8.52.6.2.4, Identification and Authentication for Revocation Request

  • 10.8.52.6.4, Audit and Accountability

  • Exhibit 10.8.52-1, Glossary

  • Exhibit 10.8.52-2, References

(3) The following sections have been added with this version of policy:

  • 10.8.52.2.1.1, IRS Policy Management Authority (PMA)

  • 10.8.52.2.4, Treasury PKI Operational Authority

  • 10.8.52.2.10, Trusted Roles, and subsections

  • 10.8.52.6.1.11, Other Aspects of Key Management, and subsections

  • 10.8.52.3.1, Certificate Usage, and subsections

  • 10.8.52.3.3.4, Repositories

  • 10.8.52.4.1.1, System Development Controls

  • 10.8.52.4.1.2, Security Management Controls

  • 10.8.52.4.1.3, Lifecycle Security Ratings

  • 10.8.52.4.2.1, Certificate Lifecycle Application, and subsections

  • 10.8.52.4.2.2, Certificate Application Processing, and subsections

  • 10.8.52.4.2.3, CA Actions during Certificate Issuance

  • 10.8.52.4.2.4, Certificate Acceptance, and subsections

  • 10.8.52.4.2.5, Key Pair and Certificate Usage

  • 10.8.52.4.3, Privacy

  • 10.8.52.4.4, Compliance Audits and other Assessments, and subsections

  • 10.8.52.4.5, Certificate Profile, and subsections

  • 10.8.52.4.6, CRL Profile Version Number and Entry Extensions

  • 10.8.52.4.7, OCSP Profile, and subsections

  • 10.8.52.5.3.1, Incident and Compromise Handling Procedures

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

  • 10.8.52.5.3.3, Entity (CA) Procedures

  • 10.8.52.5.3.4, Business Continuity Capabilities after a Disaster

  • 10.8.52.5.4, CA & RA Termination

  • 10.8.52.6.1.1, Private Key Protection and Cryptographic Module Engineering Controls, and subsections

  • 10.8.52.6.1.5, Private Key Delivery to Subscriber

  • 10.8.52.6.1.13, Private Key Backup, and subsections

  • 10.8.52.6.1.14, Private Key Archival, and subsections

  • 10.8.52.6.3, Activation Data, and subsections

  • 10.8.52.6.4.1, Audit Logging Procedures, and subsections

  • 10.8.52.6.4.2, Certificate Authority (CA) Archive

  • 10.8.52.5.4.3, Time Stamping

  • 10.8.52.5.5.2, Specific Computer Security Technical Requirements

(4) The following sections have been deleted with this version of policy:

  • 10.8.52.3.2.7, Key Escrow and Recovery

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

Effect on Other Documents

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

Audience

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

Effective Date

(07-24-2013)

Terence V. Milholland
Chief Technology Officer

10.8.52.1  (07-24-2013)
Overview

  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.

10.8.52.1.1  (07-24-2013)
Purpose

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

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

    2. Prevent unauthorized access to IRS assets.

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

  2. Specifically, the PKI program in the IRS:

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

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

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

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

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

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

10.8.52.1.2  (07-24-2013)
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 or Bureau-approved PMAs 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 must be approved by the Treasury PMA.

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

10.8.52.1.3  (07-24-2013)
Scope

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

  2. The provisions in this manual apply to:

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

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

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

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

  4. The IRS shall ensure the application or system version is a version for which the vendor still offers standardized technical support.

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

10.8.52.1.4  (07-24-2013)
Risk Acceptance and Risk Based Decisions

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

  2. Risk-Based Decision requests shall be submitted in accordance with IRM 10.8.1 and use Form 14201, as described in Risk Acceptance Request and Risk-Based Decision standard operating procedures (SOPs), available on the Enterprise FISMA Compliance SharePoint site via the Risk Acceptance Requests link at:
    http://it.web.irs.gov/cybersecurity/Divisions/SRM/Policy_Guidance/risk_acceptance.htm.

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

10.8.52.2  (07-24-2013)
Roles and Responsibilities

  1. IRM 10.8.2, Information Technology 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 requirements provided below are specific to the implementation of the IRS’s PKI program.

10.8.52.2.1  (07-24-2013)
Treasury Policy Management Authority (PMA)

  1. All aspects of the Treasury Policy Management Authority (PMA) resides in the Office of Cybersecurity, Office of the Chief Information Officer (OCIO) for Treasury. The Treasury PMA provides management authority over Treasury’s PKIs. 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 Practice Statement (CPS) issued and maintained in support of the Treasury Certification Authority (TCA).

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

    4. Oversight compliance management of the TCA and all Treasury Certificate Authorities (CAs) signed by the Treasury Root Certificate Authority (TRCA).

    5. Internal Auditing and compliance oversight of TCA operations.

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

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

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

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

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

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

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

    Note:

    The PMA guidance stated above comes directly from Department of the Treasury PKI policy.

10.8.52.2.2  (07-24-2013)
IRS PKI Program Management Office (PMO)

  1. The 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., GAO and 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 Standard Operating Procedures (SOPs) for the management and secure operation of the PKI program and assets per IRM 10.8.1.

  4. Refer to IRM 10.8.2, IT Security Roles and Responsibilities, for additional information on the role of the PMO.

  5. For additional information regarding the PKI PMO and SOPs, please visit the IRS IT Security Projects Office website at:
    http://it.web.irs.gov/Cybersecurity/Divisions/Architecture_Implement/projects_office.htm
    or contact the PMO through the *IT PKI Management Solutions mailbox.

10.8.52.2.3  (07-24-2013)
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., 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.

    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 *IT ACIOEOPS OSPMO mailbox.

10.8.52.2.4  (07-24-2013)
Treasury PKI Operational Authority

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

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

  3. The PKI OA is responsible for the following:

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

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

  4. The PKI OA established the PKI Program Team.

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

    Note:

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

10.8.52.2.5  (07-24-2013)
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 (i.e., C&A) activities, in accordance with IRM 10.8.1.

    7. Create and revise 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 policy 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.

10.8.52.2.6  (07-24-2013)
Registration Authority/Local Registration Authority

  1. The IRS RA and 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 PKI Certificate Authorities (CAs).

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

  3. The EOps 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 must 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 Agents), 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.

10.8.52.2.7  (07-24-2013)
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. IRS PKI Subscribers include but are not limited to the following categories of entities that may wish to conduct official Department business:

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

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

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

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

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

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

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

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

10.8.52.2.8  (07-24-2013)
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 Certificate Policy 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, FBCA, or another Entity CA.

  5. Applications intended partly for the use of users or systems from outside the direct control of the IRS or Treasury may accept certificates issued by companies or agencies which have been cross-certified with the Federal Bridge. IRS applications (exclusive of mail servers) may not accept certificates issued by companies or agencies which have not been cross-certified with the Federal Bridge as identification for users, devices, or systems, unless the entity issuing the certificate is under the direct control of the IRS or another Treasury office or bureau (see Federal Public Key Infrastructure Policy Authority (FPKIPA) website at:
    http://www.idmanagement.gov/custom-block/approved-identity-provider-list,
    for updated list of entities cross-certified with the Federal Bridge Certificate Authority (FBCA)).

10.8.52.2.9  (07-24-2013)
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.

10.8.52.2.10  (07-24-2013)
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 must 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.

10.8.52.2.10.1  (07-24-2013)
Administrator

  1. The Administrator role is responsible for the following:

    • Installation, configuration, and maintenance of the CA.

    • Establishing and maintaining CA system accounts.

    • Configuring certificate profiles or templates and audit parameters.

    • Generating and backing up CA keys.

  2. Administrators do not issue certificates to Subscribers.

10.8.52.2.10.2  (07-24-2013)
Officer

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

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

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

    • Approving and executing the issuance of certificates.

    • Requesting, approving and executing the revocation of certificates.

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

10.8.52.2.10.3  (07-24-2013)
Auditor

  1. The Auditor role is responsible for the following:

    • Reviewing, maintaining, and archiving audit logs.

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

10.8.52.2.10.4  (07-24-2013)
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.

10.8.52.3  (07-24-2013)
General Controls

  1. The IRS shall ensure all PKI components have met the requirements in IRM 10.8.1 and the respective IRM policies applicable to the underlying operating system.

  2. At a minimum, Certification Practices Statement (CPS) shall define:

    1. How keys and certificates are generated, disseminated, stored, revoked, archived, and managed.

    2. How users identify themselves to a CA.

    3. Operational procedures, including system backup, recovery, and audit.

    4. Physical, procedural, and personnel security controls.

    5. Any third-party reviews or audits.

    6. Incident and security response procedures (which must address the termination or compromise of a CA/registration authority Registration Authority [RA] key).

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

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

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

    3. Non Person Entities (NPE) such as: workstations, guards and firewalls, routers, trusted servers, applications and other infrastructure components. These components must 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.

10.8.52.3.1  (07-24-2013)
Certificate Usage

  1. Certificates shall not have an infinite lifetime and shall be subject to expiration.

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

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

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

  4. The following sections describe appropriate and prohibited certificate usage.

10.8.52.3.1.1  (07-24-2013)
Appropriate Certificate Usage

  1. The sensitivity of the information processed or protected using certificates issued by the TCA may vary significantly. Relying Parties should evaluate the environment and the associated threats and vulnerabilities and determine the level of risk they are willing to accept based on the sensitivity or significance of the information. Each Relying Party makes this evaluation for its application outside the control of this CP. To provide sufficient granularity, this CP specifies security requirements at five increasing, qualitative levels of assurance: Rudimentary, Basic, Medium, Medium Hardware, and High. The TRCA will issue at least one High assurance certificate, so the TRCA will operate at that level.

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

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

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

    Assurance Level Appropriate Certificate Uses
    Rudimentary This level provides the lowest degree of assurance concerning identity of the individual. One of the primary functions of this level is to provide data integrity to the digitally signed information. This level is relevant to environments in which the risk of malicious activity is considered low. It is not suitable for transactions requiring authentication, and is generally insufficient for transactions requiring confidentiality, but may be used for the latter where certificates having higher levels of assurance are unavailable.
    Basic This level provides a basic level of assurance relevant to environments where there are risks and consequences of data compromise, but which are not considered to be of major significance. This may include access to private information where the likelihood of malicious access is not high. This security level assumes that subscribers are not likely to be malicious.
    Medium This level is relevant to environments where risks and consequences of data compromise are moderate. This may include transactions having substantial monetary value or risk of fraud, or involving access to private information where the likelihood of malicious access is substantial.
    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:

    • Digital signature services (authentication and data integrity).

    • Protection (confidentiality).

    • Technical non-repudiation.

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

10.8.52.3.1.2  (07-24-2013)
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, such as:

      • 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 must state this 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.

10.8.52.3.2  (07-24-2013)
IRS PKI Authorities

  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.

10.8.52.3.2.1  (07-24-2013)
External

  1. Externally, Treasury PKI has a TRCA.

    1. Any additional Certificate Authorities (CAs) within Treasury are subordinated to TRCA.

    2. External Treasury CAs operate under approved Treasury Certificate Policy (CP) and Certification Practices Statement (CPS).

    3. TRCA is cross-certified with the Federal Bridge Certificate Authority (FBCA).

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

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

    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), and high (Level 4) 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.

10.8.52.3.2.2  (07-24-2013)
Internal

  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 IRS PKI Certificate Authorities (CAs) shall operate under an approved Certificate Policy (CP) and Certification Practices Statement (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 IRS Certificate Authority (CA) shall operate at a Basic (Level 2) level of assurance and issue certificates for Basic levels of assurance.

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

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

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

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

10.8.52.3.3  (02-28-2011)
Other PKI Authorities

  1. Other PKI authorities include the following:

10.8.52.3.3.1  (07-24-2013)
Treasury and IRS Root Certification Authority

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

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

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

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

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

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

10.8.52.3.3.2  (07-24-2013)
Treasury and IRS Subordinate Certification Authorities

  1. Treasury’s Subordinate CAs are responsible for all aspects of the issuance and management of an external certificate 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. An IRS 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 RAs/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.

10.8.52.3.3.3  (07-24-2013)
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 the Certificate Status Servers (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 Certificate Status Server (CSS) shall assert all the policy Object Identifiers (OIDs) for which it is authoritative.

10.8.52.3.3.4  (07-24-2013)
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:

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

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

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

10.8.52.4  (02-28-2011)
Management Controls

  1. Management security controls shall be implemented to mitigate risk of IT systems and electronic information loss in order to protect the organization’s mission. See IRM 10.8.1 for general information on computer security management control requirements.

10.8.52.4.1  (02-28-2011)
System and Services Acquisition

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

  2. Additional requirements specific for PKI system are specified below:

    1. Hardware and software procured to operate the CA shall be purchased in a fashion to reduce the likelihood that any particular component was tampered with (e.g., by ensuring the vendor cannot identify the PKI component that will be installed on a particular device).

    2. Hardware and software developed specifically for the Certificate Authority (CA) shall be developed in a controlled environment, and the development process shall be defined and documented. This requirement does not apply to commercial off-the-shelf hardware or software.

    3. The CA hardware and software shall be dedicated to performing one task: the Certificate Authority (CA). There shall be no other applications, hardware devices, network connections, or component software installed that are not parts of the Certificate Authority (CA) operation. Where the Certificate Authority (CA) operation supports multiple Certificate Authorities (CAs), the hardware platform may support multiple Certificate Authorities (CAs).

    4. Proper care shall be taken to prevent malicious software from being loaded onto the Certificate Authority (CA) equipment. All applications required to perform the operation of the Certificate Authority (CA) shall be obtained from documented sources. Registration Authority (RA) hardware and software shall be scanned for malicious code on first use and periodically thereafter.

  3. See IRM 10.8.1 for additional system and services acquisition requirements.

10.8.52.4.1.1  (07-24-2013)
System Development Controls

  1. The System Development Controls for the TRCA and subordinate CAs at the Basic Assurance level and above are as follows:

    • The CAs shall use software designed and developed under a formal, documented development methodology.

    • The CA shall use hardware and software specifically developed in a controlled environment; and the CMA shall define and document the development process. This requirement does not apply to commercial off-the-shelf (COTS) hardware or software.

    • Where developers use open source software, the developer/vendor shall demonstrate that security requirements were achieved through software verification & validation and structured development/life-cycle management.

    • The PKI Program Team shall procure hardware and software to operate the CA in a fashion to reduce the likelihood of tampering with any particular component (e.g., by ensuring the random selection of material at time of purchase).

    • The PKI Program Team shall dedicate CA hardware and software to performing one task: operation and management of the CA. There shall be no other applications, hardware devices, network connections, or component software installed that are not part of the CA operation.

    • The PKI Program Team shall take proper care to prevent malicious software from being loaded onto the CA equipment. RA hardware and software shall be similarly limited and scanned for malicious code on first use and continuously thereafter.

    • Hardware and software updates shall be purchased or developed in the same manner as original equipment, and shall be installed by trusted and trained personnel in a defined manner.

10.8.52.4.1.2  (07-24-2013)
Security Management Controls

  1. The PKI Program Team shall document and control the configuration of all CA systems as well as any modifications and upgrades.

  2. There shall be a mechanism for detecting unauthorized modification to the CA software or configuration.

  3. The PKI Program Team shall use Treasury’s formal configuration management methodology, through the IT-CCB, for installation and ongoing maintenance of the Treasury PKI CA systems.

  4. The PKI OA shall verify the CA software, when first loaded, as that supplied from the vendor, with no modifications, and the version intended for use.

  5. The operator shall verify the integrity of CA software at least weekly.

10.8.52.4.1.3  (07-24-2013)
Lifecycle Security Ratings

  1. This CP makes no stipulation.

10.8.52.4.2  (07-24-2013)
Certificate Lifecycle Operational Requirements

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

10.8.52.4.2.1  (07-24-2013)
Certificate Lifecycle Application

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

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

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

10.8.52.4.2.1.1  (07-24-2013)
Submission of Certificate Application

  1. For the TRCA, the Treasury PMA shall submit the certificate application to the FPKIPA.

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

10.8.52.4.2.1.2  (07-24-2013)
Enrollment Process and Responsibilities

  1. Within Treasury, only the TRCA shall apply for cross certification with the FBCA, using the procedures outlined in the FBCA CP, the U.S. Government Public Key Infrastructure Cross Certification Criteria and Methodology with the U.S. FBCA or Citizen and Commerce Class Common Certification Authority (C4CA) and the MOA.

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

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

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

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

  4. All CMAs shall conform to the CPS as written for the applicable CA.

    1. All CMAs shall authenticate, and protect from modification, communications among PKI authorities supporting the certificate application and issuance process.

10.8.52.4.2.2  (07-24-2013)
Certificate Application Processing

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

10.8.52.4.2.2.1  (07-24-2013)
Performing Identification and Authentication Functions

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

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

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

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

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

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

10.8.52.4.2.2.2  (07-24-2013)
Approval or Rejection of Certificate Application

  1. The PMA shall require an initial compliance audit to ensure that the PKI CAs and other Entity CAs are prepared to implement all aspects of the applicable CPS, before authorizing the PKI PMO to issue and manage certificates asserting Department of the Treasury or Federal Common Policy Framework (FCPF).

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

      Note:

      Key generation signing ceremony can serve as initial compliance audit.

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

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

10.8.52.4.2.2.3  (07-24-2013)
Time to Process Certificate Applications

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

10.8.52.4.2.3  (07-24-2013)
CA Actions during Certificate Issuance

  1. It is the responsibility of the CMA to verify that the certificate information is correct and accurate.

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

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

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

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

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

10.8.52.4.2.3.1  (07-24-2013)
Notification to Subscriber of Certificate Issuance

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

10.8.52.4.2.4  (07-24-2013)
Certificate Acceptance

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

  2. For Rudimentary assurance, there is no stipulation.

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

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

10.8.52.4.2.4.1  (07-24-2013)
Conduct Constituting Certificate Acceptance

  1. Failure to object to the certificate or its contents constitutes acceptance of the certificate.

10.8.52.4.2.4.2  (07-24-2013)
Publication of the Certificate by the CA

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

10.8.52.4.2.4.3  (07-24-2013)
Notification of Certificate Issuance by the CA to Other Entities

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


More Internal Revenue Manual