THSA Direct Ecosystem Community X.509 Certificate Policy (THSA CP)

Transcription

1 THSA Direct Ecosystem Community X.509 Certificate Policy (THSA CP) Draft for Public Comment Current Version: Version 1.0 Draft

2 Table of Contents 1 Introduction Overview Certificate Policy (CP) Relationship between this THSA CP and a Corresponding CPS Relationship between this THSA CP and the CA CP Document Name and Identification PKI Participants PKI Authorities Registration Authorities (RAs) Subscribers Relying Parties (RPs) Other Participants Certificate Usage Appropriate Certificate Uses Prohibited Certificate Uses Policy Administration Organization Administering the Document Contact Person Person Determining Certification Practices Statement Suitability for the Policy Certification Practices Statement Approval Procedures Definitions and Acronyms Acronyms Definitions Publication and Repository Responsibilities Repositories Repository Obligations Publication of Certification Information Publication of Certificates and Certificate Status Publication of CA Information Interoperability Frequency of Publication Access Controls on Repositories Identification and Authentication Naming Types of Names Need for Names to be Meaningful Anonymity or Pseudonymity of Subscribers Rules for Interpreting Various Name Forms Uniqueness of Names Recognition, Authentication, & Role of Trademarks Impersonation Certificates Initial Identity Validation Method to Prove Possession of Private Key Authentication of Organization Identity

3 Authentication of Individual Identity Non- verified Subscriber Information Validation of Authority Criteria for Interoperation Identification and Authentication for Re- key Requests Identification and Authentication for Routine Re- key Identification and Authentication for Re- key after Revocation Identification and Authentication for Revocation Request Certificate Life- Cycle Application Submission of Certificate Application Enrollment Process and Responsibilities Certificate Application Processing Performing Identification and Authentication Functions Approval or Rejection of Certificate Applications Time to Process Certification Applications Issuance CA Actions During Certificate Issuance Notification to Subscriber of Certificate Issuance Certificate Acceptance Conduct Constituting Certificate Acceptance Publication of the Certificate by the CA Notification of Certificate Issuance by the CA to Other Entities Key Pair and Certificate Usage Subscriber Private Key and Certificate Usage Relying Party Public Key and Certificate Usage Certificate Renewal Circumstance for Certificate Renewal Who May Request Renewal Processing Certificate Renewal Requests Notification of New Certificate Issuance to Subscriber Conduct Constituting Acceptance of a Renewal Certificate Publication of the Renewal Certificate by the CA Notification of Certificate Issuance by the CA to Other Entities Certificate Re- Key Circumstance for Certificate Re- Key Who May Request Certification of a New Public Key Processing Certificate Re- Keying Requests Notification of New Certificate Issuance to Subscriber Conduct Constituting Acceptance of a Re- Keyed Certificate Publication of the Re- keyed Certificate by the CA Notification of Certificate Issuance by the CA to Other Entities Modification Circumstance for Certificate Modification Who May Request Certificate Modification Processing Certificate Modification Requests Notification of New Certificate Issuance to Subscriber

4 Conduct Constituting Acceptance of Modified Certificate Publication of the Modified Certificate by the CA Notification of Certificate Issuance by the CA to Other Entities Certificate Revocation and Suspension Circumstances for Revocation Who Can Request Revocation Procedure for Revocation Request Revocation Request Grace Period Time Within Which CA Must Process the Revocation Request Revocation Checking Requirements for Relying Parties CRL Issuance Frequency Maximum Latency of CRLs On- Line Revocation/Status Checking Availability On- Line Revocation Checking Requirements Other Forms of Revocation Advertisements Available Special Requirements Related to Key Compromise Circumstances for Suspension Who Can Request Suspension Procedure for Suspension Request Limits on Suspension Period Certificate Status Services Operational Characteristics Service Availability Optional Features End of Subscription Key Escrow and Recovery Key Escrow and Recovery Policy and Practices Session Key Encapsulation and Recovery Policy and Practices Facility Management and Operations Controls Physical Controls Site Location and Construction Physical Access Power and Air Conditioning Water Exposures Fire Prevention and Protection Media Storage Waste Disposal Off- Site Backup Procedural Controls Trusted Roles Number of Persons Required Per Task Identification and Authentication for Each Role Separation of Roles Personnel Controls Background, Qualifications, Experience, and Security Clearance Requirements Background Check Procedures Training Requirements

