Part 10. Security, Privacy and Assurance

Chapter 8. Information Technology (IT) Security

Section 52. PKI Security Policy

10.8.52  PKI Security Policy

Manual Transmittal

February 28, 2011

Purpose

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

Background

This Internal Revenue Manual (IRM) defines the security controls for the IRS Public Key Infrastructure (PKI) used to protect federal information systems and data.

Material Changes

(1) This IRM establishes security controls for internal and external Internal Revenue Service (IRS) Public Key Infrastructure (PKI) implementation. It specifies the minimum security controls to safeguard the PKI within the IRS organization.

(2) IRM 10.8.52 is part of the Security, Privacy and Assurance policy family.

Effect on Other Documents

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. This IRM was originally published in its entirety as Interim Guidance Memo MITS-10-0111-11. The content of this IRM is identical to and supersedes MITS-10-0111-11.

Audience

IRM 10.8.52 shall be distributed to all individuals and organizations having contractual arrangements with the IRS, contractors, vendors, and outsourcing providers, which install, use or operate PKI, and store, process, or transmit IRS data.

Effective Date

(02-28-2011)

Terence V. Milholland
Chief Technology Officer

10.8.52.1  (02-28-2011)
Purpose

  1. IRM 10.8.52, Information Technology (IT) Security, PKI Security Policy, establishes the foundation for a comprehensive policy to address the internal and external Internal Revenue Service (IRS) Public Key Infrastructure (PKI) implementation. It specifies the minimum security controls to safeguard the PKI structure within the IRS organization.

10.8.52.1.1  (02-28-2011)
Overview

  1. It is the policy of the IRS to establish and manage a PKI Program in compliance with Treasury PKI Policy within all its offices. This manual provides uniform policies and guidance to be used by each office.

  2. It is the policy of the IRS to protect its information resources and allow the use, access, and disclosure of information in accordance with applicable laws, policies, federal regulations, Office of Management and Budget (OMB) Circulars, Treasury Directives (TDs), National Institute of Standards and Technology (NIST) Publications, and other regulatory guidance. All IT resources belonging to, or used by the IRS, shall be protected at a level commensurate with the risk and magnitude of harm that could result from loss, misuse, or unauthorized access to that IT resource.

  3. This PKI policy delineates the security management structure, assigns responsibilities, and lays the foundation necessary to measure progress and compliance. This policy subdivides requirements under three major security control areas: management, operational, and technical.

10.8.52.1.1.1  (02-28-2011)
IRS PKI Introduction

  1. PKI provides a method for securing transmission of information across Agency Automated Information System (AIS) assets, and supports the verification of an individual’s identity for physical and logical access control. Overall, the PKI Program establishes a secure electronic environment, at the Sensitive But Unclassified (SBU) level, that fully complements hard-copy documentation standards currently in use.

  2. PKI 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, technical non-repudiation, and confidentiality (i.e., privacy) to electronic transactions.

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

    1. Externally, Treasury PKI has a Treasury Root Certificate Authority (TRCA). Any additional Certificate Authorities (CAs) within Treasury are subordinated to TRCA. External Treasury CAs operate under approved Treasury Certificate Policy (CP) and Certificate Practices Statement (CPS). TRCA is cross certified with the Federal Bridge Certificate Authority (FBCA). The CPS of CAs subordinate to the TRCA shall comply with the Treasury CP.

    2. The IRS Internal PKI is a Subordinate CA to TRCA. 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.

    3. IRS Criminal Investigation (CI) has received a waiver from the Department of the Treasury, Policy Management Authority (PMA) to operate a standalone internal PKI for the purpose of protecting law enforcement information.

  4. The IRS internal PKI shall implement Issuer CAs to only provide Internal Non-Person Entity with certificates as necessary.

  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 Personnel Entities (NPE) such as: workstations, guards and firewalls, routers, trusted servers (e.g., database, domain controller, file transfer protocol [FTP], and world wide web [WWW]), 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.

    • 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.1.2  (02-28-2011)
