HCDirect Certification Practices Statement (CPS) Health ... · HCDirect Certification Practices...

HCDirect Certification Practices Statement (CPS)

Health Companion, Inc.

Approvals

[CEO]

[CTO]

Version 1.04

Effective Since 18 Aug 2014

Policy ID HCDP300

HCDirect Certification Practices Statement (CPS) CPS

Health Companion, Inc. Page 2 of 50

Table of Contents

1 Introduction .................................................................................................. 12

1.1 Overview ............................................................................................... 12

1.1.1 Certificate Policy (CP) ................................................................... 12

1.1.2 Relationship between this DirectTrust CP and a Corresponding CPS 12

1.1.3 Relationship between this DirectTrust CP and the CA CP ............ 12

1.1.4 Relationship between DirectTrust CP and EHNAC-DirectTrust Accredited Entities ....................................................................................... 12

1.2 Document Name and Identification ....................................................... 12

1.3 Public Key Infrastructure (PKI) Participants .......................................... 13

1.3.1 Certification Authorities .................................................................. 13

1.3.2 Registration Authority (RA) ............................................................ 13

1.3.3 Subscribers ................................................................................... 13

1.3.3.1 Custodian ................................................................................... 14

1.3.3.2 Health Information Service Providers(HISPs) ............................ 14

1.3.4 Relying Parties .............................................................................. 14

1.3.5 Other Participants .......................................................................... 14

1.4 Certificate Usage .................................................................................. 14

1.4.1 Appropriate Certificate Uses .......................................................... 14

1.4.2 Prohibited Certificate Uses ............................................................ 14

1.5 Policy Administration ............................................................................ 15

1.5.1 Organization Administering the Document .................................... 15

1.5.2 Contact Person .............................................................................. 15

1.5.3 Person Determining CPS Suitability for Policy .............................. 15

1.5.4 CPS Approval Procedures ............................................................. 15

1.6 Definitions and Acronyms ..................................................................... 15

1.6.1 Acronyms ...................................................................................... 15

1.6.2 Definitions ...................................................................................... 16

2 Publication and Repository Responsibilities ................................................ 18

2.1 Repositories .......................................................................................... 18

2.1.1 Repository Obligations .................................................................. 18

2.2 Publication of Certification Information ................................................. 18



2.2.1 Publication of Certificates and Certificate Status ........................... 18

2.2.2 Publication of CA Information ........................................................ 18

2.2.3 Interoperability ............................................................................... 18

2.3 Frequency of Publication ...................................................................... 18

2.4 Access Control on Repositories ............................................................ 18

3 Identification and Authentication .................................................................. 19

3.1 Naming ................................................................................................. 19

3.1.1 Types of Names ............................................................................ 19

3.1.2 Need for Names to be Meaningful ................................................. 19

3.1.3 Anonymity of Pseudonymity of Subscribers .................................. 19

3.1.4 Rules for Interpreting Various Name Forms .................................. 20

3.1.5 Uniqueness of Names ................................................................... 20

3.1.6 Recognition, Authentication, and Role of Trademarks................... 20

3.2 Initial Identity Validation ........................................................................ 20

3.2.1 Method to Prove Possession of Private Key .................................. 20

3.2.2 Authentication of Organization Identity .......................................... 20

3.2.3 Authentication of Individual Identity ............................................... 21

3.2.3.1 Authentication of Human Subscribers ........................................ 21

3.2.3.2 Authentication of Human Subscribers for Role-based Certificates 25

3.2.3.3 Authentication of Human Subscribers for Group Certificates ..... 25

3.2.3.4 Authentication of Devices .......................................................... 26

3.2.3.5 Verification of NPI Number ........................................................ 26

3.2.4 Non-verified Subscriber Information .............................................. 26

3.2.5 Validation of Authority .................................................................... 26

3.2.6 Criteria for Interoperation ............................................................... 26

3.3 Identification and Authentication for Re-key Requests ......................... 26

3.3.1 Identification and Authentication for Routine Re-key ..................... 26

3.3.2 Identification and Authentication for Re-key after Revocation ....... 26

3.4 Identification and Authentication for Revocation Request .................... 26

4 Certificate Lifecycle Operational Requirements ........................................... 27

4.1 Application ............................................................................................ 27

4.1.1 Submission of Certificate Application ............................................ 27



4.1.2 Enrollment Process and Responsibilities ....................................... 27

4.2 Certificate Application Processing ........................................................ 27

4.2.1 Performing Identification and Authentication Functions ................. 27

4.2.2 Approval or Rejection of Certification Applications ........................ 27

4.2.3 Time to Process Certificate Applications ....................................... 27

4.3 Issuance ............................................................................................... 28

4.3.1 CA Actions during Certificate Issuance ......................................... 28

4.3.2 Notification to Subscriber of Certificate Issuance .......................... 28

4.4 Certificate Acceptance .......................................................................... 28

4.4.1 Conduct Constituting Certificate Acceptance ................................ 28

4.4.2 Publication of the Certificate by the CA ......................................... 28

4.4.3 Notification of Certificate Issuance by the CA to Other Entities ..... 28

4.5 Key Pair and Certificate Usage ............................................................. 28

4.5.1 Subscriber Private Key and Certificate Usage ............................... 28

4.5.2 Relying Party Public Key and Certificate Usage ............................ 28

4.6 Certificate Renewal .............................................................................. 28

4.6.1 Circumstance for Certificate Renewal ........................................... 28

4.6.2 Who May Request Renewal .......................................................... 29

4.6.3 Processing Certificate Renewal Requests ..................................... 29

4.6.4 Renewal Requests Additional Policies .......................................... 29

4.6.5 Conduct Constituting Acceptance of a Renewal Certificate ........... 29

4.6.6 Publication of the Renewal Certificate by the CA .......................... 29


4.7 Certificate Re-Key ................................................................................ 29

4.7.1 Circumstance for Certificate Re-Key ............................................. 29

4.7.2 Who May Request Certification of a New Public Key .................... 29

4.7.3 Processing Certificate Re-Key Requests ....................................... 29

4.7.4 Notification of New Certificate Issuance to Subscriber .................. 29

4.7.5 Conduct Constituting Acceptance of a Re-Keyed Certificate ......... 30

4.7.6 Publication of the Re-keyed Certificate by the CA ......................... 30


4.8 Modification .......................................................................................... 30

4.8.1 Circumstance for Certificate Modification ...................................... 30



4.8.2 Who May Request Certificate Modification .................................... 30

4.8.3 Processing Certificate Modification Requests ............................... 30

4.8.4 Notification of New Certificate Issuance to Subscriber .................. 30

4.8.5 Conduct Constituting Acceptance of Modified Certificate .............. 30

4.8.6 Publication of the Modified Certificate by the CA ........................... 30


4.9 Certificate Revocation and Suspension ................................................ 30

4.9.1 Circumstances for Revocation ....................................................... 30

4.9.2 Who Can Request Revocation ...................................................... 31

4.9.3 Procedure for Revocation Request ............................................... 31

4.9.4 Revocation Request Grace Period ................................................ 31

4.9.5 Time within Which CA Must Process the Revocation Request ...... 31

4.9.6 Revocation Checking Requirements for Relying Parties ............... 31

4.9.7 CRL Issuance Frequency .............................................................. 31

4.9.8 Maximum Latency of CRLs ........................................................... 31

4.9.9 On-Line Revocation/Status Checking Availability .......................... 31

4.9.10 On-Line Revocation Checking Requirements ................................ 32

4.9.11 Other Forms of Revocation Advertisements Available .................. 32

4.9.12 Special Requirements Related to Key Compromise ...................... 32

4.9.13 Circumstances for Suspension ...................................................... 32

4.9.14 Who Can Requests Suspension .................................................... 32

4.9.15 Procedure for Suspension Request ............................................... 32

4.9.16 Limits on Suspension Period ......................................................... 32

4.10 Certificate Status Services .................................................................... 32

4.10.1 Operational Characteristics ........................................................... 32

4.10.2 Service Availability......................................................................... 32

4.10.3 Optional Features .......................................................................... 32

4.11 End of Subscription .............................................................................. 32

4.12 Key Escrow and Recovery .................................................................... 32

4.12.1 Key Escrow and Recovery Policy and Practices ........................... 33

4.12.2 Session Key Encapsulation and Recovery Policy and Practices ... 33

5 Facility, Management and Operational Controls .......................................... 33

5.1 Physical Controls .................................................................................. 33



5.1.1 Site Location and Construction ...................................................... 33

5.1.2 Physical Access ............................................................................ 33

5.1.3 Power and Air Conditioning ........................................................... 33

5.1.4 Water Exposures ........................................................................... 33

5.1.5 Fire Prevention and Protection ...................................................... 33

5.1.6 Media Storage ............................................................................... 33

5.1.7 Waste Disposal ............................................................................. 34

5.2 Procedural Controls .............................................................................. 34

5.2.1 Trusted Roles ................................................................................ 34

5.2.1.1 Administrator .............................................................................. 34

5.2.1.2 Officer ........................................................................................ 34

5.2.1.3 Auditor ....................................................................................... 34

5.2.1.4 Operator ..................................................................................... 34

5.2.2 Number of Persons Required Per Task ......................................... 34