5 Retraining Frequency and Requirements Job Rotation Frequency and Sequence Sanctions for Unauthorized Actions Independent Contractor Requirements Documentation Supplied to Personnel Audit Logging Procedures Types of Events Recorded Frequency of Processing Log Retention Period for Audit Logs Protection of Audit Logs Audit Log Backup Procedures Audit Collection System (internal vs. external) Notification to Event- Causing Subject Vulnerability Assessments Records Archival Types of Events Archived Retention Period for Archive Protection of Archive Archive Backup Procedures Requirements for Time- Stamping of Records Archive Collection System (Internal vs. External) Procedures to Obtain & Verify Archive Information Key Changeover Compromise and Disaster Recovery Incident and Compromise Handling Procedures Computing Resources, Software, and/or Data Are Corrupted Entity Private Key Compromise Procedures Business Continuity Capabilities after a Disaster CA and RA Termination Technical Security Controls Key Pair Generation and Installation Key Pair Generation Private Key Delivery to Subscriber Public Key Delivery to Certificate Issuer CA Public Key Delivery to Relying Parties Key Sizes Public Key Parameters Generation and Quality Checking Key Usage Purposes (as per X.509 v3 key usage field) Private Key Protection and Cryptographic Module Engineering Controls Cryptographic Module Standards and Controls Private Key Multi- Person Control Private Key Escrow Private Key Backup Private Key Archival Private Key Transfer into or from a Cryptographic Module Private Key Storage on Cryptographic Module Method of Activating Private Keys

6 Methods of Deactivating Private Keys Method of Destroying Private Keys Cryptographic Module Rating Other Aspects of Key Management Public Key Archival Certificate Operational Periods/Key Usage Periods Activation Data Activation Data Generation and Installation Activation Data Protection Other Aspects of Activation Data Computer Security Controls Specific Computer Security Technical Requirements Computer Security Rating Life- Cycle Security Controls System Development Controls Security Management Controls Life Cycle Security Ratings Network Security Controls Time Stamping Certificate, CRL, and OCSP Profiles Format Certificate Profile Version Numbers Certificate Extensions Algorithm Object Identifiers Name Forms Name Constraints Certificate Policy Object Identifier Usage of Policy Constraints Extension Policy Qualifiers Syntax and Semantics Processing Semantics for the Critical Certificate Policy Extension CRL Profile Version Numbers CRL and CRL Entry Extensions OCSP Profile Compliance Audits and Other Assessments Frequency and Circumstances of Assessment Identity/Qualifications of Assessor Assessor s Relationship to Assessed Entity Topics Covered by Assessment Actions Taken as a Result of Deficiency Communication of Results Other Business and Legal Matters Fees Certificate Issuance/Renewal Fees Certificate Access Fees Revocation or Status Information Access Fee

7 Fees for other Services Refund Policy Financial Responsibility Insurance Coverage Other Assets Insurance/Warranty Coverage for End- Entities Confidentiality of Business Information Scope of Confidential Information Information not within the scope of Confidential Information Responsibility to Protect Confidential Information Privacy of Personal Information Privacy Plan Information Treated as Private Information Not Deemed Private Responsibility to Protect Private Information Notice and Consent to Use Private Information Disclosure Pursuant to Judicial/Administrative Process Other Information Disclosure Circumstances Intellectual Property Rights Representations and Warranties CA Representations and Warranties RA Representations and Warranties Subscriber Representations and Warranties Relying Parties Representations and Warranties Representations and Warranties of Affiliated Organizations Representations and Warranties of Other Participants Disclaimers of Warranties Limitations of Liabilities Indemnities Term and Termination Term Termination Effect of Termination and Survival Individual Notices and Communications with Participants Amendments Procedure for Amendment Notification Mechanism and Period Circumstances Under Which OID Must be Changed Dispute Resolution Provisions Governing Law Compliance with Applicable Law Miscellaneous Provisions Entire Agreement Assignment Severability Enforcement (Attorney Fees/Waiver of Rights) Force Majeure Other Provisions

8

9 Document Change History Version Date Approval Description 1.0 Draft THSA has approved this release Initial THSA CP, based on version for draft public review purposes 0.9 of the S&I Framework CP approved , the Rhode Island CP version 1.0 Draft, and the Federal Bridge CP 2.25, dated