Scope

  1. The provisions in this IRM apply to all offices, business, operating and functional units within the IRS, including IRS employees, and are to be applied when information technology is used to accomplish the IRS mission.

  2. This IRM applies to all individuals and organizations having contractual arrangements with the IRS, contractors, vendors, and outsourcing providers, which install, use, or operate PKI, and store, process, or transmit IRS data.

10.8.52.1.3  (02-28-2011)
IRM Section Topics

  1. This manual contains information on the following subjects:

    • Authority

    • General Policy

    • Management Controls

    • Operational Controls

    • Technical Controls

    • Deviations

    • Glossary (see Exhibit 10.8.52-1)

    • References (see Exhibit 10.8.52-2)

10.8.52.1.4  (02-28-2011)
Authority

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

  2. This IRM augments the management, operational and technical controls as defined in IRM 10.8.1, Information Technology (IT) Security, Policy and Guidance, IRM 10.8.20, Information Technology (IT) Security, Windows Security Policy, IRM 10.8.10, Basic UNIX Security Requirements (BUSR); and IRM 10.8.3, Information Technology (IT) Security, Audit Logging Security Standards to include comprehensive guidance on the implementation of Web Servers and Web Application Servers.

  3. In the event that 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.

10.8.52.2  (02-28-2011)
General Policy

  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. IRS shall have a dual PKI infrastructure.

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

      1. The reliance the 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.

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

  4. All internal IRS PKI Certificate Authorities (CAs) shall operate under an approved certificate policy (CP) and certificate 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.

  5. At a minimum, certificate 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; and

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

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

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

  8. For the Internal IRS PKI, NPE certificates, both the use of a manual certificate issuance and life-cycle management (MCM) process for certificates, and the use of an automated certificate issuance and life-cycle management (ACM) process shall be implemented.

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

10.8.52.2.1  (02-28-2011)
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.1  (02-28-2011)
Policy Management Authority (PMA)

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

    • The Treasury PKI Policy (CP);

    • Review, approval, and compliance review of all Treasury CPSs issued and maintained in support of the Treasury Certification Authority (TCA);

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

    • Oversight compliance management of the TCA and all Treasury CAs signed by the TRCA;

    • Internal Auditing and compliance oversight of TCA operations;

    • Determinations regarding CP and CPS compliance and assurance level with the Department of the Treasury CP;

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

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

    • Issuing cross certificates to other PKIs asserting other policies;

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

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

    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.

  2. Establishing a PMA within the IRS requires approval from the Department of the Treasury PMA and coordination through the IRS PKI Program Management Office (PMO).

    1. IRS or Bureau-approved PMAs shall operate in accordance with Department of the Treasury (DOT) 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/.

  3. Any exception to Department of the Treasury PKI policy must be approved by the Treasury PMA.

10.8.52.2.1.2  (02-28-2011)
IRS PKI Program Management Office (PMO)

  1. The PKI Program Management Office (PMO) shall be established within MITS 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:

    • Provide oversight and coordination of the IRS CA on behalf of the IRS;

    • Recommend approval to Department of the Treasury for any PMO approved CP or CPS exception;

    • Create, publish, and maintain all CPSs pertaining to the IRS PKI;

    • Publish IRS Internal PKI CP and coordinate modifications to ensure continued compliance by all IRS PKI CA or Registration Authority(RA) operating under approved CPSs;

    • Participate in audit management activities (e.g., GAO and TIGTA) in accordance with the MITS Strategy and Planning, Risk Management organizational processes and procedures for audit management, reporting, and oversight;

    • Provide Bureau RA and Local Registration Authority (LRA) training;

    • 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 IT Security Projects Office website at http://mits.web.irs.gov/Cybersecurity/Divisions/Architecture_Implement/projects_office.htm or contact the PMO through the *MITS PKI Management Solutions mailbox.