5.2.3 Identification and Authentication for Each Role ............................. 34

5.2.4 Roles Requiring Separation of Duties ............................................ 34

5.3 Personnel Controls ............................................................................... 35

5.3.1 Qualifications, Experience and Clearance Requirements .............. 35

5.3.2 Background Check Procedures ..................................................... 35

5.3.3 Training Requirements .................................................................. 35

5.3.4 Retraining Frequency and Requirements ...................................... 35

5.3.5 Job Rotation Frequency and Sequence ........................................ 35

5.3.6 Sanctions for Unauthorized Actions............................................... 35

5.3.7 Independent Contractor Requirements.......................................... 35

5.3.8 Documentation Supplied to Personnel .......................................... 35

5.4 Audit Logging Procedures .................................................................... 35

5.4.1 Types of Events Recorded ............................................................ 36

5.4.2 Frequency of Processing Log ........................................................ 37

5.4.3 Retention Period for Audit Log ...................................................... 37

5.4.4 Protection of Audit Log .................................................................. 37

5.4.5 Audit Log Backup Procedures ....................................................... 37

5.4.6 Audit Collection System ................................................................. 37

5.4.7 Notification to Event-Causing Subject ........................................... 37



5.4.8 Vulnerability Assessments ............................................................. 37

5.5 Records Archival .................................................................................. 37

5.5.1 Types of Records Archived ........................................................... 37

5.5.2 Retention Period for Archive .......................................................... 38

5.5.3 Protection of Archive ..................................................................... 38

5.5.4 Archive Backup Procedures .......................................................... 38

5.5.5 Requirements for Time-stamping of Records ................................ 38

5.5.6 Archive Collection System (Internal vs. External) .......................... 38

5.5.7 Procedures to Obtain & Verify Archive Information ....................... 38

5.6 Key Changeover ................................................................................... 38

5.7 Compromise and Disaster Recovery .................................................... 38

5.7.1 Incident and Compromise Handling Procedures ........................... 38

5.7.2 Computing Resources, Software, and/or Data Are Corrupted ....... 38

5.7.3 Entity Private Key Compromise Procedures .................................. 39

5.7.4 Business Continuity Capabilities after a Disaster .......................... 39

5.8 CA or RA Termination........................................................................... 39

6 Technical Security Controls ......................................................................... 39

6.1 Key Pair Generation and Installation .................................................... 39

6.1.1 Key Pair Generation ...................................................................... 39

6.1.1.1 CA Key Pair Generation ............................................................. 39

6.1.1.2 Subscriber Key Pair Generation................................................. 39

6.1.2 Private Key Delivery to Subscriber ................................................ 39

6.1.3 Public Key Delivery to Certificate Issuer ........................................ 39

6.1.4 CA Public Key Delivery to Relying Parties ..................................... 39

6.1.5 Key Sizes ...................................................................................... 40

6.1.6 Public Key Parameters Generation and Quality Checking ............ 40

6.1.7 Key Usage Purposes (as per X.509 v3 key usage field) ................ 40

6.2 Private Key Protection and Cryptographic Module Controls ................. 40

6.2.1 Cryptographic Module Standards and Controls ............................. 40

6.2.2 Private Key (n out of m) Multi-person Control ................................ 40

6.2.3 Private Key Escrow ....................................................................... 40

6.2.4 Private Key Backup ....................................................................... 40

6.2.5 Private Key Archival ...................................................................... 40



6.2.6 Private Key Transfer into or from a Cryptographic Module ............ 41

6.2.7 Private Key Storage on Cryptographic Module .............................. 41

6.2.8 Method of Activating Private Key ................................................... 41

6.2.9 Method of Deactivating Private Key............................................... 41

6.2.10 Method of Destroying Private Key ................................................. 41

6.2.11 Cryptographic Module Rating ........................................................ 41

6.3 Other Aspects of Key Management ...................................................... 41

6.3.1 Public Key Archival ........................................................................ 41

6.3.2 Certificate Operational Periods and Key Pair Usage Periods ........ 41

6.4 Activation Data ..................................................................................... 41

6.4.1 Activation Data Generation and Installation ................................... 41

6.4.2 Activation Data Protection ............................................................. 42

6.4.3 Other Aspects of Activation Data ................................................... 42

6.5 Computer Security Controls .................................................................. 42

6.5.1 Specific Computer Security Technical Requirements .................... 42

6.5.2 Computer Security Rating ............................................................. 42

6.6 Life Cycle Technical Controls ............................................................... 42

6.6.1 System Development Controls ...................................................... 42

6.6.2 Security Management Controls ..................................................... 42

6.6.3 Life Cycle Security Ratings ............................................................ 42

6.7 Network Security Controls .................................................................... 43

6.8 Time-stamping ...................................................................................... 43

7 Certificate, CRL and OCSP Profiles ............................................................ 43

7.1 Certificate Profile .................................................................................. 43

7.1.1 Version Numbers ........................................................................... 43

7.1.2 Certificate Extensions .................................................................... 43

7.1.3 Algorithm Object Identifiers ........................................................... 43

7.1.4 Name Forms .................................................................................. 43

7.1.5 Name Constraints .......................................................................... 43

7.1.6 Certificate Policy Object Identifier .................................................. 43

7.1.7 Usage of Policy Constraints Extension .......................................... 43

7.1.8 Policy Qualifiers Syntax and Semantics ........................................ 43

7.1.9 Processing Semantics for the Critical Certificate Policy Extension 44



7.2 CRL Profile ........................................................................................... 44

7.2.1 Version Numbers ........................................................................... 44

7.2.2 CRL and CRL Entry Extensions .................................................... 44

7.3 OCSP Profile ........................................................................................ 44

8 Compliance Audit and Other Assessments ................................................. 44

8.1 Frequency or Circumstances of Assessment ....................................... 44

8.2 Identity/Qualifications of Assessor ........................................................ 44

8.3 Auditor’s Relationship to Assessed Entity............................................. 44

8.4 Topics Covered by Assessment ........................................................... 44

8.5 Actions Taken as a Result of Deficiency............................................... 44

8.6 Communication of Results .................................................................... 44

9 Other Business and Legal Matters ............................................................... 45

9.1 Fees...................................................................................................... 45

9.1.1 Certificate Issuance/Renewal Fees ............................................... 45

9.1.2 Certificate Access Fees ................................................................. 45

9.1.3 Revocation or Status Information Access Fees ............................. 45

9.1.4 Fee for Other Services .................................................................. 45

9.1.5 Refund Policy ................................................................................ 45

9.2 Financial Responsibility ........................................................................ 45

9.2.1 Insurance Coverage ...................................................................... 45

9.2.2 Other Assets .................................................................................. 45

9.2.3 Insurance or Warranty Coverage for End-entities ......................... 45

9.3 Confidentiality of Business Information ................................................. 45

9.3.1 Scope of Confidential Information.................................................. 45

9.3.2 Information Not Within the Scope of Confidential Information ....... 46

9.3.3 Responsibility to Protect Confidential Information ......................... 46

9.4 Privacy of Personal Information ............................................................ 46

9.4.1 Privacy Plan .................................................................................. 46

9.4.2 Information Treated as Private ...................................................... 46

9.4.3 Information not Deemed Private .................................................... 46

9.4.4 Responsibility to Protect Private Information ................................. 46

9.4.5 Notice and Consent to Use Private Information ............................. 46

9.4.6 Disclosure Pursuant to Judicial or Administrative Process ............ 46



9.4.7 Other Information Disclosure Circumstances ................................ 46

9.5 Intellectual Property Rights ................................................................... 46

9.6 Representations and Warranties .......................................................... 47

9.6.1 CA Representations and Warranties ............................................. 47

9.6.2 RA Representations and Warranties ............................................. 47

9.6.3 Subscriber Representations and Warranties ................................. 47

9.6.4 Relying Parties Representations and Warranties .......................... 47

9.6.5 Representations and Warranties of Affiliated Organizations ......... 47

9.6.6 Representations and Warranties of Other Participants.................. 48

9.7 Disclaimers of Warranties ..................................................................... 48

9.8 Limitations of Liability ........................................................................... 48

9.9 Indemnities ........................................................................................... 48

9.10 Term and Termination .......................................................................... 48

9.10.1 Term .............................................................................................. 48

9.10.2 Termination ................................................................................... 48

9.10.3 Effect of Termination and Survival ................................................. 49

9.11 Individual Notices and Communications with Participants .................... 49

9.12 Amendments ........................................................................................ 49

9.12.1 Procedure for Amendment ............................................................ 49

9.12.2 Notification Mechanism and Period ............................................... 49

9.12.3 Circumstances under Which OID Must be changed ...................... 49

9.13 Dispute Resolution Provisions .............................................................. 49

9.14 Governing Law ..................................................................................... 49

9.15 Compliance with Applicable Law .......................................................... 49

9.16 Miscellaneous Provisions ..................................................................... 50

9.16.1 Entire Agreement........................................................................... 50

9.16.2 Assignment .................................................................................... 50

9.16.3 Severability .................................................................................... 50

9.16.4 Enforcement (Attorneys’ Fees and Waiver of Rights) .................... 50

9.16.5 Force Majeure ............................................................................... 50

