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

Manual Transmittal

February 09, 2015

Purpose

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

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 title of this IRM has changed to IRS Public Key Infrastructure (PKI) X.509 Certificate Policy

(2) The entire IRM has been restructured to align with Treasury PKI X.509 Certificate Policy. Many sections have been added, revised, deleted or relocated within this IRM. For a detailed listing of the changes please see Exhibit 10.8.52-3.

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

Effect on Other Documents

IRM 10.8.52 dated July 24, 2013, 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

(02-09-2015)

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  (02-09-2015)
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 Policy Management Authority (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  (02-09-2015)
Scope

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

  2. The provisions in this manual apply to:

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

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

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

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

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

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

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

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

  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  (02-09-2015)
Roles and Responsibilities

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

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

10.8.52.2.1  (02-09-2015)
Treasury Policy Management Authority (PMA)

  1. All aspects of the Treasury PMA reside 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 CAssigned 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  (02-09-2015)
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., Government Accountability Office (GAO) and Treasury Inspector General Tax Administration (TIGTA) in accordance with the IRS IT organization Strategy and Planning, Risk Management organizational processes and procedures for audit management, reporting, and oversight.

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

    5. Provide Bureau RA and LRA guidance.

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

  4. Refer to IRM 10.8.2, for additional guidance 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  (02-09-2015)
PKI Operations Program Manager

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

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

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

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

    3. Provide acquisition support to maintain PKI technology.

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

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

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

    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 & ACIOEOPS-ISD-DSB PKI 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  (02-09-2015)
PKI Operational Staff

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

    1. Administer PKI and IRS PKI CAs.

    2. Publish certificates.

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

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

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

    6. Manage technical operational issues, including:

      • Set up and administer subordinate CAs

      • Implement the PKI and components

      • Coordinate installation

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

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

    7. 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  (02-09-2015)
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 CAs..

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

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

  4. The EOps PM 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  (02-09-2015)
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, File Transfer Protocol (FTP), and World Wide Web (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  (02-09-2015)
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, Federal Bridge Certificate Authority (FBCA) or another Entity CA.

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  (02-09-2015)
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.2.11  (02-09-2015)
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. ACA, 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.2.12  (02-09-2015)
Certificate Status Servers

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

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

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

10.8.52.2.13  (02-09-2015)
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.3  (02-09-2015)
IRS PKI Infrastructure

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

10.8.52.3.1  (02-09-2015)
External

  1. Externally, Treasury PKI has a TRCA.

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

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

    3. TRCA is cross-certified with the FBCA.

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

  2. Externally, the Treasury 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  (02-09-2015)
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 CAs shall operate under an approved CP and CPS consistent with the Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (PKIX) RFC 3647, Certificate Policy and Certification Practice Statement Framework.

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

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

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

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

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

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

10.8.52.4  (02-09-2015)
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.4.1  (02-09-2015)
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 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.4.2  (02-09-2015)
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.

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

10.8.52.5  (02-09-2015)
Identification and Authentication

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

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

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

  4. 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. Refer toIRM 10.8.1 for general information and computer security operational control requirements.

10.8.52.5.1  (02-09-2015)
Naming

  1. The naming requirements in the following subsections apply.

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

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

    1. Rudimentary: N/A.

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

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

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

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

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

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

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

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

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

    • Have not been convicted of a felony offense

    • Be appointed in writing by the PKI OA

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

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

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

    • Employment

    • Education

    • Place of residence

    • Law Enforcement

    • References

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

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

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

10.8.52.5.1.1  (02-09-2015)
Types of Names

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

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

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

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

    :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    1. All new implementations (after May of 2006) shall assign names in the following directory tree:

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

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

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

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

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

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

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

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

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

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

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

  12. Distinguished names based on Internet domain component (dc) names shall be in one of the following directory information trees:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    1. For certificates with an Affiliated Organization:

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

    2. For certificates with no Affiliated Organization:

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

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

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

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

    1. For certificates with an Affiliated Organization:

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

    2. For certificates with no Affiliated Organization:

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

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

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

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

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

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

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

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

    6. Device names shall use one of the following forms:

      C=US, o=U.S. Government, [ou=department], [ou=agency], cn=device name

      dc=gov, dc=org0, [dc=org1], [dc=orgN], [cn=device name]

      dc=mil, dc=org0, [dc=org1], [dc=orgN], [cn=device name]

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

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

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

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

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

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

    Assurance Level Naming Requirements
    Rudimentary Non-Null Subject Name, or Null Subject Name if Subject Alternative Name is populated and marked critical
    Basic Non-Null Subject Name, and optional Subject Alternative Name if marked non-critical
    Medium (all policies) Non-Null Subject Name, and optional Subject Alternative Name if marked non-critical
    High Non-Null Subject Name, and optional Subject Alternative Name if marked non-critical
    PIV Authentication Subject Alternative Name that include a name of type pivFASC-N, and option non-NULL Subject Name

10.8.52.5.1.2  (02-09-2015)
Need for Names to be Meaningful

  1. Names used within certificates shall identify the person or object to which it is assigned in a meaningful way.

    Note:

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

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

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

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

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

    Note:

    This does not preclude the use of pseudonymous certificates.

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

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

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

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

10.8.52.5.1.3  (02-09-2015)
Anonymity or Pseudonymity of Subscribers

  1. The TRCA shall not issue anonymous certificates.

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

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

10.8.52.5.1.4  (02-09-2015)
Rules for Interpreting Various Name Forms

  1. Rules for interpreting name forms shall use the appropriate standard.

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

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

    3. Rules for interpreting the pivFASC-N name type are specified in [PACS].

10.8.52.5.1.5  (02-09-2015)
Uniqueness of Names

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

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

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

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

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

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

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

    • What name forms shall be used.

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

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

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

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

10.8.52.5.1.6  (02-09-2015)
Recognition, Authentication, and Role of Trademarks

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

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

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

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

10.8.52.5.2  (02-09-2015)
Initial Identity Validation

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

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

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

10.8.52.5.2.1  (02-09-2015)
Method to Prove Possession of Private Key

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

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

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

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

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

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

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

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

10.8.52.5.2.2  (02-09-2015)
Authentication of Organization Identity

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

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

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

      Note:

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

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

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

    • Organization identification and authorization

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

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

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

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

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

10.8.52.5.2.3  (02-09-2015)
Authentication of Individual Identity

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

10.8.52.5.2.3.1  (02-09-2015)
Authentication of Human Subscribers

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

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

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

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

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

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

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

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

    • Identity of the applicant

    • Identity of the person performing the identification

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

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

    • The date of the verification

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

      Note:

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

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

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

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

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

    Assurance Level Identification Requirements
    Rudimentary No identification requirement; applicant may apply and receive a certificate by providing his or her email address.
    Basic Applicant shall establish identity by in-person proofing before a RA/LRA, Trusted Agent, an Entity certified by a State or Federal Entity as being authorized to confirm identities; or remotely by providing verifying information including ID number and account number through record checks either with the applicable agency or institution, or through credit bureaus or similar databases. Such information confirms that: name, DoB, address, and other personal information in records are consistent with the application and sufficient to identify a unique individual. RA/LRA shall confirm addresses by: a) Issuing credentials in a manner that confirms the address of record supplied by the applicant; or b) Issuing credentials in a manner that confirms the ability of the applicant to receive telephone communications at a number associated with the applicant in records, while recording the applicant’s voice.
    Medium (all policies) Applicant shall establish identity by in-person proofing before the RA/LRA, Trusted Agent, or an Entity certified by a State or Federal Entity as being authorized to confirm identities; the proofing authority shall verify such information provided to ensure legitimacy. A trust relationship between the Trusted Agent and the applicant, based on an in-person antecedent, may suffice as meeting the in-person identity-proofing requirement. Credentials required are either one Federal Government-issued Picture I.D., one REAL ID Act compliant picture ID, or two non-Federal Government IDs, one of which shall be a photo I.D. (e.g., Non-REAL ID Act compliant Drivers License). Any credentials presented must be unexpired. Clarification on the trust relationship between the Trusted Agent and the applicant, which is based on an in-person antecedent identity proofing event, can be found in the “FBCA Supplementary Antecedent, In-Person Definition” document.
    High Applicant shall establish identity by in-person appearance before the RA/LRA, or Trusted Agent; the proofing authority shall verify such information provided to ensure legitimacy Credentials required are either one Federal Government-issued Picture I.D., or two non-Federal Government IDs, one of which shall be a photo I.D. (e.g., Drivers License).

