Certificate Discovery for Direct Project Implementation Guide Version 4.1, 20 August 2015 Revision History Date Document Version Document Revision Description Revision Owner 2011-10-19 1.1 Revisions from F2F meeting Ken Pool 2011-10-24 2.0 Revisions from Bob Dieterle Bob Dieterle 2011-11-09 3.0 Revisions from Ken Pool Ken Pool 2011-12-14 4.0 First revision following comments Ken Pool 2015-08-20 4.1 Revision addressing corrections and clarifications identified by the Direct Certificate Discovery Tool (DCDT) team. Original Authors Workgroup Lead Ken Pool, OZ Systems Workgroup Lead Sri Koka, Techsant Technologies Participating Author Peter Bachman, Cequs Inc. Participating Author Bob Dieterle, EnableCare Participating Author Ernest Grove, SHAPE HITECH, LLC Participating Author Lester Keepper, SHAPE HITECH, LLC 1. Introduction The Provider Directories Initiative focuses on identifying the requirements, core data set, and standards to support two specific use cases: Discovery of Digital Certificates for the Direct Project; and Discovery of Electronic Service Information (including electronic address and any required security information) in order to support the electronic exchange of health information. The health care industry has utilized provider directories for years. The content of individual directories has varied substantially based upon intended use and audience. The Provider Directories Initiative created within the S&I Framework is not intended to replace existing directories - its primary goal is to support the electronic exchange of health information in a secure fashion. This Implementation Guide addresses the use case for discovery of digital certificates for the Direct Project using a hybrid approach based on DNS and LDAP. The Direct Project DNS Configuration Guide addresses the discovery of digital certificates stored in DNS CERT records. The hybrid approach to discovery of digital certificates extends the work described in that document to enable the universal discovery of certificates via LDAP services. Briefly, this guide’s approach for Direct Project certificate is: DNS is used as the entry point leveraging its global discoverability. LDAP is used when the DNS record does not support the CERT record or when LDAP is preferred by the publisher. See Section 3.1 for a detailed description. This guide provides specific technical guidance on: Publishing and discovering LDAP services using the DNS SRV record. Querying an LDAP service for digital certificate discovery using anonymous binding for a specific Direct Project address. The digital certificate(s) obtained from the query facilitate the secure exchange of health information. 1.1 Purpose This Implementation Guide enables providers and others to electronically obtain the digital certificate of a desired destination to support secure transfer of health information. Adopting and implementing this guide’s approach to certificate discovery provides the following benefits: The ability for providers and other authorized entities to retrieve digital certificate(s) to facilitate secure exchange of health information A standardized query mechanism for Certificate Directories that can be adopted by EHR and HIE vendors, State HIEs, HISPs and other mediators of exchange The standardization and simplification of the implementation of interfaces to query Certificate Directories 1.2 Scope The scope of this guide addresses a single scenario - in it, the digital certificate requester has a Direct Address associated with the digital certificate(s) being requested and queries a Certificate Directory to retrieve the digital certificate(s): Scenario 1: The digital certificate requester or the digital certificate requester system has a known Direct Address associated with the digital certificate being requested. The digital certificate requester’s system does not have the digital certificate(s) associated with the Direct Address. The digital certificate requester system sends a query to the Certificate Directory without user intervention. The Certificate Directory returns zero or more digital certificate(s) associated with the Direct Address. The digital certificate requester performs Certificate Validation on the digital certificate returned by the Certificate Directory. The digital certificate requester selects the correct digital certificate(s) for the intended use when multiple certificates are returned. 1.3 Audience This Implementation Guide is intended to assist providers, payers, and any other health care organization that wants to participate in secure health information exchange. Specifically it informs: Vendors/Developers, who need to understand, design, and develop Direct project compliant messaging. HISPS/Providers who are configuring DNS and LDAP services to support Direct certificate discovery. Registration Authorities/Certificate Authorities who certify health care organizations and/or individuals and issue Direct digital certificates. 1.4 Assumptions The Certificate Discovery for Direct Project Implementation Guide assumes the following: The certificate recipient will validate the certificate but this is not covered in this guide. Access to digital certificates for the Direct Project is assumed to be world readable. The Provider, Patient, and health care organizations and individuals who implement the Use Case will use the guide to enable interoperable exchange of protected health information (PHI) using Direct Project messaging. The Implementation Guide continues the methodology for defining needs, selecting and developing standards, and implementing those standards in a testable, sustainable way via the “Standards and Interoperability Framework – Use Case Development and Functional Requirements for Interoperability." The reader is familiar with the Direct Project. The Direct address is the canonical address. 2 Development of Guidance The Certificate Discovery for Direct Project Implementation Guide provides specific guidance for the development, implementation, and ongoing discovery of S/MIME digital certificates for known Direct defined addresses. To develop this guidance, the S&I Framework PD sprint team investigated currently available options for an open and universally accessible approach to discovering S/MIME digital certificates using only the Direct address. The investigation focused on two specific, highly deployed technologies – DNS and LDAP. The hybrid approach to discovery of digital certificates is based on the findings of this investigation. This hybrid approach ensures: That the digital certificate can be obtained if located in a DNS CERT record That the digital certificate can be obtained if located in an LDAP implementation That existing DNS implementations that do not support CERT can facilitate locating the digital certificate That data contained in LDAP implementations by health care organizations that store S/MIME certificates can contribute to this use case. A complete summary of the team’s findings can be found in Appendix D: Development of Guidance. 3 Implementation Guide As defined by Direct project, a “Security Trust Agent (STA)” refers to the actor who has a Direct address to which they wish to send information and for which they need to obtain the associated digital certificate. In general, we expect the STA to actually be an application or a service used by the sender. The “Publisher” refers to the actor who has digital certificates for specific Direct addresses and wishes to make those digital certificates available for use. We also will refer to the organization Direct address DNS record as the full domain specification consistent with the Direct Project Rules of the Road communities. We assume that both the consumer application and the publisher are familiar with the basics of DNS and LDAP. We also assume they both adhere to industry best practices in their use of these technologies. Lastly, we assume the reader is familiar with the Direct Project Rules of the Road and especially the Direct Project – Applicability Statement for Secure Health Transport. Briefly, this guide’s approach for Direct Project certificate discovery is: ● DNS is used as the entry point leveraging its global discoverability. ● LDAP is used when the DNS record does not support the CERT record or is preferred by the publisher. See Section 3.1 for a detailed description. DNS allows for multiple Resource Records (RR) that support the storage of a number of different content types. This guide uses RR capability in two ways. First, a digital certificate can be stored in a CERT RR if the CERT RR has been entered into a DNS zone record. Second, the domain name and port information for an LDAP service can be stored in a SRV RR as defined by RFC-2782, “A DNS RR for specifying the location of services (DNS SRV)”. The SRV RR standard also allows for multiple LDAP service instances to be advertised with a standard protocol for establishing the relative priority among them. For this guide, the STA is expected to establish their criteria for what they consider a valid digital certificate for their use. For guidance on validating certificates for use in Direct, see the policies as detailed in Direct Project – Applicability Statement for Secure Health Transport Section 4.0 and Direct Communities of interest for specific stakeholders. While security surrounding the proper use of digital certificates is beyond the scope of this initiative the STA may wish to consider whether the DNS resolver implements DNSSEC to protect against security flaws. 3.1 DNS/LDAP Hybrid Digital Certificate