10 Introduction This THSA Direct Ecosystem Community X.509 Certificate Policy (CP) follows the structure of Internet Engineering Task Force (IETF) Internet X.509 Public Key Infrastructure (PKI) Certificate Policy and Certification Practices Framework (RFC ). Although the intent of the THSA is to provide a stable environment, including a stable CP, the THSA reserves the right to change this CP in response to industry developments such as new state or federal requirements, new security best practices, new use case requirements, or interoperability concerns. The THSA shall notify any THSA Approved HISPS (defined below) of changes to this CP; provided, however, that it is the responsibility of the THSA Approved HISP to keep its contact information up to date with the THSA. The PKI to which this CP applies supports entities and applications involved in the exchange of electronic messages grounded in the specification of the Direct Project 2. The Direct Project is an initiative sponsored by the Office of the National Coordinator (ONC) for Health Information Technology 3 to encourage adoption of secure clinical and administrative messaging within the healthcare system. The THSA CP is derived from the approved Certificate Policy issued by the Direct Project process 4. This document applies to all THSA White Space Qualified HISP Vendors and all other Direct participants that are approved by the THSA to be contained within the THSA trust bundle. BY SELF-ATTESTING TO COMPLIANCE WITH THIS CP AND/OR REQUESTING THAT THE THSA INCLUDE YOUR TRUST ANCHOR CERTIFICATE FOR PURPOSES OF BECOMING A THSA APPROVED HISP IN ORDER TO HAVE YOUR TRUST ANCHOR CERTIFICATE INCLUDED IN THE THSA TRUST BUNDLE, YOU HEREBY AGREE THAT THE ORGANIZATION THAT IS MAKING THE CERTIFICATION OR REQUEST WILL BE BOUND BY THE TERMS OF THIS CP AND THAT YOU HAVE THE AUTHORITY, AS ATTESTOR OR REQUESTOR, TO BIND YOUR ORGANIZATION TO THESE TERMS. Technologically the Direct Project is based on S/MIME message signatures and message encryption for the purposes of achieving privacy, authentication, message integrity, and non-repudiation. This CP is intended to be fully consistent with the Federal Bridge Certification Authority 1 Document may be found at: 2 Document and wiki page may be found at: 3 Web site may be found at: home/ Wiki page may be found at: 10

11 (FBCA) Certificate Policy 5 in general, and the Medium assurance level of edition in particular. However, this CP is also intended to specify policies that further constrain the conditions under which THSA Direct Ecosystem conformant digital certificates may be issued. In any case where this CP found inconsistent or incompatible with the FBCA CP, the incompatibilities will be addressed by the THSA, or such entity such as the THSA may later designate. This CP uses the key words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "not recommended", "may", and "optional". These are to be interpreted as described in RFC RFC 2119 gives the following definitions: 1. must This word, or the terms "required" or "shall", mean that the definition is an absolute requirement of the specification. 2. must not This phrase, or the phrase "shall not", mean that the definition is an absolute prohibition of the specification. 3. should This word, or the adjective "recommended", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. should not This phrase, or the phrase "not recommended" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. 5. may This word, or the adjective "optional", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option must be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option must be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) 1.1 Overview This THSA Direct Ecosystem Community X.509 Certificate Policy Draft for Public Comment (THSA CP) describes the unified policy under which a THSA-conforming Certificate Authority ( Conforming CA ) operates. Specifically, this document defines 5 Document may be found at: 6 Note: All dates specified in this document follow the ISO 8601 date format of yyyymm-dd (year-month-day)