10.8.52.2.1.3  (02-28-2011)
PKI Operations Program Manager

  1. The position of PKI Operations Program Manager shall be established within MITS 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:

    • Establish the operational requirements for the IRS subordinate CAs in the CPSs

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

    • Provide acquisition support to maintain PKI technology;

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

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

    • Work with MITS communications to provide customer advisories in advance of any downtime or potential impact. See IRM 10.8.1 for additional information regarding incident reporting requirements;

    • Coordinate PKI activities with MITS Enterprise Services and ensure that the IRS PKI complies with the IRS Enterprise Architecture;

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

10.8.52.2.1.4  (02-28-2011)
PKI Operational Staff

  1. The PKI operational staff shall be established within the MITS Enterprise Operations organization. The PKI operational staff shall administer the IRS’ PKI from an operation perspective and shall:

    • Publish certificates;

    • Perform issuance and revocation of certificates to subordinate CAs, and to Subscribers from those CAs;

    • Manage certificate repositories and certificate and authority revocation lists;

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

    • Manage technical operational issues, including Security Assessment and Authorization (i.e., C&A) activities, in accordance with IRM 10.8.1.

10.8.52.2.1.5  (02-28-2011)
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 PKI Certificate Authorities (CAs).

  2. RA functions as the Officer trusted role of the IRS PKI CA. The EOps PM appoints all RA and LRA for IRS CA from members of the PKI operational staff, or other IRS personnel as necessary. The EOps PM must maintain a current active list of all RAs and provide that list to the PMO when requested.

10.8.52.2.1.6  (02-28-2011)
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 it uses 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 those who request certificates for uses other than signing and issuing certificates or certificate status information.

10.8.52.2.1.7  (02-28-2011)
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. 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/fpkipa/, for updated list of entities cross-certified with the Federal Bridge Certificate Authority (FBCA)).

10.8.52.2.1.8  (02-28-2011)
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.2  (02-28-2011)
Other PKI Authorities

  1. Other PKI authorities include the following:

10.8.52.2.2.1  (02-28-2011)
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.

10.8.52.2.2.2  (02-28-2011)
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 re-key.

  2. IRS’s Subordinate CAs are responsible for all aspects of the issuance and management of internal certificates to non personnel entities (only), including control over the enrollment process, the identification and authentication process, the certificate manufacturing process, publication of certificates, revocation of certificates, and re-key.

10.8.52.2.2.3  (02-28-2011)
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.