9.17 Other Provisions ................................................................................... 50



Modification Log

Date Author Version Reason

5 Feb 2014 Jayson 0.01 Initial Draft

17 Feb 2014 Jessica 0.02 Reviewed

5 Mar 2014 Jayson 1.00 Final

22 July 2014 Jayson 1.01 Updated to sync with CP numbering

17 Aug 2014 Jessica 1.02 Updates on 3.2.2

07 Aug 2017 Bhuvanesh 1.03 Updated CP Version reference and OID Map

15 May 2019 Babu Raj K.R 1.04 Updated policy in align to DT CP v1.4.



1 Introduction

1.1 Overview

This document is the HCDirect Direct Certification Practice Statement (CPS) and is issued by Health Companion, Inc. Health Companion, Inc. operates HCDirect HISP, HCDirect RA and HCDirect CA services as defined by the Direct Project. The Direct Project enables participants to send authenticated health information directly to trusted recipients using secure messaging.

1.1.1 Certificate Policy (CP)

This CPS is based on the DirectTrust Community Certificate Policy v1.4 (CP) and provides policies regarding identity validation requirements and digital certificate lifecycle management in HCDirect services (RA, CA and HISP).

This document follows the structure IETF Internet X.509 public key infrastructure (PKI) certificate policy and certification practices framework (RFC 3647).

1.1.2 Relationship between this DirectTrust CP and a Corresponding CPS

This CPS conforms to DirectTrust Community Certificate Policy v1.4.

1.1.3 Relationship between this DirectTrust CP and the CA CP

HCDirect CA conforms to DirectTrust CP and this CPS.

1.1.4 Relationship between DirectTrust CP and EHNAC-DirectTrust Accredited Entities

Compliance to an Active CP Version is a requirement for accreditation under the DirectTrust -EHNAC Accreditation as described in CP Section 1.5.3, and entities accredited under this program have been audited regarding implementation of practices in compliance with an Active CP Version in conjunction with proper use of the DirectTrust policy OIDs. DirectTrust publishes bundles of trust anchors for the purpose of assisting Relying Parties in verifying the accredited status of Custodians, CAs, and RAs, available at https://www.directrust.org.

1.2 Document Name and Identification

This CPS defines multiple levels of assurance each assigned a unique object identifier (OID). The policy OIDs map to the DirectTrust policy as follows,

id-DirectTrust. arc 1.3.6.1.4.1.41179

id-DirectTrust-policies id-DirectTrust.(0) 1.3.6.1.4.1.41179.0

DirectTrust-CP 1.4 id-DirectTrust-policies.(1.4) 1.3.6.1.4.1.41179.0.1.4

id-DirectTrust-LoAs id-DirectTrust.(1) 1.3.6.1.4.1.41179.1



DirectTrust LoA 1 id-DirectTrust-LoAs.(1) 1.3.6.1.4.1.41179.1.1



id-DirectTrust-Cat id-DirectTrust.(2) 1.3.6.1.4.1.41179.2

DirectTrust CE id-DirectTrust-Cat.(1) 1.3.6.1.4.1.41179.2.1

DirectTrust BA id-DirectTrust-Cat.(2) 1.3.6.1.4.1.41179.2.2

Certificates issued by this CA asserts level of assurance by listing the appropriate OIDs in the certificatePolicies X.509v3 standard extension.

1.3 Public Key Infrastructure (PKI) Participants

The following roles are relevant to the administration/operation of this PKI.

1.3.1 Certification Authorities

A Certification Authority (CA) is an entity that issues Public KeyX.509 Certificates and, through such issuance, attests to the binding between an identity and cryptographic Key Pair to a Subscriber.For ease of reference herein, all CAs issuing Certificates in conformance with this CP are hereafter referred to as "Issuer CAs".CAs accredited through EHNAC for DirectTrust issuance operate under a Certification Practices Statement (CPS) that is reviewed as part of the accreditation process to ensure conformance to the policies of this CP.

HCDirect has a two tier PKI hierarchy, HCDirect Root CA and HCDirect Subscriber CA. HCDirect Root CA issues a CA signing certificate to the HCDirect Subscriber CA.

HCDirect Subscriber CA signs certificate signing requests and issues X.509 public direct certificates to organizational or individual subscribers.

1.3.2 Registration Authority (RA)

Registration Authority (RA) collects and verifies identity information from subscribers as required by the identity validation policies defined in this CPS. HCDirect RA is the primary RA for HCDirect Subscriber CA. However HCDirect may delegate the RA responsibility to other qualified organizations.

1.3.3 Subscribers

An HCDirect subscriber is an entity who uses direct messaging services. As subscriber, as used herein, refers to both the subject of the certificate and the entity that contracted with HCDirect Subscriber CA for the certificate’s issuance in accordance with this CPS.



1.3.3.1 Custodian

HCDirect may act as a custodian of the Subscriber for the purpose of enabling health information exchange by holding and managing Private Keys associated with a Certificate on behalf of that Subscriber in a Custodial Subscriber Key Store.

1.3.3.2 Health Information Service Providers(HISPs)

HCDirect operates HISP services and processes direct messages to and from direct addresses. Acting as an agent for subscribers, HCDirect HISP may hold and manage private keys associated with a digital certificate issued to a subscriber.

Practice Note: Custodians (including HISPs) may be subject to additional requirements regarding management of Private Keys for DirectTrust accreditation and/or acceptance into DirectTrust trust anchor bundles.

1.3.4 Relying Parties

A relying party uses the 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. It is up to the relying party to decide whether or how to check the validity of the subscriber certificate by checking appropriate certificate status information (CRL).

1.3.5 Other Participants

No stipulation.

1.4 Certificate Usage

1.4.1 Appropriate Certificate Uses

The primary use for the certificate in in the exchange of electronic messages as grounded in the specification for the Direct Project. Please refer to DirectTrust CP v1.4 for more details.

1.4.2 Prohibited Certificate Uses

Certificates do not guarantee that the Subject is trustworthy, honest, reputable in its business dealings, compliant with any laws, or safe to do business with. A certificate only establishes that the information in the certificate was verified as reasonably correct to a known level of assurance when the certificate was issued. Certificates issued under this policy may not be used where prohibited by law.



1.5 Policy Administration

1.5.1 Organization Administering the Document

HCDirect Policy Group (HPG) is responsible for administering this CPS document. This group includes members of HCDirect Security Team (HST) and management representatives. HPG may amend this CPS, or any part thereof, at any time, at its discretion.

1.5.2 Contact Person

Questions regarding this certificate policy should be directed to,

George Samuel

Chief Security Officer

Health Companion, Inc.

20770 Highway 281 North,

Suite 108, PMB 206

San Antonio, TX 78258.

866.944.8196

[email protected]

1.5.3 Person Determining CPS Suitability for Policy

Please refer to 1.5.2.

1.5.4 CPS Approval Procedures

HCDirect CA submits this CPS to a compliance analysis and audit against the DirectTrust CP as described in section 8. This CPS is required to meet all facets of the policy. Conformance of this CPS to DirectTrust CP is only declared after compliance analysis/audit and all discrepancies are resolved.

All changes to this CPS is subject to the approval of HCDirect Policy Group (HPG).

1.6 Definitions and Acronyms

1.6.1 Acronyms

Acronym Meaning

CA Certification Authority

CP Certificate Policy

CPS Certification Practice Statement

CRL Certificate Revocation List

mailto:[email protected]



CSO Chief Security Officer

EIN Employer Identification Number

DN Distinguished Name

DTAAP Direct Trusted Agent Accreditation Program

DTPA Direct Trust Policy Authority

HPG HCDirect Policy Group

HST HCDirect Security Team

ID Identity

IETF Internet Engineering Task Force

NPI National Provider Identifier

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 Request for Comments

S/MIME Secure Multipurpose Internet Mail Extensions

1.6.2 Definitions

Term Definition

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

An authority trusted by one or more users to create and assign certificates. Also known as a Certificate Authority.

Certificate Policy

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.

Certificate A statement of the practices that a CA employs in issuing,



Practice Statement

suspending, revoking and renewing certificates and providing access to them, in accordance with specific requirements typically provided in a certificate policy.

Certificate Revocation List

A list maintained by a Certification Authority of the certificates which it has issued that are revoked prior to their stated expiration date.

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

Chief Security Officer

An individual responsible for establishing and maintaining the enterprise vision, strategy and program as it relates to Information Systems Security, to ensure information assets are adequately protected.

Private Key (1) The key of a signature key pair used to create a digital signature. (2) The key of an encryption key pair that is used to decrypt confidential information. In both cases, this key must be kept secret.

Public Key (1) The key of a signature key pair used to validate a digital signature. (2) The key of an encryption key pair that is used to encrypt confidential information. In both cases, this key is made publicly available normally in the form of a digital certificate.

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.

Registration Authority

Entity responsible for identification and authentication of certificate subjects.

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

Subscriber A Subscriber is an entity that does not itself issue certificates to another party and is either (1) the subject named or identified in a certificate issued to that entity, or (2) holds, directly or through its designated HISP (or other authorized third party), a private key that corresponds to the public key listed in the certificate.



2 Publication and Repository Responsibilities

2.1 Repositories