12 the creation and management of X.509 version 3 public key certificates for use in applications supporting HHS/ONC Direct Project message exchange. In the context of this document, the term CA is intended to include a Certification Authority and its related components such as a Registration Authority, Validation Authority, internal certificate life cycle management systems, databases, and processes unless otherwise specified Certificate Policy (CP) Digital Certificates that conform to this CP ( Conforming Certificates ) MUST contain a registered certificate policy object identifier (OID) which SHOULD be used by a Relying Party to decide whether a certificate is trusted for a particular purpose. The OID corresponds to a specific level of assurance established by this Certificate Policy (CP) that SHALL be available to Relying Parties. A certificate issued by a Conforming CA MUST assert the OID in the certificatepolicies extension Relationship between this THSA CP and a Corresponding CPS Although, at this time, the THSA does not intend to publish a Certification Practices Statement (CPS), the THSA MAY publish such in the future. The THSA MAY establish and document procedures to support the publishing of a Declaration of Conformance by CAs issuing digital certificates conforming to the requirements of this CP. The THSA Qualified HISP Vendors MUST issue and publish a CP, a CPS, and a Declaration of Conformance with this CP. Such documents MUST be available to members of the public Relationship between this THSA CP and the CA CP A Conforming CA MUST assert a mapping between its CP and this CP in the policymappings extension of its CA certificate. 1.2 Document Name and Identification This CP currently defines one level of assurance (other levels MAY be defined when, and if, needed in the future). This single level of assurance is assigned the following object identifier (OID), which is registered via the HL7 OID Registry as follows: x.y.z Conforming Certificates MUST assert this level of assurance by listing this OID in the certificatepolicies X.509v3 standard extension. However, the Direct Project specification does not explicitly require utilization of policy OIDs as a mechanism of asserting trust. Rather a set of trust anchor certificates are maintained by a Relying Party and each presented certificate MUST chain to a certificate within this set of trust anchor certificates. THSA intends to publish and maintain a collection of trust anchor certificates (a "trust bundle") from Conforming CAs that the Relying Party SHOULD 12

13 include in its set of trust anchor certificates. This bundle will be published in a format to be determined at a later time. 1.3 PKI Participants The following are roles relevant to the administration and operation of the THSA Diect Ecosystem PKI. Although certificates SHOULD be issued to human Direct end-users, the THSA does NOT require such PKI Authorities Direct Project The Direct Project 8 developed the Direct Ecosystem Community x.509 Certificate Policy version 0.9 dated in accordance with its consensus process. This THSA Direct Ecosystem Community Certificate Policy Draft for Public Comment modifies that document so that it can be referenced in Conforming Certificates and to provide a set of interim policies under which Conforming CAs may publish their subordinate CPs and/or CPSs and self-attest to their compliance with the THSA s CP The Texas Health Services Authority (THSA) The THSA is a public/private partnership organized as a 501(c)(3) non-profit working in partnership with its fiscal agent, the Texas Health and Human Services Commission, operated for participants of the Texas White Space Direct community, along with other purposes Certification Authorities (CAs) A Certification Authority (CA) in this context is an entity that signs Certificate Signing Requests (CSRs) and issues public key X.509 certificates to Subscribers. Conforming CAs MUST create a Certificate Policy and MUST create a Certification Practices Statement (CPS) that is conformant to the policies of this CP Registration Authorities (RAs) RAs collect and verify identity information from Subscribers using procedures that implement the identity validation policies set forth in this document. The RA creates CSRs for submission to a CA. RA entities MUST utilize identity validation policies defined in this Certificate Policy (CP). 8 The Direct Project currently maintains a web site at: 9 The Direct Project CP currently may be found at: 13

14 Subscribers A THSA Direct Ecosystem Subscriber ( Subscriber ) is an entity whose identifying information appears as the subject in an X.509 certificate and who uses its private key and public certificate in accordance with this certificate policy. A Subscriber is serviced by and has a legal relationship with the HISP Vendor or other organization that is providing for x.509 public key management services for that subscriber Relying Parties (RPs) A Relying Party (RP) is the entity that uses a Subscriber s X.509 certificate to verify the integrity of a digitally signed message, to identify the creator of a message, or to establish confidential communications with the Subscriber. The RP MUST check the authenticity, integrity, validity period, revocation status, intended use, and valid chain of trust, of the Asserting Party s (APs) certificate for each transaction as per section Other Participants The Asserting Party (AP) is the entity making a claim about the authenticity and possession of THSA x.509 certificate and is initiating a Direct message. 1.4 Certificate Usage Appropriate Certificate Uses The primary anticipated use for Conforming Certificates is in the exchange of electronic messages grounded in the specifications of the Direct Project. This includes PKI based S/MIME message signature verification and S/MIME message encryption Prohibited Certificate Uses Conforming Certificates issued under this CP MUST only be used for THSA Direct messaging, or for exchange of healthcare data with systems integrated with the THSA Direct Ecosystem (such as EMRs or other health information exchange networks). 1.5 Policy Administration Organization Administering the Document The THSA, or such other entity as it may designate, is responsible for all aspects of governance of this document Contact Person 14