10.8.52.3  (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.3.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 bellow:

    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.3.2  (02-28-2011)
Certificate Life cycle 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.3.2.1  (02-28-2011)
Certificate Application

  1. User Identification (ID) - User authentication shall occur prior to certification issuance.

10.8.52.3.2.2  (02-28-2011)
Key Pair and Certificate Usage

  1. Subscriber Private Key and Certificate Usage:

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

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

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

  2. Relaying Party Public key and Certificate Usage:

    1. IRS PKI certificate authorities (CAs) shall issue certification revocation lists (CRLs) specifying the status of all unexpired certificates.

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

10.8.52.3.2.3  (02-28-2011)
Certificate Renewal

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

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

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

10.8.52.3.2.4  (02-28-2011)
Certificate Re-key

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

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

    2. After certificate re-key, the CA may or may not revoke the old certificate, but must not re-key, renew, or modify it further.

  2. Subscribers of Entity Certificate Authorities (CAs) shall identify themselves for the purpose of re-keying as required in the section “Identification and Authentication for Re-Key Request”.

10.8.52.3.2.5  (02-28-2011)
Certificate Modification

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

  2. After certificate modification, the IRS PKI CA may or may not revoke the old certificate, but must not re-key, renew, or modify it further.

10.8.52.3.2.6  (02-28-2011)
Certificate Revocation and Suspension

  1. Certificate Revocation - A certificate shall be revoked if:

    1. The associated private key is compromised;

    2. CA’s become compromised;

    3. Management requests revocation; or

    4. The certificate is no longer needed.

  2. The CA shall publish a Certificate Revocation List (CRL) documenting the revocation of a certificate and identifying the reason for revocation.

  3. CRLs shall be available to an intended community of Relying Parties, i.e., Subscribers and other parties who use the certificates.

  4. Certificates shall be revoked within the time specified below:

    1. Rudimentary: No revocation required

    2. Basic: Within 6 hours

    3. Medium: Within 2 hours

    4. High: Within 30 minutes [IRM 10.8.1]

10.8.52.3.2.7  (02-28-2011)
Key Escrow and Recovery

  1. CA private keys shall never be escrowed.

  2. Subscriber key management keys may be escrowed to provide key recovery.

  3. CAs that support private key escrow for key management keys shall identify the document describing the practices in the applicable CPS.

  4. Escrowed keys shall be protected at no less than the level of security in which they are generated, delivered, and protected by the subscriber.

  5. Under no circumstances shall a subscriber signature key be held in trust by a third party.

10.8.52.4  (02-28-2011)
Operational Controls

  1. Operational controls address security mechanisms that primarily are implemented and executed by people versus systems. They often require technical or specialized expertise and rely on management activities as well as technical controls. See IRM 10.8.1 for general information and computer security operational control requirements.

10.8.52.4.1  (02-28-2011)
Personnel Security – Background Investigations

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

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

    1. Rudimentary: N/A

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

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

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

  3. For additional personnel security requirements see IRM 10.8.1.

10.8.52.4.2  (02-28-2011)
Physical and Environmental Protection

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

  2. See IRM 10.8.1 for additional physical and environmental protection requirements.

10.8.52.4.2.1  (02-28-2011)
Physical Security

  1. Rudimentary and Basic: When not in use, CA tokens, removable cryptographic modules and any activation information used to access or enable cryptographic modules, shall be placed in high-security locked containers (e.g., with Medeco deadbolt locks, Schlage, or USCAN).

    1. CA servers, workstations, and other components shall be located in a restricted/secure environment accessed only by authorized personnel.

  2. Medium and High: When not in use, CA tokens, removable cryptographic modules, and any activation information used to access or enable cryptographic modules shall be placed in GSA-approved Class VI security containers.

    1. CA servers, workstations and other components shall be located in a restricted/secure environment accessed only by authorized personnel and shall be protected with intrusion alarms.

10.8.52.4.2.2  (02-28-2011)
Environmental Controls

  1. Rudimentary - N/A;

  2. Basic to High:

    1. CA media shall be stored in a manner that provides protection from accidental water, fire, or electromagnetic damage.

    2. CA backup media and copies of audit logs and archival files shall be maintained in a secure offsite location.

    3. System backup sufficient to recover CA and directory service operations shall be performed on a periodic schedule that is described in the CA CPS.

    4. Provisions shall be made to protect CA and directory service operation from fire and water damage.

    5. CA and directory service operations shall have adequate power. HVAC is required to maintain a reliable operating environment.

    6. CA and directory services operations shall be provided with an uninterruptible power supply (UPS) with at least a capability to provide an orderly shutdown in the event of a power failure.

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

10.8.52.4.3  (02-28-2011)
Contingency Planning

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

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

  3. See IRM 10.8.1 for additional contingency planning requirements.

10.8.52.4.4  (02-28-2011)
Configuration Management

  1. The configuration of the CA system, in addition to any modifications and upgrades, shall be documented and controlled.

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

  3. The CA software, when first loaded, shall be verified as being that supplied from the vendor, with no modifications, and be the version intended for use.

  4. The CA shall periodically verify the integrity of the software as specified in the CPS.

10.8.52.5  (02-28-2011)
Technical 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.

    1. See IRM 10.8.1 for additional technical security control requirements.

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

10.8.52.5.1  (02-28-2011)
Encryption/Cryptography

  1. Cryptographic keying material shall be used by CAs to sign certificates.

  2. CRLs or status information shall be generated in FIPS 140 validated cryptographic modules.

10.8.52.5.1.1  (02-28-2011)
Encryption key recovery

  1. When cryptographic protection is used, IRS information systems shall use cryptographic modules that comply with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

  2. When employing cryptography, the IRS shall perform all cryptographic operations using, at a minimum, FIPS-validated (e.g., FIPS 140-2 or later) encryption technology.

  3. The IRS shall establish, implement, and maintain an encryption key management program in accordance with NIST Special Publication 800-57, Recommendation for Key Management, to manage the keys for IRS information systems that require them and address the protection and continued accessibility of cryptographically protected information.

    1. Procedures shall be in place to ensure that the information remains viable during its lifetime in the event of the loss of cryptographic keys by a user.

    2. The IRS shall assign the role of Encryption Recovery Agent. See IRM 10.8.2, Information Technology (IT) Security Roles and Responsibilities for further details.

    3. Encryption products shall provide for encryption key recovery to support IRS availability needs.

    4. Encryption key recovery requirements, at a minimum, shall include identification of which keying material, if any, requires back-up or archive for later recovery.

10.8.52.5.1.2  (02-28-2011)
CA Key Pair Generation and Storage

  1. CA key pairs shall be generated and stored as follows:

    1. Rudimentary: N/A

    2. Basic: CA key pairs shall be generated and stored using FIPS 140-2 Security Level 2 or higher cryptographic modules.

    3. Medium: CA key pairs shall be generated and stored using FIPS 140-2 Security Level 2 or higher cryptographic modules.

    4. High: CA key pairs shall be generated and stored using FIPS 140-2 Security Level 3 or higher.

  2. Two or more persons shall be required for CA key pair generation and at least one participant shall be the Administrator.

  3. CA key pair generation shall create a verifiable audit trail that the security requirements for procedures were followed.

    1. The documentation of the procedure must be detailed enough to show that appropriate role separation was used.

    2. An independent third party shall validate the execution of the key generation procedures either by witnessing the key generation or by examining the signed and documented record of the key generation.

10.8.52.5.1.3  (02-28-2011)
Subscriber Key Pair Generation and Storage

  1. Subscriber key pair generation shall be performed by the subscriber.

    1. Validated software or hardware cryptographic modules shall be used to generate all subscriber key pairs, as well as pseudo-random numbers and parameters used in key pair generation.

  2. Subscriber’s keys shall be generated and stored as follows:

    1. Rudimentary: N/A

    2. Basic: Subscriber key pairs shall be generated and stored using FIPS 140-2 Security Level 1 or higher cryptographic modules.

    3. Medium: Subscriber key pairs shall be generated and stored using FIPS 140-2 Security Level 2 or higher cryptographic modules.

    4. High: Subscriber key pairs shall be generated and stored using FIPS 140-2 Security Level 2 or higher cryptographic modules.

10.8.52.5.1.4  (02-28-2011)
Public Key Delivery to Certificate Issuer

  1. Where key pairs are generated by the subscriber or RA, the public key and the subscriber’s identity must be delivered securely to the CA for certificate issuance.

    1. The delivery mechanism shall bind the subscriber’s verified identity to the public key.

    2. If cryptography is used to achieve this binding, it shall be at least as strong as the CA keys used to sign the certificate.

10.8.52.5.1.5  (02-28-2011)
CSS Key Pair Generation

  1. Cryptographic keying material used by CSSs to sign status information shall be generated in FIPS 140 validated cryptographic modules.

    1. For CSSs that provide status for High (Level 3) certificates, the module(s) shall meet or exceed FIPS 140 Level 3.

    2. For CSSs that provide status for any other certificates, the module(s) shall meet or exceed FIPS 140 Level 2.

10.8.52.5.1.6  (02-28-2011)
CA Public Key Delivery to Relying Parties

  1. When a CA updates its signature key pair, the CA shall distribute the new public key in a secure fashion (e.g., a self-signed certificate, in a key rollover certificate, or in cross-certificates).

    1. Self-signed certificates shall be conveyed to relying parties in a secure fashion to preclude substitution attacks.

10.8.52.5.2  (02-28-2011)
Key Sizes

  1. CAs that generate certificates and CRLs that expire before December 31, 2010 shall use signature keys of 1024, 2048, or 3072 bits for RSA and 256 or 384 bits for elliptic curve algorithms.

    1. Certificates that expire on or after December 31, 2010 shall be generated with 2048- or 3072-bit keys for RSA and 256- or 384-bit keys for elliptic curve (EC) algorithms.

    2. Certificates that expire after December 31, 2030 shall be generated with 3072-bit keys for RSA and 256- or 384-bit keys for elliptic curve algorithms.

      Note: NIST SP800-57 recommendation is 256-bit elliptic curve keys after December 31, 2010.

  2. CA that generates certificates and CRLs that are issued before December 31, 2010 shall use the SHA-1, SHA-256, or SHA-384 hash algorithm when generating digital signatures.

    1. RSA signatures on certificates and CRLs that are issued after December 31, 2010 shall be generated using SHA-256.

    2. ECDSA signatures on certificates and CRLs that expire on or after December 31, 2010 shall be generated using SHA-256 or SHA-384, as appropriate for the key length.

  3. Where implemented, certificate status server (CSS) shall sign responses using the same signature algorithm, key size, and hash algorithm used by the CA to sign CRLs.

  4. End entity device and hardware certificates that expire before December 31, 2010 shall contain RSA public keys that are 1024, 2048, or 3072 bits in length or elliptic curve keys that are 256 or 384 bits.

  5. End entity certificates issued that expires on or after December 31, 2010 shall contain RSA public keys that are 2048 or 3072 bits or elliptic curve keys that are 256 or 384 bits.

  6. End entity certificates issued that expires after December 31, 2030 shall contain RSA public keys that are 3072 bits or elliptic curve keys that are 256 or 384 bits.

  7. Trusted Certificates that expire before January 1, 2031 shall contain subject public keys of 2048 or 3072 bits for RSA or 256 or 384 bits for elliptic curve, and be signed with the corresponding private key.

  8. Trusted Certificates that expire on or after January 1, 2031 shall contain subject public keys of 3072 bits for RSA or 256 or 384 bits for elliptic curve, and be signed with the corresponding private key.

  9. Use of TLS or another protocol providing similar security to accomplish any of the requirements of this policy shall require:

    1. Triple-DES or AES for the symmetric key through December 31, 2010 and AES for the symmetric key after December 31, 2010.

    2. At least 2048-bit RSA or 224 bit elliptic curve keys after December 31, 2008, and 3072-bit RSA or at least 256-bit elliptic curve keys after December 31, 2030.

10.8.52.5.3  (02-28-2011)
Identification and Authentication

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

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

  3. See IRM 10.8.1 for additional identification and authentication requirements.

10.8.52.5.3.1  (02-28-2011)
Naming

  1. Subscriber names, as contained within a certificate, shall be unique and meaningful.

10.8.52.5.3.1.1  (02-28-2011)
Types of Names

  1. All CAs shall be able to generate and sign certificates that contain an X.501 Distinguished Name (DN).

    1. DN's may be in either one of three forms: a geo-political name space, an internet domain component name space, or in the case of active directory integrated certificate authorities, the name space may be derived from the directory.

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

  3. DNs employed externally to the IRS shall not include SBU information.

    1. Refer to IRM 10.8.1 for the definition of SBU and guidance for protecting it.

10.8.52.5.3.2  (02-28-2011)
Initial Identity Validation

  1. Initial Identity validation shall be processed as follows:

    • Rudimentary: Users shall apply online and only need to supply a valid E-mail address.

    • Basic: Users may be identified online by a personal identification number (PIN) or secret information. User-supplied ID information shall be protected using the Transport Layer Secure (i.e., TLS v1.2 or later, after December 31, 2010) protocol with 128-bit encryption or an alternative approved by the IRS Policy Management Authority (PMA).

    • Medium: Users shall present, in person, one Federal Government-issued Picture ID, or two non-Federal Government IDs, one of which shall be a photo ID. (e.g., Drivers License) to a CA or an RA. The RA or CA shall vet the information presented.

    • High: Users shall present, in person, Federal Government-issued Picture I.D., or two non-Federal Government IDs, one of which shall be a photo ID (e.g., Drivers License), to a CA or an RA. The RA or CA shall vet the information presented.

10.8.52.5.3.3  (02-28-2011)
Identification and Authentication for Re-Key Request

  1. Identification and Authentication for Routine Re-key – Re-keying a certificate means that the Certification Management Request (CMR) creates a new certificate that has the same characteristics and level as the original key, except that the new certificate has a new public key (corresponding to a new private key), a new serial number, and possibly a new validity period.

  2. Identification and Authentication for Re-key after Revocation – 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.

10.8.52.5.3.4  (02-28-2011)
Identification for Revocation Request

  1. The Certificate Management Authority (CMA) shall authenticate revocation requests in accordance with the established procedures of revocation request.

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

10.8.52.5.4  (02-28-2011)
Audit and Accountability

  1. Auditable events shall be logged and processed as specified by IRM 10.8.3, Information Technology (IT), Audit Logging Security Standards. See IRM 10.8.3 for details.

  2. Additional audit requirements are provided below:

    1. Rudimentary: N/A

    2. Basic: CAs shall maintain a system audit logs/trail that records at a minimum:

      1. Configuration changes to hardware or software;

      2. Operational events (e.g., system startup, system shutdown, and system backup);

      3. System access (log on, log off);

      4. Issuance and revocation of certificates; and

      5. Security violations (failed log on, network probe/attack).

    3. Medium: Same as Basic except CAs shall record audit data on Write-Once, Read-Many (WORM) media.

    4. High: Same as medium.

  3. In addition to IRM 10.8.3, see IRM 10.8.1 for audit and accountability requirements.

10.8.52.5.4.1  (02-28-2011)
Certificate Authority (CA) Archive

  1. CAs shall maintain an archive of records sufficient to establish the validity of any certificate, including those revoked or expired.

    1. Archived records shall be maintained for a period to be determined by CAs in compliance with regulation and records management guidance.

10.8.52.5.5  (02-28-2011)
System and Communications Protection

  1. IRM 10.8.1 for additional system and communications protection security requirements.

10.8.52.5.5.1  (02-28-2011)
Network Protection and Design

  1. A network guard, firewall, or filtering router shall protect network access to CA equipment.

    1. The network guard, firewall, or filtering router shall limit services allowed to and from the CA equipment to those required to perform CA functions.

  2. Protection of CA equipment shall be provided against known network attacks.

    1. All unused network ports and services shall be turned off.

    2. Any network software present on the CA equipment shall be necessary to the functioning of the CA application.

  3. Any boundary control devices used to protect the network on which PKI equipment is hosted shall deny all but the necessary services to the PKI equipment.

  4. Directories, certificate status servers, and remote workstations used to administer the CAs shall employ appropriate network security controls.

    1. Networking equipment shall turn off unused network ports and services.

    2. Any network software present shall be necessary to the functioning of the equipment.

  5. The CA shall establish connection with a remote workstation used to administer the CA only after successful authentication of the remote workstation at a level of assurance commensurate with that of the CA.

  6. CA servers and workstations shall not be connected to or accessible from a non-IRS network.

    1. CA servers and workstations shall be attached to a IRS LAN or WAN, if protected by a dedicated firewall that is located between the LAN/WAN and the CA servers/workstations.

    2. An acceptable firewall shall consist of a screening network and transmission protocol layers.

      1. This firewall shall be configured to allow only a minimal set of inbound and outbound services as required for CA operation.

    3. This requirement shall not be applicable to directory servers used to publish certificates and/or Certificate Revocation Lists.

10.8.52.6  (02-28-2011)
Deviations

  1. Deviations from this policy shall be submitted in accordance with IRM 10.8.1 and as described in the deviation Standard Operating Procedures (SOPs) provided on the Cybersecurity (formally Mission Assurance and Security Service MA&SS) Web site.

Exhibit 10.8.52-1 
Glossary


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


Authentication: Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual’s identity.


C
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): It could be a Certification Authority or a Registration Authority.