10.8.52.5.2.3.2  (02-09-2015)
Authentication of Human Subscribers for Group Certificates

  1. Normally, a CMA shall issue a certificate to a single Subscriber.

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

    2. Subordinate Treasury PKI CAs and/or RA/LRAs shall record the information identified in the “Authentication of Human Subscribers” section for a Sponsor from the organization’s Information Systems Security Office or equivalent, as well as for the subordinate PKI CA CMA, before issuing a group certificate.

  2. In addition to the authentication of the Sponsor, the RA/LRA shall perform the following procedures for members of the group:

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

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

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

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

10.8.52.5.2.3.3  (02-09-2015)
Authentication of Devices

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

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

    • Equipment or software application public keys

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

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

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

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

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

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

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

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

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

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

    Note:

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

10.8.52.5.2.4  (02-09-2015)
Non-verified Subscriber Information

  1. Except for the rudimentary assurance level, CMAs shall not include unverified information in certificates.

10.8.52.5.2.5  (02-09-2015)
Validation of Authority

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

10.8.52.5.2.6  (02-09-2015)
Criteria for Interoperation

  1. The PMA shall determine the criteria for cross certification with other Entities in accordance with this CP and the U.S. Government Public Key Infrastructure Cross Certification Methodology and Criteria. (See http://www.cio.gov/fbca/documents.htm.http://www.cio.gov/fbca/documents.htm.)

10.8.52.5.3  (02-09-2015)
Identification and Authentication For Re-key Request

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

10.8.52.5.3.1  (02-09-2015)
Identification and Authentication for Routine Rekey

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.8.52.5.3.1.1  (02-09-2015)
Certificate Renewal

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

  2. The TRCA shall not perform certificate renewal.

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

    2. Subordinate PKI CAs may renew certificates.

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

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

10.8.52.5.3.1.2  (02-09-2015)
Certificate Update

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

  2. The TRCA shall not create a new certificate containing a public key that exists in another certificate.

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

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

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

10.8.52.5.3.2  (02-09-2015)
Identification and Authentication for Rekey after Revocation

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

    Note:

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

10.8.52.5.4  (02-09-2015)
Identification and Authentication for Revocation Request

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

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

10.8.52.6  (02-09-2015)
Certificate Lifecycle

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

10.8.52.6.1  (02-09-2015)
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.6.1.1  (02-09-2015)
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.6.1.2  (02-09-2015)
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.6.2  (02-09-2015)
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.6.2.1  (02-09-2015)
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.6.2.2  (02-09-2015)
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.6.2.3  (02-09-2015)
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.6.3  (02-09-2015)
Issuance

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


More Internal Revenue Manual