15 Questions regarding this certificate policy should be directed to: direct-admin *at* THSA *dot* org Texas Health Services Authority San Jacinto Building 221 East 9th Street Suite 201 Austin, Texas USA The THSA MAY change the designated THSA contact pursuant to this Section by issuing notice to the THSA Approved HISP Person Determining Certification Practices Statement Suitability for the Policy The Certification Practices Statement states how a Conforming CAs establishes the assurance required by the corresponding Certificate Policy of the Conforming CA. Each Conforming CA is responsible for asserting that their CPS conforms to their CP and that their CP maps to the requirements of this THSA CP. The Conforming CA MUST designate the person or organization authorized to make these assertions. See Section 8 for further details Certification Practices Statement Approval Procedures Each Conforming CA shall submit the related CPS to a compliance analysis and audit against this CP as described in Section 8 of this CP. Conforming CA s CPS shall be required to meet all facets of its policy. The CA may not declare conformance with this CP until the compliance analysis and audit is complete and all discrepancies resolved. 1.6 Definitions and Acronyms Acronyms Acronym Meaning AP Asserting Party CA Certification Authority CP Certificate Policy CPS Certification Practice Statement CRL Certificate Revocation List DN Distinguished Name ID Identity 15

16 IETF Internet Engineering Task Force OCSP Online Certificate Status Protocol OID Object IDentifier ONC Office of the National Coordinator for Health Information Technology PKI Public Key Infrastructure RA Registration Authority RFC RP Request For Comments Relying Party S/MIME Secure Multipurpose Internet Mail Extensions Definitions Term Approved HISP Certificate Certification Authority Certificate Policy Definition A Direct Health Information Service Provider that is compliant with this CP, and has been added to the THSA trust bundle. 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. An authority trusted by one or more users to create, assign, and manage the entire life cycle of certificates. In this CP, the term Certification Authority (CA) refers to a CA proper AND to the related broader systems and services such as Subordinate CAs, Issuing CAs, Registration Authorities, staff, data centers, and Validation Authorities. A Certificate Policy is a specialized form of administrative policy tuned to electronic transactions performed during certificate management. A Certificate Policy addresses all aspects associated with the generation, production, distribution, accounting, compromise recovery and administration of digital certificates. A statement of the practices that a CA employs in issuing, Certificate suspending, revoking and renewing certificates and providing access Practice Statement to them, in accordance with specific requirements typically provided in a certificate policy. Certificate Revocation List Conforming A list, published and maintained by a Certification Authority, of the certificates which it has issued that have been revoked or suspended prior to their stated expiration date. A Certificate issued by a Conforming Certification Authority. 16

17 Certificate Conforming Certification Authority Conforming Registration Authority Direct Project Internet Engineering Task Force Integrating the Healthcare Enterprise (IHE) Private Key Public Key Public Key Infrastructure Qualified HISP Registration Authority Relying Party Subscriber THSA Approved HISP A Certification Authority (CA) that is compliant with this CP. A Registration Authority that is compliant with this CP. An initiative from the Office of the National Coordinator (ONC) for Health Information Technology that created a set of standards and services that, with a policy framework, enables simple, routed, scalable, and secure message transport over the Internet between known participants. A standards development organization responsible for the creation and maintenance of many Internet-related technical standards. An ISO liaison A Standards Development Organization (SDO) focused on creating implementation ready profiles based on other widely accepted standards such as HL7 CDA and OASIS SAML 2. (1) The key of a signature key pair used to create a digital signature. (2) The key of an encryption key pair that is used to decrypt confidential information. In both cases, this key must be kept secret. (1) The key of a signature key pair used to validate a digital signature. (2) The key of an encryption key pair that is used to encrypt confidential information. In both cases, this key is made publicly available normally in the form of a digital certificate. 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. A Direct Health Information Service Provider that has been approved under the THSA white space program to offer Direct services to designated counties. Entity responsible for identification and authentication of certificate subjects. A person or Entity 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. A Subscriber is an entity that (1) is the subject named or identified in a certificate issued to that entity, (2) holds a private key that corresponds to the public key listed in the certificate, and (3) does not itself issue certificates to another party. An entity that has been found to comply with this CP, and has been added to the THSA-governed trust bundle. 17