Certificate Policy (CP): Policy focused on certificates and the Certificate Authority’s (CA) responsibilities regarding these certificates. It defines certificate characteristics such as usage, enrollment and issuance procedures, as well as liability issues.


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.


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: The combination of a certificate and the matching private key.


Cryptography: The discipline that embodies principles, means, and methods for the transformation of data in order to hide semantic content, prevent unauthorized use, or prevent undetected modification.


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.


D
Disaster Recovery Plan: A written plan for processing critical applications in the event of a major hardware or software failure or destruction of facilities.


E
End Entity Certificate (EEC): A certificate belonging to a non-CA entity, e.g. you, me or the computer, firewall.


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


K
Key Escrow: The retention of the private component of the key pair associated with a Subscriber’s encryption certificate to support key recovery.


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


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


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.


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.


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


Re-key (a certificate): To change the value of a cryptographic key that is being used in a cryptographic system application.


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


T
Technical non-repudiation: The contribution public key mechanisms make to the provision of technical evidence supporting a non-repudiation security service.


Trust List: Collection of Trusted Certificates used by Relying Parties to authenticate other certificates.


Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL): Are cryptographic protocols that provide security for communications over networks such as the Internet.


U
User credentials: The combination of a user certificate and its corresponding private key.


Exhibit 10.8.52-2 
References