HCDirect operate certificate repositories. Private Key repositories are secured and are only for internal use. Public key/certificates are published as per direct specification and are available via DNS.

HCDirect trust anchor certificate and revocation data for issued certificates (CRL) are available through a public repository.

2.1.1 Repository Obligations

The repositories shall operate 24 hours a day, 7 days a week, with a minimum of 99% availability overall per year (excluding network outages), and scheduled down‐time not to exceed 0.5% annually.

2.2 Publication of Certification Information

2.2.1 Publication of Certificates and Certificate Status

Every certificate issued by HCDirect Subscriber CA contains URIs specifying the location of its issuing CA’s current CRL and also the location of HCDirect Subscriber CA certificate. Similarly the HCDirect Subscriber CA certificate (trust anchor) contains the HCDirect Root CA CRL and also the location of HCDirect Root CA certificate.

2.2.2 Publication of CA Information

HCDirect CPS document, CA certificates and CRL files are publicly accessible at http://www.hcdirect.healthcompanion.com/cps/ .

2.2.3 Interoperability

No stipulation.

2.3 Frequency of Publication

This CPS is updated and published in accordance with section 10.12. Subscriber certificates are published to DNS on the same day of issuance.

2.4 Access Control on Repositories

Read only access is provided to CPS document, CA certificates and CRL files. However private keys and other internal information is strongly protected using industry best practices.

http://www.hcdirect.healthcompanion.com/cps/



3 Identification and Authentication

3.1 Naming

3.1.1 Types of Names

All certificates shall use non-null DN name forms for the issuer and subject names. Certificates tied to full direct addresses shall contain the direct address in the subjectAltName extended attribute as an rfc822Name. Certificates tied to a direct domain shall contain the domain name in the subjectAltName extension formatted as a dNSName and the CN of the subject DN.

DN attributes in the HCDirect Subscriber CA is given below,

Attribute Value

Country (C) = US

Organization (O) = Health Companion

Organizational Unit (OU) = HCDirect

State or Province (S) = California

Locality (L) = Rancho Santa Fe

Common Name (CN) = HCDirect Subscriber CA

DN attributes in the user certificates issued by HCDirect Subscriber CA is given below,

Attribute Value

Country (C) = US

Organization (O) = Subscriber Organization Name

Organizational Unit (OU) = Not Used

State or Province (S) = Subscriber Organization State

Locality (L) = Subscriber Organization Locality

Common Name (CN) = Name of the domain or name of the user

3.1.2 Need for Names to be Meaningful

Names used in certificates uniquely identify the organization or person to which they are assigned and are easily understood by humans.

3.1.3 Anonymity of Pseudonymity of Subscribers

This CA does not issue anonymous certificates. Pseudonymous certificates may be issued as long as namespace uniqueness requirements are met.



3.1.4 Rules for Interpreting Various Name Forms

No stipulation.

3.1.5 Uniqueness of Names

This CA enforces name uniqueness of the certificate subject DN with the CA’s X.500 namespace.

3.1.6 Recognition, Authentication, and Role of Trademarks

Subscribers may not request certificates with any content that infringes the intellectual property rights of another entity. HCDirect Subscriber CA may reject any application or require revocation of any certificate that is part of a trademark dispute.

3.2 Initial Identity Validation

3.2.1 Method to Prove Possession of Private Key

Currently HCDirect generates private key for the subscribers and hence no proof of key possession is required.

3.2.2 Authentication of Organization Identity

Requests for Certificates that assert an organization name in the subject field or Subject Alternative Name extension of the certificate MUST include the organization name, mailing address, and documentation of the legal existence of the organization. For Address-Bound and Domain-Bound Certificates, the requested Health Domain Name or Health Endpoint Name that will appear in the Certificate MUST also be included (see section 3.1.1 for details).

The requesting organization MUST represent in a signed statement such as a Certificate application their healthcare category as defined by HIPAA at 45 CFR 160.103. Any organization not providing attestation to one of the above categories is considered a non-declared entity.

The Subscriber SHALL be listed in the Organization (O) field of the subjectDistinguishedName and MUST be a legally distinct entity with the right to use the Health Domain Name asserted in the Domain-Bound Certificate or the Health Endpoint Name asserted in the Address-Bound Certificate. The requesting organization MUST have the legal authority to originate Direct messages and/or be the final destination for Direct messages using the requested Certificate.

For all Certificates asserting affiliation, HC Subscriber CA or HC Direct RA will verify the Applicant organization and the organization’s healthcare category in accordance with the following minimum requirements. The corresponding healthcare category OID will be asserted in all affiliated Certificates.



Healthcare Category Minimum Verification Requirements

DT.org CE Applicant represents in a statement such as a signed Certificate application that it is a Covered Entity (CE) as defined by HIPAA at 45 CFR 160.103.

The HCDirect RA shall verify the application includes the signed statement, the organization information submitted, the identity of the representative in accordance with section 3.2.3.1 and the representative’s authorization to act in the name of the organization.

DT.org BA Applicant represents in a statement such as a signed Certificate application that it is a Business Associate (BA) as defined by as defined by HIPAA at 45 CFR 160.103.

HCDirect RA shall verify the application includes the signed statement, the organization information submitted, the identity of the representative in accordance with section 3.2.3.1 and the representative’s authorization to act in the name of the organization.

If a Certificate asserts an organizational affiliation, HC Direct RA SHALL obtain documentation from the organization that authorizes the affiliation and an agreement which obligates the organization to:

Request modification or revocation of the Certificate if information in the Certificate subject is no longer accurate, and

Request revocation of unexpired Certificates if organizational affiliation ends.

3.2.3 Authentication of Individual Identity

3.2.3.1 Authentication of Human Subscribers

Validation of an individual identity is required for the following purposes,

Subscriber (when an Address Certificate is bound to an address corresponding to an individual;)

Organizational representative(to identity proof the representative of an organization requesting a Domain-Bound Certificate or an Address Certificate with an organizational affiliation;)

DirectTrust identity proofing LoAs are intended to provide equivalent assurances to identity proofing LoAs as defined by NIST SP 800-63-2. At a minimum,



HCDirect Subscriber CA or RA SHALL proof an individual’s identity in accordance with one of the following LoAs:

DT.org LoA 1 The name associated with the Subscriber is provided by the Applicant and accepted without verification.

The HCDirect RA verifies Applicant’s control over an email address (or any of the identity proofing methods listed for a higher level).

DT.org LoA 2 Applicant supplies his or her full legal name, an address of record, and date of birth.

In-Person Vetting

For in-person vetting, the Applicant also provides valid government issued photoID.

The HCDirect RA inspects the photo-ID; compares picture to Applicant; and records the ID number, address and date of birth (DoB)

The HCDirect CA issues credentials in a manner that confirms the ability of the Applicant to receive telephone communications or text message at phone number or e-mail address associated with the Applicant in records – or – confirms the ability of the Applicant to receive mail at the claimed address– or – sends notice to the confirmed physical address associated with the Applicant in the records after issuance.

Remote Vetting

For remote vetting, the Applicant provides a valid government issued ID identifier and a utility or financial account identifier, along with appropriate metadata sufficient to identify and verify the respective ID or account.

The HCDirect RA inspects both ID and



account numbers supplied (e.g. for correct number of digits) and verifies either the ID number OR the account number information provided through record checks either with the applicable agency or institution or through credit bureaus or similar databases, and confirms that: name, DoB, address and other personal information in records are on balance consistent with the application and sufficient to identify a unique individual. (For utility or financial account numbers, confirmation MAY be performed by verifying knowledge of recent account activity).

The HCDirect CA issues credentials in a manner that confirms the ability of the Applicant to receive telephone communications or text message at phone number or email address associated with the Applicant in records – or – confirms the ability of the Applicant to receive mail at a physical address associated with the Applicant in the records – or – sends notice to an address confirmed in the records check after issuance.

Any of the identity proofing methods listed for a higher level are also acceptable.

DT.org LoA 3 Applicant supplies his or her full legal name, an address of record, and date of birth.

In-Person Vetting

For in-person vetting, the Applicant also provides a valid government issued photoID.

The HCDirect RA inspects the photo-ID and records the ID number; compares picture to Applicant; and verifies information provided through record checks either with the applicable



agency or institution or through credit bureaus or similar databases, and confirms that: name, DoB, address and other personal information in records are consistent with the application.

The HCDirect CA issues credentials in a manner that confirms the ability of the Applicant to receive telephone communications at phone number associated with the Applicant in records – or – confirms the ability of the Applicant to receive mail at the claimed address– or – sends notice to the confirmed physical address associated with the Applicant in the records after issuance.

If the telephone method is used, HCDirect CA also records Applicant’s voice or uses alternative means that establish an equivalent level of non-repudiation.

Remote Vetting

For remote vetting, the Applicant provides a valid government issued ID identifier and a utility or financial account identifier, along with appropriate metadata sufficient to identify and verify the respective ID or account.

The HCDirect RA verifies both ID AND account numbers provided through record checks either with the applicable agency or institution or through credit bureaus or similar databases, and confirms that: name, DoB, address and other personal information in records are consistent with the application. (For utility or financial account numbers, confirmation MAY be performed by verifying knowledge of recent account activity).