18 Trust Bundle Trusted Agent A package containing a list of approved HISP x.509 certificate anchor apexes. As constrained by this CP, a human acting on behalf of the RA to perform certain Subscriber identity proofing activities. 2 Publication and Repository Responsibilities 2.1 Repositories Conforming CAs shall operate repositories in support of operations required by this CP and related CPS Repository Obligations 2.2 Publication of Certification Information Publication of Certificates and Certificate Status Each Conforming CA MUST maintain a Certificate Revocation List (CRL) and expose its location in the CRL Distribution Points X.509v3 extension. Conforming CAs MUST support the HTTPS if-modified-since request header, and MUST support distribution of differential CRLs. Each Conforming CA MAY also maintain an equivalent Online Certificate Status Protocol (OCSP) Responder Network and expose its location in the Authority Information Access X.509 extension. A Conforming CA MAY maintain both a CRL and OCSP Responder Network. In addition, Conforming CAs MAY maintain other certificate revocation publication methods. Conforming CA s root and Subordinate (issuing) CA s private keys MUST be stored in a Hardware Security Module (HSM) Publication of CA Information Each Conforming CA shall publish information concerning the CA necessary to support its operation and use. CA shall notify and publish its root trust anchor point certificate or certificates to the THSA as per section Information on how to obtain a copy of this Certificate Policy shall be provided to any party with a legitimate interest. 18

19 Interoperability 2.3 Frequency of Publication This CP, and any ensuing changes, shall be made available within 14 days of approval by the THSA. CRLs from Conforming CAs MUST expire every 30 days or less. The CRL MUST be regenerated and issued with a frequency as defined in section (CRL Issue Frequency) and a maximum latency as per section (Maximum Latency of CRLs). 2.4 Access Controls on Repositories Conforming CAs shall protect repository information not intended for public dissemination or modification. 3 Identification and Authentication 3.1 Naming Types of Names Conforming Certificates shall use non-null DN name forms for the Issuer and Subject names. As specified in the Direct Project Applicability Statement for Secure Health Transport 10, certificates tied to full (individual) Direct addresses shall contain the Direct address in the subjectaltname extended attribute as an rfc822name and optionally in the legacy Address attribute of the Subject Distinguished Name. Certificates tied to a Direct domain (organization) shall contain the domain name in two places: 1. The subjectaltname extension formatted as a dnsname, and 2. The CN of the Subject DN Need for Names to be Meaningful Conforming Certificate Names shall uniquely identify the Subscriber and shall be easily understood by humans Anonymity or Pseudonymity of Subscribers

20 Conforming CAs shall not issue anonymous or pseudonymous certificates Rules for Interpreting Various Name Forms Uniqueness of Names Conforming CAs shall enforce name uniqueness within the CA's X.500 namespace of the certificate Subject DN Recognition, Authentication, & Role of Trademarks Conforming CAs will not knowingly use trademarks in names unless the Subject of the certificate possesses the rights to use that name Impersonation Certificates A Conforming CAs, and subordinate CAs (if utilized), MUST not issue certificates for domains other than those domains registered by and under the control of clients contracting with that HISP vendor, except as required to comply with a court order issued by a court with appropriate jurisdiction for a specific domain, and such a court ordered impersonation certificate MUST only be used to monitor a specific, named, human within an organization. 3.2 Initial Identity Validation Method to Prove Possession of Private Key In the case where the private key is generated by the RA, no proof of private key possession is required. In the case where the Subscriber named in the certificate generates its own private key, then the Subscriber MUST digitally sign a known piece of data with the private key and send it to the Conforming CA. The Conforming CA will verify the signature and the known piece of data thus proving private key possession Authentication of Organization Identity Requests for organizational certificates MUST include the organization name, mailing address and documentation of the existence of the organization as well as the requested domain name that will appear in the certificate (see section for details). The RA MUST verify that the requesting organization is a HIPAA covered entity or business associate, or is a healthcare related organization which treats protected health 20