IRS

  • IRM 10.8.1 – Information Technology (IT) Security, Policy and Guidance

  • IRM 10.8.2 – Information Technology (IT) Security, Roles and Responsibilities

  • IRM 10.8.3 – Information Technology (IT) Security, Audit Logging Security Standards

  • IRM 10.8.10 - Information Technology (IT) Security, Basic UNIX Security Requirements (BUSR)

  • IRM 10.8.20 - Information Technology (IT) Security, Windows Security Policy

  • IRM 10.8.42 - Information Technology (IT) Security, Web Server and Web Application Server Security

Treasury

  • Treasury Department PKI Policy RFC 3647 v2.1

NIST

  • FIPS 199, Standards for Security Categorization of Federal Information and Information Systems, Feb, 2004

  • FIPS 140-2, Security Requirements for Cryptographic Modules, May 25, 2001.

  • FIPS 186, Digital Signature Standard, June 2009

  • FIPS 201-1, Personal Identity Verification (PIV) of Federal Employees and Contractors, March 2006

  • NIST SP 800-57, Part 3, Recommendation for key Management, Part 3 Application-Specific Key Management Guidance, December 2009

  • NIST SP 800-73-3, Interfaces for Personal Identity Verification, Feb 2010

  • NIST SP 800-76-1, Biometric Data Specification for Personal Identity Verification, Jan 2007

  • NIST 800-78-2, Cryptographic Algorithms and Key Sizes for Personal Identification Verification (PIV), Feb 2010

Other Documents

  • Certificate Policy (CP) for IRS Secure Messaging Public Key Infrastructure (PKI) Department of the Treasury v2.1, Aug 22, 2001

  • Certificate Practice Statement (CPS) for the IRS Secure Enterprise Messaging System (SEMS) Department of the Treasury, Sept, 2001

  • RFC 3647 - Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework

  • X.509 Certificate Policy For The U.S. Federal PKI Common Policy Framework, Aug16, 2010

  • Treasury Certification Authority, IRS Internal Certificate Authority, Certification Practice Statement, May 22, 2004, Draft v.01


More Internal Revenue Manual