 |
|
|
|
|
|
|
|
|
 |
|
HHS IRM Policy for Public Key Infrastructure (PKI) Certification Authority (CA)January 8, 2001HHS-IRM-2000-0011 TABLE OF CONTENTS
1. Purpose This circular establishes the policies and responsibilities for the Implementation and Usage of Public Key Infrastructure (PKI) Certification Authority (CA) by the Department of Health and Human Services (HHS) and its Agencies. 2. Background The American public relies on the U.S. Department of Health and Human Services (HHS) to administer a broad range of approximately 300 Federal program activities. Together with its many service partners, HHS delivers $238 billion dollars of health care services annually to 62 million people through its Medicare, Medicaid and Indian Health Service Programs. HHS also plays a vital role in ensuring safety, efficacy, and appropriate use of health care products; controlling disease and promoting health; advancing biomedical research; and assisting the poor. HHS’ service partners include States, universities, contractors and not-for-profit organizations. Together these activities are vital to the health and well being of the American Public, especially the elderly, children, and the poor. Taking account of private and public spending, the health sector constitutes a significant segment of the overall U.S. economy and looks toward the HHS to lead the future direction of these vital health activities. Presidential Decision Directive 63 (PDD 63), "Critical Infrastructure Protection" requires each Federal Agency to develop a vulnerability plan, implement an infrastructure framework solution, monitor the enterprise infrastructure for vulnerabilities and respond to threats as appropriate. Currently, there is a worldwide transformation in progress from paper-based commerce and interaction, to electronic commerce and interaction. This is true in HHS as well. Potentially, significant vulnerabilities exist in electronic commerce and interaction if security is not planned and implemented. To secure both internal and external electronic communications, HHS plans to implement an Enterprise Certification Authority using Public Key Infrastructure (PKI) technology and an Enterprise Directory Service using Lightweight Directory Access Protocol (LDAP) technology. A PKI implementation is a combination of Technology, Policies and Procedures, which supports digital signatures, encryption and other inherent PKI-Enabled security services. A PKI enables users of a basically unsecured public network such as the Internet to securely and privately exchange data through the use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority. The public key infrastructure provides for a digital certificate that can identify an individual or an organization and a directory service that can store the certificates. PKI technology provides the mechanism for ensuring that electronic transactions are more secure than their paper counterparts. A PKI offers the security services of confidentiality, authenticity, integrity, and technical non-repudiation. Essential components of the PKI are: An Enterprise PKI using LDAP will strengthen internal and external security and HHS will realize significant cost savings through implementation of a single Departmental Certification Authority hierarchy and Directory rather than multiple ones in the various HHS Operating Divisions (OPDIVs) with potentially incompatible Certification Authorities and Directories. 3. Scope This policy applies to all Departmental (Operating Division and Staff Division) PKI implementation whether owned and operated by HHS, or operated on behalf of HHS. 4. Policy All HHS organizations deploying a PKI shall meet FIPS 140-1 Standards (FIPS 140-1, Security Requirements for Cryptographic Modules of January 1994). 4.1. HHS PKI Architecture4.1.1 The HHS PKI architecture shall be that of a Hierarchical Root CA (which could be either an HHS Root CA system or a trusted third party). Agencies within HHS shall formulate a Subordinate Certification Authority to operate under the root Certificate Policy (CP). The HHS’s root CA will issue certificates to the subordinate CAs. This will result in a single trust domain composed of subordinate CAs operating within the HHS’s hierarchy. 4.1.2 The Subordinate CAs operated by the OPDIVs shall operate in accordance with the policies and procedures established by the HHS Root Certification Authority. 4.1.3 Trust between CAs flows down from the root. Relying parties shall only directly trust other users whose CA is a member of the same hierarchy. In a hierarchy, the level of trust for a CA is a function of the level of trust associated with the CA at the root of the hierarchy.4.1.4 The HHS PKI architecture shall interoperate with the Federal Bridge Certification Authority (FBCA). 4.2. Relying Party 4.2.1 All HHS OPDIVs shall be considered Relying Parties. 4.2.2 Relying parties are obliged to use the certificate for the purpose for which it was issued in accordance with the corresponding CP and the current Certificate Practice Statement (CPS) 4.2.3 Prior to its use, relying parties are obliged to check each certificate for its validity, revocation, or suspension before use. 4.2.4 Relying parties are obliged to verify the digital signature of a received digitally signed message and to verify the digital signature of the CA that issued the certificate. 4.3. Enrollment/Registration Process 4.3.1 All HHS OPDIVs shall follow an enrollment/registration process. 4.3.2 The PKI user enrollment process shall contain the following steps: 5. Roles and ResponsibilitiesThe CIO is responsible for providing advice and assistance to the Secretary and other senior management personnel, to ensure that information technology is acquired and information resources are managed for the agency in a manner that implements the policies (Certificate Policy) and procedures (Certificate Practice Statement) of the HHS PKI. The HHS CIO is responsible for approving any implementation of PKI by HHS OPDIVs. The Deputy Assistant Secretary for Information Resources Management (DASIRM) shall assure that the HHS Enterprise PKI effectively supports mission requirements, meets strict performance criteria, and conforms to the HHS hieraracal architecture. The DASIRM is responsible for defining, implementing and managing HHS certificate policy decisions. The DASIRM is also responsible for certification and accreditation of the overall PKI implementation and has responsibility for the oversight of all PKI operations. The DASIRM will publish and maintain the Certificate Policy for the HHS PKI. The DASIRM will provide lead support in the development and implementation of the HHS PKI. The DASIRM is responsible to audit the operations of root and subsidiary CAs in the HHS hierarchy on a regular basis consistent with the requirements of the Federal Bridge Certification Authority and the Federal Bridge Policy Authority. The OPDIV CIOs shall be responsible for ensuring that PKI implementation is performed in accordance with the policy of the DASIRM Certificate Policy. The OPDIV CIOs provide planning guidance to, and oversight of the PKI infrastructure, and direct the activities of the OPDIV PKI Manager and the OPDIV PKI manager’s staff. The OPDIV CIOs have overall responsibility for proper and reliable operations of the OPDIV PKI CA and for seeing that the policies and directives of the DASIRM are carried out. They are responsible for establishing and approving detailed operating procedures. Responsibilities of the OPDIV CIOs include: The OPDIV CIO shall be responsible for appointing the OPDIV PKI Manager The root CA PKI Manager shall be a Federal government employee and shall be designated by the CIO. The root CA PKI Manager staffs and operates the HHS root CA PKI on a day-to-day basis and assures that it is functioning properly, that all procedures and safeguards are being followed, and that any operational errors, anomalies, and breaches of policy and procedure are addressed promptly and properly. Because the PKI itself is a trust-oriented service, it is essential that the PKI Manager institutes, and consistently follows, operational procedures that promote reliability and trust. The root CA PKI Manager is responsible for developing and maintaining PKI plans, policies and procedures pertaining to operation of the Certification Authority and the overall operation of the PKI. The OPDIV PKI Manager staffs and operates the Subordinate CA on a day-to-day basis and assures that it is functioning properly, that all procedures and safeguards are being followed, and that any operational errors, anomalies, and breaches of policy and procedure are addressed promptly and properly. Because the PKI itself is a trust-oriented service, it is essential that the OPDIV PKI Manager institutes, and consistently follows, operational procedures that promote reliability and trust. The OPDIV PKI Manager staffs and operates the Subordinate Certification Authority (CA) Workstation and its associated directories, repositories and communication facilities. The OPDIV PKI Manager shall follow the policies and procedures established by the root Certification Authority. The OPDIV PKI Manager shall work in coordination with the root CAs PKI Manager. 6. Applicable Laws/Guidance The following Legislative Mandates are applicable: 7. Information and Assistance Direct questions, comments, suggestions or requests for further information to the Deputy Assistant Secretary for Information Resources Management, (202) 690-6162. 8. Effective DateThis policy is effective on the approval date. 9. Approved ________/s/______________________ ___01/08/01___ John J. Callahan Glossary Authenticate - To confirm the identity of an entity when that identity is presented. Authentication - Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual's authorization to receive specific categories of information. Certificate - A digital representation of information which at least (1) identifies the certification authority issuing it, (2) names or identifies its subscriber, (3) contains the subscriber's public key, (4) identifies its operational period, and (5) is digitally signed by the certification authority issuing it. Certification Authority (CA) - An authority trusted by one or more users to issue and manage X.509 Public Key Certificates. Digital Certificate - The result of a transformation of a message by means of a cryptographic system using keys such that a Relying Party can determine: (1) whether the transformation was created using the private key that corresponds to the public key in the signer’s digital certificate; and (2) whether the message has been altered since the transformation was made. Federal Bridge Certification Authority (FBCA) - The Federal Bridge Certification Authority consists of a collection of Public Key Infrastructure components (Certificate Authorities, Directories, Certificate Policies and Certificate Practice Statements) that are used to provide peer to peer interoperability among Agency Principal Certification Authorities. 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. Relying Party - A person or Agency who has received information that includes a certificate and a digital signature verifiable with reference to a public key listed in the certificate, and is in a position to rely on them. 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. Subordinate CA - In a hierarchical PKI, a CA whose certificate signature key is certified by another CA, and whose activities are constrained by that other CA. Trusted Certificate - A certificate that is trusted by the Relying Party on the basis of secure and authenticated delivery. The public keys included in trusted certificates are used to start certification paths. Also known as a "trust anchor". |
Last revised: January 8, 2001
 |