21 information with privacy and security protections that are equivalent to those required by HIPAA. The RA MUST NOT submit a single CSR representing multiple legally distinct requesting entities to a CA. In other words, one certificate may not be used to represent multiple legally distinct entities. The RA shall verify the organization information submitted, in addition to the authenticity of the requesting representative and the representative s authorization to act in the name of the organization Authentication of Individual Identity Authentication of Human Subscribers Validation of the identity of an individual is required: (1) To verify the identity of a representative of an organization requesting a organizational Conforming Certificate, (2) To verify the identity of a human individual requesting a Conforming Certificate, (3) To verify the identity of Trusted Agents, (4) To verify the identity the human sponsor of a machine certificate, and (5) To verify the identity of a member of a role or group certificate. Initial identity proofing and credentials issuance SHALL adhear to at least NIST Level 3 assurance Electronic Authentication Guideline, released December Authentication of Human Subscribers for Role-based Certificates There is a subset of human subscribers who will be issued role-based certificates. These certificates will identify a specific role on behalf of which the subscriber is authorized to act rather than the subscriber s name and are issued in the interest of supporting accepted business practices. The role-based certificate can be used in situations where nonrepudiation is desired. Normally, it will be issued in addition to an individual subscriber certificate. A specific role may be identified in certificates issued to multiple subscribers, however, the key pair will be unique to each individual role-based certificate (i.e. there may be four individuals carrying a certificate issued in the role of Chief Information Officer however, each of the four individual certificates will carry unique keys and certificate identifiers). Roles for which role-based certificates may be issued are limited to those that uniquely identify a specific individual within an organization (e.g., Chief Information Officer is a unique individual whereas Program Analyst is not). Rolebased certificates shall not be shared, but shall be issued to individual subscribers and protected in the same manner as individual certificates. Conforming CAs shall record the information identified in Section for a sponsor associated with the role before issuing a role-based certificate. The sponsor MUST hold

22 an individual certificate in his/her own name issued by the same CA at the same or higher assurance level as the role-based certificate. The procedures for issuing role-based tokens MUST comply with all other stipulations of this CP (e.g., key generation, private key protection, and Subscriber obligations). Pseudonymous certificates are not allowed for role-based certificates other than as stipulated in this section Authentication of Human Subscribers for Group Certificates Normally, a certificate shall be issued to a single Subscriber. For cases where there are several entities acting in one capacity, and where non-repudiation for transactions is not desired, a certificate may be issued that corresponds to a private key that is shared by multiple Subscribers. Conforming CAs shall record the information identified in Section for a sponsor before issuing a group certificate. In addition to the authentication of the sponsor, the following procedures shall be performed for members of the group: 1. The group s organization 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. 2. The subjectname DN MUST NOT imply that the subject is a single individual, e.g. by inclusion of a human name form; 3. The list of those holding the shared private key MUST be provided to, and retained by, the applicable CA or its designated representative; and 4. 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) Authentication of Devices Some computing and communications devices and services (routers, firewalls, servers, XD* transcoding proxies, EMR gateways, etc.) will be named as certificate Subjects. In such cases, the device must have a human sponsor. The sponsor is responsible for providing the following registration information: 1. Equipment identification (e.g., serial number) or service name (e.g., DNS name) 2. Equipment public keys 3. Equipment authorizations and attributes (if any are to be included in the certificate) 4. Contact information to enable the CA or RA to communicate with the sponsor when required 22

23 These certificates shall be issued only to devices and services under the issuing entity s control (i.e., require registration and validation that meets all issuing agency s requirements, as well as requiring re-validation prior to being re-issued). In the case a human sponsor is changed, the new sponsor shall review the status of each device under his/her sponsorship to ensure it is still authorized to receive certificates. The CPS shall describe procedures to ensure that certificate accountability is maintained. The identity of the device or service sponsor shall be verified as per Section Non-verified Subscriber Information See section Validation of Authority The conforming RA must verify the association between an organization requesting an organizational certificate and the individual representing the organization Criteria for Interoperation To be deemed a Conforming CA, the CA shall issue certificates according to this CP or by a CP that meets equivalent criteria. 3.3 Identification and Authentication for Re-key Requests Identification and Authentication for Routine Re-key The identity of an organization and/or individual requesting a re-key of a Conforming Certificate must be established through the initial identity verification process or through proof of possession of the private key via a digital signature Identification and Authentication for Re-key after Revocation If a Conforming Certificate is revoked, the Subscriber shall go through the initial identity verification process described in section 3.2 to obtain a new Conforming Certificate. 3.4 Identification and Authentication for Revocation Request The Subscriber shall go through the initial identity verification process described in section 3.2 to request revocation of a certificate issued to that Subscriber. 23