The HCDirect CA issues credentials in a manner that confirms the ability of the Applicant to receive telephone



communications or text message at phone number or email address associated with the Applicant in records – or – confirms the ability of the Applicant to receive mail at a physical address associated with the Applicant in the records.

Any of the identity proofing methods listed for a higher level are also acceptable.

All subscriber information collected as part of the issuance process is validated during the identity proofing process. There is no information collected by HCDirect that would not be validated.

In-Person vetting for LoA 2 and LoA 3 MAY be performed by the RA, Trusted Agent of the RA, or an entity certified by a State or Federal Entity as being authorized to confirm identities. A trust relationship between the Trusted Agent and the Applicant which is based on an in-person antecedent MAY suffice as meeting the In-Person identity vetting requirements for LoA 2 and LoA 3.

3.2.3.2 Authentication of Human Subscribers for Role-based Certificates

No stipulation.

3.2.3.3 Authentication of Human Subscribers for Group Certificates

For Custodian managed group certificates, HCDirect RA shall also record the information identified in Section 3.2.3.1 for the Information Systems Security Officer (or equivalent) of the HISP, before issuing the certificate. In addition to the authentication of the Subscriber (and their organization when required), the following procedures shall also be performed:

The Custodian (e.g. HISP) Information Systems Security Officer(ISSO) or equivalent shall be responsible for ensuring control of the private key, including maintaining a list of any Subscribers who have access to use of the private key, and accounting for which Subscriber had control of the key at what time. Currently HCDirect HISP manages private keys on behalf of subscribers.

The subjectName DN must not imply that the subject is a single individual and hence contains "HISP Managed".

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



Users MUST be identity proofed at a level corresponding to the LOA asserted in the Certificate, however HISP managed group certificates are currently not available to individual users. Therefore HCDirect doesn’t identity proof human subscribers for Group Certificates.

3.2.3.4 Authentication of Devices

No stipulation.

3.2.3.5 Verification of NPI Number

HCDirect does not include NPI Number in the certificate.

3.2.4 Non-verified Subscriber Information

If needed, HCDirect will only add verified Subscriber information in the certificate.

3.2.5 Validation of Authority

RA must verify that a representative of an organization is authorized to act on behalf of and as an agent of the organization. In the case of use of custom domains for direct addresses, applicant may need to demonstrate control of this domain using a method we specify.

3.2.6 Criteria for Interoperation

HCDirect CA shall issue certificates according to DirectTrust certificate policy.

3.3 Identification and Authentication for Re-key Requests

3.3.1 Identification and Authentication for Routine Re-key

The identity of an organization and/or individual requesting a re-key of a certificate must be established through the initial identity verification process or through proof of possession of the private key via a digital signature.

3.3.2 Identification and Authentication for Re-key after Revocation

If a certificate is revoked, the Subscriber shall go through the initial identity verification process described in section 3.2 to obtain a new certificate.

3.4 Identification and Authentication for Revocation Request

Revocation requests must be authenticated. Requests to revoke a certificate may be authenticated using that certificate's public key, regardless of whether or not the associated private key has been compromised.



4 Certificate Lifecycle Operational Requirements

4.1 Application

4.1.1 Submission of Certificate Application

The RA creates the official certificate signing request(CSR) based on the input received from the subscriber application during the identity validation process.

4.1.2 Enrollment Process and Responsibilities

As part of the identity validation steps, the applicant is responsible for providing accurate information and the RA is responsible for verifying, approving and archiving subscriber application and documentation of the application validation.

4.2 Certificate Application Processing

4.2.1 Performing Identification and Authentication Functions

The identity verification of applicants will be performed by HCDirect RA as specified in section 4.2. During identity verification, applicant is responsible for submitting any supplementary documentation required by our RA. RA may reject or approve an application.

If a new-certificate-request is rejecting, they need to resubmit the request after fixing whatever things are noted in the audit notes and RA should create a new request for the same. If the renew/reissue/revoke request is rejecting, re-request the corresponding operation through the RA after fixing the things which are pointed at the RA audit notes.

Once the verification is approved by RA, it would be submitted to HCDirect Subscriber CA.

4.2.2 Approval or Rejection of Certification Applications

A certificate application may be rejected by HCDirect CA due to missing or inaccurate information or due to other reasons.

If a new-certificate-request is rejecting, they need to resubmit the request after fixing whatever things are noted in the CA audit notes and RA should create a new request for the same. If the renew/reissue/revoke request is rejecting, re-request the corresponding operation through the RA after fixing the things which are pointed at the CA audit notes.

Once an application is approved, the subscriber must accept the subscriber agreement and pay any required certificate fee.

4.2.3 Time to Process Certificate Applications

All certificates must be issued within 30 days of the RA approval.



4.3 Issuance

4.3.1 CA Actions during Certificate Issuance

Applications received from RA are verified by authorized CA administrators. After verification, authorized CA administrators will issue the subscriber certificate.

4.3.2 Notification to Subscriber of Certificate Issuance

The subscriber will be notified via email that his/her certificate has been issued.

4.4 Certificate Acceptance

4.4.1 Conduct Constituting Certificate Acceptance

Certificate is considered to be accepted after the first use of it by a subscriber directly or through an application.

4.4.2 Publication of the Certificate by the CA

HCDirect CA may send the issued subscriber certificates to HCDirect HISP for deployment.

4.4.3 Notification of Certificate Issuance by the CA to Other Entities

No stipulation.

4.5 Key Pair and Certificate Usage

4.5.1 Subscriber Private Key and Certificate Usage

HCDirect manages private keys on behalf of its subscribers.

4.5.2 Relying Party Public Key and Certificate Usage

Relying parties should understand HCDirect CP/CPS policies. Relying parties also should process the HCDirect CRL and reject certificates found on it.

4.6 Certificate Renewal

Certificate renewal consists of issuing a new certificate with new validity period and serial number while retaining other information in the original certificate including public key. After renewal, the old certificate may still be valid, but it cannot be further re-keyed, renewed or modified.

4.6.1 Circumstance for Certificate Renewal

A certificate may be renewed if the public key is still valid, the associated private key is not compromised, subscriber name and other details are unchanged, and the original certificate is not previously renewed, re-keyed, or modified.



4.6.2 Who May Request Renewal

Renewal may requested by the subscriber or HCDirect RA. HCDirect CA may request renewal in the case of CA certificate re-key.

4.6.3 Processing Certificate Renewal Requests

HCDirect CA shall approve or reject certificate renewal requests. Identity verification of the subscriber shall be equivalent to the initial identify verification process.

4.6.4 Renewal Requests Additional Policies

No stipulation.

4.6.5 Conduct Constituting Acceptance of a Renewal Certificate

The passage of time after delivery or notice of issuance of the certificate to the Subscriber, or actual use of the certificate, constitutes the Subscriber’s acceptance of it.

4.6.6 Publication of the Renewal Certificate by the CA

Please refer to section 2.2.1.


No stipulation.

4.7 Certificate Re-Key

Certificate re-keying consists of creating a new certificate with a new key-pair. However the certificate attributes specific to the identity of the participant will not be changed.

4.7.1 Circumstance for Certificate Re-Key

A certificate is re-keyed before end of its validity period and when no other information besides keys and validity period are changing. Revoked certificates cannot be re-keyed.

4.7.2 Who May Request Certification of a New Public Key

Re-keying may be requested by subscriber, RA or CA.

4.7.3 Processing Certificate Re-Key Requests

HCDirect CA shall approve or reject subscriber certificate re-keying requests. Identity verification of the subscriber is equivalent to the initial identity verification.

4.7.4 Notification of New Certificate Issuance to Subscriber

See section 4.3.2.



4.7.5 Conduct Constituting Acceptance of a Re-Keyed Certificate

See section 4.4.1.

4.7.6 Publication of the Re-keyed Certificate by the CA

See section 4.4.2.


See section 4.4.3.

4.8 Modification

HCDirect CA does not support certificate modification.

4.8.1 Circumstance for Certificate Modification

No stipulation.

4.8.2 Who May Request Certificate Modification

No stipulation.

4.8.3 Processing Certificate Modification Requests

No stipulation.

4.8.4 Notification of New Certificate Issuance to Subscriber

No stipulation.

4.8.5 Conduct Constituting Acceptance of Modified Certificate

No stipulation.

4.8.6 Publication of the Modified Certificate by the CA

No stipulation.


No stipulation.

4.9 Certificate Revocation and Suspension

HCDirect does not support certificate suspension. Certificate revocation procedures are given below.

4.9.1 Circumstances for Revocation

HCDirect Subscriber CA shall revoke a certificate and publish the status in CRL for any reason, including but not limited to,

The identifying information or affiliation components of any names in the certificate become invalid



If it turns out that the information provided by the subscriber during the application for certificate is false or misleading

If there is reasonable suspicion that the private key is compromised

If there is a request from subscriber to revoke his/her certificate

The subscriber violates terms of use of the direct services

Termination or expiration of the subscriber agreement

4.9.2 Who Can Request Revocation