24 Certificate Life-Cycle 4.1 Application This section specifies requirements for the initial application for a Conforming Certificate Submission of Certificate Application The Conforming RA creates the official Certificate Signing Request (CSR) based on input received from the Subscriber during the identity verification process Enrollment Process and Responsibilities A Subscriber is responsible for providing accurate information about himself and his organization during identity verification. The Conforming RA is responsible for archiving Subscriber data for audit purposes. 4.2 Certificate Application Processing The Conforming CA and RA are responsible for verifying that the information in a Certificate Signing Request (CSR) is accurate and reflects the information presented by the Subscriber Performing Identification and Authentication Functions The identity verification of Subscribers shall be done by the Conforming RA as specified in section Approval or Rejection of Certificate Applications A certificate application may be rejected by a Conforming CA due to missing or inaccurate information. Each Conforming CA governing body retains the right to reject Conforming Certificate applications if, in its judgment, the requesting individual or organization does not have a legitimate reason to possess a Conforming Certificate Time to Process Certification Applications All Subscriber information placed in a THSA Direct Ecosystem certificate must be verified within 5 business days and a certificate issued within 1 business day of completion of verification. 4.3 Issuance 24

25 CA Actions During Certificate Issuance The Conforming CA will ensure that the public key is bound to the correct Subscriber and generate the X.509 certificate. The Conforming CA will publish the certificate as specified in section Notification to Subscriber of Certificate Issuance The Subscriber must be notified via physical mail or that his certificate has been issued if such notification is relevant to the Subscriber s usage of the certificate. 4.4 Certificate Acceptance Conduct Constituting Certificate Acceptance Use of a Conforming Certificate by the Subscriber is considered acceptance of the certificate Publication of the Certificate by the CA The appropriate entity publishes Subscriber certificates in a directory specified in section Notification of Certificate Issuance by the CA to Other Entities 4.5 Key Pair and Certificate Usage Subscriber Private Key and Certificate Usage Subscribers who take possession of their private key shall protect it from access by unauthorized parties and shall be sign an acknowledgement indicating that they are aware of proper key management techniques and agree to comply with such techniques Relying Party Public Key and Certificate Usage Conforming Certificates SHALL conform to the policies provided by this CP. RPs should understand these policies. Conforming CAs MUST publish a certificate revocation list (CRL). Conforming CAs MAY also maintain an OCSP Responder network, or other certificate revocation publishing mechanisms. RPs MUST check for expired, suspended, or revoked certificates each transaction. 4.6 Certificate Renewal 25

26 Certificate renewal consists of issuing a new certificate with a new validity period and serial number while retaining all other information in the original certificate including the public key. Frequent renewal of certificates may assist in reducing the size of CRLs. After certificate renewal, the old certificate may or may not be revoked, but must not be further re-keyed, renewed, or modified Circumstance for Certificate Renewal A certificate may be renewed if the public key has not reached the end of its validity period, the associated private key has not been compromised, and the Subscriber name and attributes are unchanged. Certificates may also be renewed if the Conforming CA rekeys Who May Request Renewal Conforming CAs may request renewal of its own certificate. For Subscriber certificates, the Subscriber himself or the Conforming RA may request renewal Processing Certificate Renewal Requests Conforming CAs shall approve or reject Subscriber certificate renewal requests. Identity verification of the Subscriber shall be equivalent to the initial identity verification process or executed via proof of possession of the private key through a digital signature Notification of New Certificate Issuance to Subscriber The Subscriber is to be notified as per section Conduct Constituting Acceptance of a Renewal Certificate Use by the Subscriber of any application using a Conforming Certificate is considered acceptance of the certificate Publication of the Renewal Certificate by the CA Conforming CAs publish Subscriber certificates in a directory as specified in section Notification of Certificate Issuance by the CA to Other Entities Each Conforming CA must notify the THSA of issuance of its trust anchor point certificate(s), and provide the trust anchor point certificate(s) public keys to the THSA, in a mutually agreeable manner, so that the THSA may maintain and publish a bundle of such certificates for each Qualified HISP and THSA-approved trust anchor point. Trust anchor point sets will be published by the THSA in the same manner as the Internet 26