Certificate revocation can be initiated by an authorized representative of the subscriber, authorized representative of RA (when RA has performed initial identity validation or an authorized representative of CA.

4.9.3 Procedure for Revocation Request

Revocation requests shall be initially validated by RA (when RA has performed initial identity validation) and shall be reviewed and approved by CA. Approved revocation requests will be posted to the repository.

4.9.4 Revocation Request Grace Period

There is no specific grace period mandated by this CPS. However all participants are expected to request the revocation as soon as possible when a need for revocation comes to their attention.

4.9.5 Time within Which CA Must Process the Revocation Request

Revocation requests received by CA must be processed within 8 hours of receipt.

4.9.6 Revocation Checking Requirements for Relying Parties

It is up to the relying parties to decide the revocation checking requirements.

4.9.7 CRL Issuance Frequency

HCDirect must issue and post CRL to the repository every 30 days. However it must be immediately updated in the repository whenever a new entry is added to CRL.

4.9.8 Maximum Latency of CRLs

Revised CRL will be available on the public repository within 4 hours of generation.

4.9.9 On-Line Revocation/Status Checking Availability

Right now HCDirect does not support OCSP responding.



4.9.10 On-Line Revocation Checking Requirements

No stipulation.

4.9.11 Other Forms of Revocation Advertisements Available

No stipulation.

4.9.12 Special Requirements Related to Key Compromise

No stipulation.

4.9.13 Circumstances for Suspension

HCDirect does not support suspension of certificates.

4.9.14 Who Can Requests Suspension

No Stipulation.

4.9.15 Procedure for Suspension Request

No Stipulation.

4.9.16 Limits on Suspension Period

No Stipulation.

4.10 Certificate Status Services

4.10.1 Operational Characteristics

The status of public certificates is available via CRL list. The location of CRL is published in each certificate under x.509v3 extensions.

4.10.2 Service Availability

HCDirect certificate status services are hosted on highly available servers.

4.10.3 Optional Features

No stipulation.

4.11 End of Subscription

HCDirect will revoke any unexpired certificate of a subscriber upon termination or expiration of their subscriber agreement. Certificates that expired during the term of a subscriber agreement will not be revoked.

4.12 Key Escrow and Recovery

HCDirect Subscriber CA does not offer key escrow for private keys.



4.12.1 Key Escrow and Recovery Policy and Practices

No stipulation.

4.12.2 Session Key Encapsulation and Recovery Policy and Practices

No stipulation.

5 Facility, Management and Operational Controls

The following sections specify the non-technical security controls, including physical, procedural and personnel controls used by HCDirect and the hosting datacenter as part of CA operations.

5.1 Physical Controls

5.1.1 Site Location and Construction

HCDirect uses SSAE-16 Type II certified datacenter facilities to ensure adequate security to CA operations.

5.1.2 Physical Access

HCDirect uses HIPAA compliant managed hosting solutions for operating CA services. This facility is located in a no fly zone and has round the clock security presence. Entry requires presentation of a valid ID card. Inside the data center there is another physical security and the datacenter is under continuous video surveillance. All doors inside require 2 forms of authentication (proximity cards and biometric fingerprint readers). All access is logged for auditing purposes.

5.1.3 Power and Air Conditioning

Our data centers have 2 power feeds from 2 separate power grids. 2 redundant UPS systems are in place and power conditioning with bus synchronization is also available. There are multiple generators available with automatic transfer switch.

There are multiple air-conditioning units and temperature is controlled and monitored. Humidity is also controlled and monitored.

5.1.4 Water Exposures

Our data centers have under the floor water detection systems installed.

5.1.5 Fire Prevention and Protection

Our data centers have fireproof, anti-static raised floors and state-of-the-art Cheetah fire suppression systems are in place.

5.1.6 Media Storage

A backup copy of audit, archive and system backup is securely stored at an alternate location.



5.1.7 Waste Disposal

All paper documents that are no longer needed is periodically identified and destroyed.

5.2 Procedural Controls

5.2.1 Trusted Roles

The following four trusted CA roles are defined for HCDirect: Administrator, Officer, Auditor and Operator. Some of the roles may be combined. No one individual will assume both the Officer and Administrator roles.

5.2.1.1 Administrator

An Administrator is authorized to install, configure and maintain HCDirect systems including management of user accounts, configuration of auditing and creation/backup of CA certificates. Administrators do not issue certificates to subscribers.

5.2.1.2 Officer

The CA officer role is responsible for request, approval, issuance, re-keying, revocation and renewal of certificates.

5.2.1.3 Auditor

The auditor is responsible for the review, maintenance and archival of audit logs. Auditor also oversee internal audits to ensure that HCDirect is operating compliant to this CP/CPS.

5.2.1.4 Operator

The operator is responsible for the regular operations of HCDirect including backup and recovery. Operator and Administrator roles may be handled by a single individual.

5.2.2 Number of Persons Required Per Task

Two persons will be trained for each task, however only one is required to execute each task.

5.2.3 Identification and Authentication for Each Role

All users acting in a trusted role must authenticate to HCDirect before performing any actions available for that roles. Access to HCDirect RA and CA portals will have additional access controls and will be available only over an SSL connection.

5.2.4 Roles Requiring Separation of Duties

An individual will not be designated to both Officer and Administrator roles at the same time.



5.3 Personnel Controls

5.3.1 Qualifications, Experience and Clearance Requirements

All trusted roles are held by persons who are legally eligible to work in the United States. We will select persons for trusted roles on the basis of loyalty, trustworthiness and integrity.

5.3.2 Background Check Procedures

We may perform background checks on all personnel selected for trusted roles.

5.3.3 Training Requirements

All persons acting in a trusted role, will receive comprehensive training on the policies, procedures and applications of HCDirect. They will also have a good understanding of the PKI principles and operations.

5.3.4 Retraining Frequency and Requirements

Individuals responsible for Trusted Roles shall be aware of changes in CA operation. Any significant change to the operations shall have a training (awareness) plan, and the execution of such plan shall be documented. Documentation shall be maintained identifying all personnel who received training and the level of training completed.

5.3.5 Job Rotation Frequency and Sequence

No stipulation.

5.3.6 Sanctions for Unauthorized Actions

HCDirect management will take appropriate administrative and disciplinary actions against personnel who violate provisions of this CPS. Employees under HCDirect will also be bound by Health Companion, Inc’s sanction policy.

5.3.7 Independent Contractor Requirements

Independent contractor personnel employed to perform trusted roles will meet the personnel requirements set forth in previous sections.

5.3.8 Documentation Supplied to Personnel

HCDirect CA will provide essential documentation (CPS, user manual for RA/CA portals etc.) necessary to perform trusted roles to personnel filling that role.

5.4 Audit Logging Procedures

HCDirect will generate audit logs for all events related to the security of the CA operations. HCDirect CA systems are configured to automatically collect and store audit data. In cases where automated audit logs are not feasible, events



are recorded in a log book. All audit data will be made available during compliance audits.

5.4.1 Types of Events Recorded

Each audited event record will include date/time of event, type of event, success/failure (where relevant) and the identity of the user/entity that caused the event. The following events are audited,

System Security

o Changes to audit parameters or attempt to delete or modify logs

o Successful and unsuccessful attempt to login to CA systems

o Any change to security parameters

o User/role changes in security

o The user account locked out due to maximum invalid attempts

o When a user account unlocked by an administrator

o Attempts to set or modify passwords

Certificate Management

o Key generation

o Private key access

o Certificate issuance, re-key, renewal and revocation

o Changes to certificate profile, revocation profile and CRL profile

Configuration Changes

o Any changes to hardware, software, operating system and application upgrades/patches

Site Security

o Known or suspected violations of physical security

System Errors

o Software error conditions

o System crashes or hardware failures

o Intrusion attempts

Miscellaneous

o Installation, backup or modification of cryptographic modules or OS

o Installation, backup or restoration of CA systems

o Any data export/import

o Violations of this CP/CPS



o Resetting operating system clock

5.4.2 Frequency of Processing Log

Audit logs are reviewed by an auditor whenever there is a need. Any discrepancies identified are investigated and handled properly.

5.4.3 Retention Period for Audit Log

Security audit log data will be retained on the CA systems for a minimum of 2 months. After this period, it will be moved to archives.

5.4.4 Protection of Audit Log

Only authorized personnel (trusted roles) have access to audit logs and only CA administrator/Auditors can archive audit logs. CA administrator may delete audit log after the archival of audit data.

5.4.5 Audit Log Backup Procedures

Audit logs are backed up monthly on a separate and safe location.

5.4.6 Audit Collection System

All automated audit processes will be operational when CA system is up and running. If a failure in automated audit is detected, CA operations should be stopped except revocation process.

5.4.7 Notification to Event-Causing Subject

No stipulation.

5.4.8 Vulnerability Assessments

Vulnerability scan will be conducted on CA systems and any findings will be addressed within 30 days. The frequency of the scans will be decided by HCDirect.

5.5 Records Archival

5.5.1 Types of Records Archived

The following records will be archived,

Submitted certificate applications

Documentation supporting certificate applications

Audit logs

Subscriber agreements

All types of certificate requests

CPS documents



5.5.2 Retention Period for Archive

CA archives are retained for a minimum of seven years and 6 months.

5.5.3 Protection of Archive

Only authorized individuals are permitted to access archived data. Archived data will be stored in a separate storage facility.

5.5.4 Archive Backup Procedures

No stipulation.

5.5.5 Requirements for Time-stamping of Records

CA system time is synchronized using NTP with a trusted time service. All CA archive records from CA systems are automatically time-stamped as they are created. Other archive records such as documents may be manually date-stamped.

5.5.6 Archive Collection System (Internal vs. External)

No stipulation.

5.5.7 Procedures to Obtain & Verify Archive Information

No stipulation.

5.6 Key Changeover

HCDirect will not issue subscriber certificates with an expiration date after the expiration date of the subscriber CA certificate. Similarly subscriber CA certificates with an expiration date after the expiration date of the root CA certificate won’t be issued.

To minimize risk to the PKI through compromise of a CA’s key, the private signing key will be changed more frequently than the CA certificate renewal period.

5.7 Compromise and Disaster Recovery

5.7.1 Incident and Compromise Handling Procedures

If a hacking or any other potential compromise of CA becomes known, it will be promptly investigated to assess the damage sustained. Based on the damage assessment, CA certificate may be rebuilt, all or a select set of certificates may be revoked, and/or the CA private key may be declared as compromised.

5.7.2 Computing Resources, Software, and/or Data Are Corrupted

HCDirect maintains regular backup of CA system including cryptographic modules, databases, software systems and private keys to rebuild the CA



capability in the case of hardware failure or corruption of software/data. An offsite backup is also kept for disaster recovery.

5.7.3 Entity Private Key Compromise Procedures

If a CA key is compromised, all relying parties would be notified for removal of CA certificate. HCDirect would also issue a new CA certificate.

5.7.4 Business Continuity Capabilities after a Disaster

In the case of a disaster in which the CA systems rendered inoperable, HCDirect will reestablish CA operations as quickly as possible at another suitable location in accordance with HCDirect disaster recovery plan using a secure backup.

5.8 CA or RA Termination

In the event of termination of CA, all unexpired and unrevoked certificates signed by CA will be revoked.

6 Technical Security Controls

6.1 Key Pair Generation and Installation

6.1.1 Key Pair Generation

6.1.1.1 CA Key Pair Generation

HCDirect root CA and HCDirect subscriber CA key pairs are generated in well protected hardware located at SSAE 16 type II certified data center.

6.1.1.2 Subscriber Key Pair Generation

Authorized HCDirect personnel will generate subscriber key pair in well protected hardware located at SSAE 16 type II certified data center.

6.1.2 Private Key Delivery to Subscriber

Private keys are not delivered to subscribers. They are directly hosted on HCDirect HISP services.

6.1.3 Public Key Delivery to Certificate Issuer

Since keys are generated within CA system, no delivery of public key is required. After issuance, public keys are published through DNS using HISP engine.

6.1.4 CA Public Key Delivery to Relying Parties

HCDirect CA public certificates are available for download through a public repository. It would also be available as part of third party trust bundles.



6.1.5 Key Sizes

HCDirect uses minimum 2048-bit RSA key with SHA-256 algorithm.

6.1.6 Public Key Parameters Generation and Quality Checking

Public key parameter generation and quality checking will be done in accordance with FIPS 186 specification.

6.1.7 Key Usage Purposes (as per X.509 v3 key usage field)

Subscriber certificates will assert the following,

digitalSignature (key usage bit)

keyEncipherment (key usage bit)

extended key usage bit of emailProtection

basic constraint of CA:FALSE

Subscriber certificates that are dual-use certificates MUST not assert the non-repudiation bit.

CA certificates will assert the following,

cRLSign (key usage bit)

keyCertSign (key usage bit)

basic constraint of CA:TRUE

6.2 Private Key Protection and Cryptographic Module Controls

6.2.1 Cryptographic Module Standards and Controls

HCDirect uses cryptographic modules operating in a FIPS 140 level 3 or equivalent security mode.

6.2.2 Private Key (n out of m) Multi-person Control

No stipulation

6.2.3 Private Key Escrow

HCDirect does not provide private key escrow services.

6.2.4 Private Key Backup

The HCDirect root CA private keys and HCDirect subscriber CA private keys are backed up to a secure offsite location to facilitate disaster recovery. Subscriber private keys are also backed up to a secure offsite location to facilitate disaster recovery.

6.2.5 Private Key Archival

HCDirect does not archive private keys.



6.2.6 Private Key Transfer into or from a Cryptographic Module

Transfer of keys from cryptographic modules are restricted to CA administrators and private keys are securely exported for the purposes of key backup.

6.2.7 Private Key Storage on Cryptographic Module

HCDirect’s Root CA and Intermediate CA private keys and Encryption key’s are stored in the FIPS 140 Level 3 Cryptographic Module (HSM).

6.2.8 Method of Activating Private Key

CA administrators can activate CA private keys only after authenticating themselves to a CA server.

6.2.9 Method of Deactivating Private Key

CA private keys are deactivated by CA administrators when not needed for CA functions.

6.2.10 Method of Destroying Private Key

Private keys are destroyed when they are no longer required by utilizing features of the cryptographic modules.

6.2.11 Cryptographic Module Rating

See Section 6.2.1.

6.3 Other Aspects of Key Management

6.3.1 Public Key Archival

Public keys are archived as part of the certificate archival process. Certificates are archived for at least eight years following their expiry or revocation, whichever is sooner.

6.3.2 Certificate Operational Periods and Key Pair Usage Periods

HCDirect root CA private keys will be used for a maximum of 20 years. HCDirect Subscriber’s CA private keys will be used for a maximum of 15 years.

HCDirect root CA certificates will expire after a maximum of 20 years. HCDirect Subscriber’s CA certificates will expire after a maximum of 15 years.

Subscriber private keys will be used for a maximum of 6 years. Subscriber public certificates will expire after one year.

6.4 Activation Data

6.4.1 Activation Data Generation and Installation

HCDirect conforms to DirectTrust CP and mandates the use of strong activation data for protecting private keys. Strong passwords or smartcards will be used as



activation data. The Issuer CA or Subscriber may only transmit activation data via an appropriately protected channel and at a time and place that is distinct from the delivery of the associated cryptographic module.

6.4.2 Activation Data Protection

Administrative personnel will be instructed not to write down or share activation data. Activation data will not be stored in the same cryptographic module or saved in local storage. Activation data will be entered by trusted personnel during service startup and is destroyed automatically whenever servers are powered down.

6.4.3 Other Aspects of Activation Data

No stipulation.

6.5 Computer Security Controls

6.5.1 Specific Computer Security Technical Requirements

HCDirect CA systems are only accessible to authenticated users. HCDirect has built-in access control and only authorized users are allowed to perform protected actions. An audit log is maintained for all transactions.

6.5.2 Computer Security Rating

No stipulation.

6.6 Life Cycle Technical Controls

6.6.1 System Development Controls

HCDirect software systems are developed using agile development methodology utilizing modern source code control. Software updates are deployed only after internal testing and QA review.

CA hardware and software are dedicated for performing only CA functions. HCDirect may use virtualized hardware meeting the requirements of this CPS.

6.6.2 Security Management Controls

The configuration of the CA systems are controlled and documented. Only authorized administrators are allowed to configure, modify or upgraded CA systems. All administrative access to the systems are logged.

6.6.3 Life Cycle Security Ratings

No stipulation.



6.7 Network Security Controls

HCDirect RA, CA and HISP servers are well protected against intrusion attacks. Firewalls are in put in place and RA, CA and HISP service management is only available through secure channels. Periodic vulnerability scans are performed to assess network security controls.

6.8 Time-stamping

All network enabled systems will be synchronized using a trusted time service using Network Time Protocol. HCDirect will ensure that all times used are accurate within 3 minutes.

7 Certificate, CRL and OCSP Profiles

7.1 Certificate Profile

Certificate profile, CRL profile and OCSP profile (if used) conform to the DirectTrust CP. Please refer the same. HCDirect currently does not operate an OCSP responder.

7.1.1 Version Numbers

HCDirect shall issue X.509 v3 certificates.

7.1.2 Certificate Extensions

See DirectTrust CP v1.4, section 7.1.2

7.1.3 Algorithm Object Identifiers


7.1.4 Name Forms


7.1.5 Name Constraints

No stipulation.

7.1.6 Certificate Policy Object Identifier

See DirectTrust CP v1.4 section, 7.1.6

7.1.7 Usage of Policy Constraints Extension

No stipulation.

7.1.8 Policy Qualifiers Syntax and Semantics

No stipulation.



7.1.9 Processing Semantics for the Critical Certificate Policy Extension


7.2 CRL Profile

7.2.1 Version Numbers


7.2.2 CRL and CRL Entry Extensions


7.3 OCSP Profile

No stipulation.

8 Compliance Audit and Other Assessments

8.1 Frequency or Circumstances of Assessment

HCDirect will initiate a compliance audit once every two years. These audits may be part of an external accreditation process such as DTAAP. These audits will cover HCDirect operational procedures and hosting facilities.

8.2 Identity/Qualifications of Assessor

The auditor must demonstrate competence in the field of compliance audits. The CA compliance auditor must be thoroughly familiar with the requirements which the CA imposes on the issuance and management of its certificates.

8.3 Auditor’s Relationship to Assessed Entity

The CA Declaration of Conformance shall describe the compliance assessor’s relationship to the CA, indicating whether the assessor is internal to the CA or an independent compliance auditor.

8.4 Topics Covered by Assessment

No stipulation.

8.5 Actions Taken as a Result of Deficiency

HCDirect will remedy any deficiencies detected as part of assessment by executing a formal action plan.

8.6 Communication of Results

No stipulation.



9 Other Business and Legal Matters

9.1 Fees

9.1.1 Certificate Issuance/Renewal Fees

HCDirect charges subscriber fees for certificate issuance and renewals of direct certificates. Fee details are available upon request. HCDirect retains its right to effect changes to such fees and subscribers will be suitably advised of price amendments as detailed in the subscriber agreements.

9.1.2 Certificate Access Fees

HCDirect currently does not charge for access and use of certificate by relying parties.

9.1.3 Revocation or Status Information Access Fees

HCDirect currently does not charge a fee for revocation or status information access.

9.1.4 Fee for Other Services

Details of additional services and their fee are available upon request.

9.1.5 Refund Policy

HCDirect currently does not offer any refunds.

9.2 Financial Responsibility

9.2.1 Insurance Coverage

HCDirect maintains a minimum general liability insurance of $1 million with a commercial insurance provider.

9.2.2 Other Assets

No stipulation.

9.2.3 Insurance or Warranty Coverage for End-entities

We do not offer any insurance or warranty coverage for end entities.

9.3 Confidentiality of Business Information

9.3.1 Scope of Confidential Information

Except for the information released by HCDirect in this document or other public channels, all information related to security or operation of HCDirect is confidential. This includes, but not limited to, all private keys, confidential documents related to identity verification and internal procedures/policies.



9.3.2 Information Not Within the Scope of Confidential Information

Information available in the public direct certificates issued and certificate revocation list are not within the scope of confidential information.

9.3.3 Responsibility to Protect Confidential Information

All participants in the PKI must take reasonable degree of care in protecting confidential information. Business associate agreements further define responsibilities for protecting confidential information.

9.4 Privacy of Personal Information

9.4.1 Privacy Plan

HCDirect protects subscriber identifying information from unauthorized disclosure. Detailed privacy policy may be available in subscriber agreements.

9.4.2 Information Treated as Private

Subscriber agreements dictate what information is deemed private.

9.4.3 Information not Deemed Private

Information available on the issued public certificates is deemed not private. Any information available in the public domain including, but not limited to, public NPI records, WHOIS databases or through internet resources is not treated as private.

9.4.4 Responsibility to Protect Private Information

HCDirect will use commercially reasonable efforts to protect private information.

9.4.5 Notice and Consent to Use Private Information

This would be specified in subscriber agreements.

9.4.6 Disclosure Pursuant to Judicial or Administrative Process

HCDirect will not disclose private information unless allowed by subscriber agreements or unless required by law.

9.4.7 Other Information Disclosure Circumstances

No stipulation.

9.5 Intellectual Property Rights

HCDirect will not knowingly violate the intellectual property rights held by others.

Certificates issued by HCDirect are exclusive property of HCDirect. HCDirect gives permission to reproduce and distribute certificates on a non-exclusive, royalty-free basis, provided that they are reproduced and distributed in full.



HCDirect reserves the right to revoke the certificate at any time and at its sole discretion.

HCDirect retains the copyright of this CPS document.

9.6 Representations and Warranties

9.6.1 CA Representations and Warranties

HCDirect CA warrants that it will perform the functions outlined in this CPS in accordance with applicable laws and regulations and in a professional manner in accordance with this CPS.

9.6.2 RA Representations and Warranties

RA warrants that,

Information provided by the RA within the certificate is true and correct.

It has completed required identity verification as required by this CPS.

It will perform the functions of an RA in a professional manner and in accordance with applicable laws and regulations and this CPS.

9.6.3 Subscriber Representations and Warranties

Subscriber warrants that,

Information provided by the subscriber for certificate generation is true and correct.

It has provided accurate identity information

Direct certificate will be used in conformance with this CPS and all applicable laws and regulations.

9.6.4 Relying Parties Representations and Warranties

Relying party warrants that,

It will only use certificates for the purpose for which they were intended, and for no other purposes whatsoever, and in compliance with all applicable laws and regulations and this CPS.

It will check each certificate for validity and authenticity.

It will promptly notify HCDirect of any issues or problems with a certificate of which it becomes aware.

Relying party’s decision to rely on the information within a certificate is solely its responsibility.

9.6.5 Representations and Warranties of Affiliated Organizations

No stipulation.



9.6.6 Representations and Warranties of Other Participants

No stipulation.

9.7 Disclaimers of Warranties

To the extent permitted by applicable law, HCDirect shall disclaim all possible warranties, including any warranty of merchantability and/or fitness for a particular purpose.

9.8 Limitations of Liability

To the maximum extent permitted by law, HCDirect will not be liable under this CPS for lost revenues or direct, indirect, special, incidental, consequential, exemplary or punitive damages whether arising from contract, tort, legislation, or any other theory of liability, any death or personal injury, any liability arising from reliance on information in a certificate if the fault in the verified information due to fraud or willful misconduct of the applicant, or from the certificate usage not in conformance with this CPS.

Individual subscriber agreements may have additional clauses pertaining to liability.

9.9 Indemnities

To the extent permitted by applicable law, the subscriber agrees to indemnify, defend and hold HCDirect harmless from and against all claims brought by a third party against HCDirect that arise out of,

Subscriber’s breach of its responsibilities.

Subscriber’s use of HCDirect services, other than those claims arising out of or related to the negligence or wilful misconduct by HCDirect in providing services.

Additional indemnities may be found in the subscriber agreement.

9.10 Term and Termination

9.10.1 Term

This CPS is effective from the date mentioned as “effective since”. This CPS has no specified term and will remain effective until a new version is released and is effective.

9.10.2 Termination

As decided by the HCDirect Policy Group, we may terminate or revoke this CPS, portions of it, or its application to any subscriber in our PKI.



9.10.3 Effect of Termination and Survival

The requirements of this CPS shall remain in effect until the end of the validity period for all certificates issued by HCDirect Subscriber CA.

9.11 Individual Notices and Communications with Participants

No stipulation.

9.12 Amendments

9.12.1 Procedure for Amendment

HCDirect Policy Group may occasionally amend, revise or update this CPS.

9.12.2 Notification Mechanism and Period

Any significant changes to CPS which might impact subscribers would be intimated to subscribers within 30 days of approval by HCDirect Policy Group and prior to the effective date of the updated CPS. Minor updates to the CPS may be made without any notice to the subscribers.

9.12.3 Circumstances under Which OID Must be changed

HCDirect Policy Group will decide whether a change in this CPS warrants a change in OID.

9.13 Dispute Resolution Provisions

Disputes between us and any of our subscribers shall be resolved pursuant to provisions in the applicable agreement between the parties. Before initiating any third party dispute resolution mechanism, all parties engaged with HCDirect PKI agree to notify HCDirect of the dispute with a view to seek dispute resolution.

9.14 Governing Law

Subject to any limits appearing in applicable law, the laws of the State of California, USA, shall govern the enforceability, construction, interpretation and validity of this CPS, irrespective of contract or other choice of law provisions and without the requirement to establish a commercial nexus in California, USA. This choice of law is made to ensure uniform interpretation for all participants of HCDirect.

Each party in HCDirect PKI agree that court actions, which may arise out of this CPS, will take place in California, USA.

9.15 Compliance with Applicable Law

This CPS is subject to applicable national, state, local and foreign laws, rules, regulations, ordinances, decrees, and orders including, but not limited to, restrictions on exporting or importing software, hardware, or technical



information. We will comply with all applicable laws. Our subscriber agreements also will mandate compliance with all applicable laws.

9.16 Miscellaneous Provisions

9.16.1 Entire Agreement

This CPS constitutes the entire agreement related to the subjects herein and supersedes all prior agreements written or oral. The headings, subheadings, and other captions in this CPS are intended for convenience and reference only and shall not be used in interpreting, construing, or enforcing any of the provisions of this CPS.

9.16.2 Assignment

Parties bound by subscriber agreement may not assign any of their rights or obligations under this CPS or applicable agreements without the written consent of HCDirect.

9.16.3 Severability

If any provision of this CPS is for any reason and to any extent found to be invalid or unenforceable, the remainder to this CPS shall remain in full force until this CPS is updated. Any waivers of and consents to any terms of this CPS must be in writing to be effective. Any such waivers or consents applies only to the sections of this CPS specifically mentioned in them.

9.16.4 Enforcement (Attorneys’ Fees and Waiver of Rights)

No stipulation.

9.16.5 Force Majeure

HCDirect will not be liable for failure to perform any of its obligations under this CPS if such failure is caused by an event outside its reasonable control, including but not limited to, an act of God, war, strike, an act of terrorism, fire, or natural disaster. HCDirect incurs no liability for failure to perform any of its obligations under this CPS if such failure is caused by any provision of any applicable law/regulation/order, by any act of civil/governmental/military authority or by failure of systems operated by third parties over which HCDirect has no control.

9.17 Other Provisions

No stipulation.

Date post:	25-Aug-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

HCDirect Certification Practices Statement (CPS) Health ... · HCDirect Certification Practices...

Documents