Certificate Pilot Recommendations Discussion
Call for Consensus
- ===Consensus was achieved by Implementation Group WG===
- ===Consensus was achieved by the Best Practices WG and Implementation Geographies WG ===
Certificate management for Direct Communities and Participating Organizations
Note that this discussion talks about Direct communities and participating organizations rather than squashing them together into implementations. It is a specific goal of Direct that in its final form, organizations will be able to use their single Direct implementation to exchange messages with participants from many different communities. Each community defines the policies which their members must adhere to. In the pilot phase, each organization/implementation might belong to only one community, but this will almost certainly not be true once the project moves into broad adoption.
Community = a group of organizations that agree to a common set of policies to establish directed message exchange
Organization = an entity that collects together one or more endpoints. For example, a HIPAA Covered Entity, a state immunization registry, etc.
Implementation = a deployment of Direct technology to deliver messaging functionality as a Full Service HISP to an organization
Our current expectation is that each pilot “geography” will deploy as a distinct Direct community. In the pursuit of ubiquitous addressing, it would also be useful if a broader, nationwide certificate authority were to emerge as well, so that any provider who wanted to use Direct would have an opportunity during the pilot phase. Such an authority might also serve as the beginning of a nationwide authority, but is unclear who would take on that responsibility at this time.
The certificate discoverability “gotcha” (pilot phase only)
Universal addressability within the Direct model requires that any given endpoint is able to discover the public certificates for a destination address, because this certificate is required to perform encryption according to the specification. There are a number of feasible means by which this discovery can happen: DNS CERT records, LDAP, out of band exchange, and empty message exchange are some that have been proposed. It is the desire of the Direct team to specify a common discovery mechanism as the “baseline” for implementations. However, the team agreed that we could not make that definitive decision without further experimentation during the pilot phase.
Therefore --- each pilot community will have to decide what method or methods will be used for certificate discovery by the implementations deployed by its participating organizations. The “agent-based” C# and Java reference implementations each implement a DNS option and expect to have an LDAP option available as well.
If it is important to a community that purely client-side S/MIME implementations be an option for participating organizations (i.e., without using an agent-based HISP), they will have to decide how certificates will be discovered and managed in that environment. This document does NOT attempt to provide guidance for those implementations. A separate discussion on this approach can be found ATSOMEURLONTHEWIKI. The rest of this document assumes that clients will connect to an agent-based HISP (which may be on-premise or off-premise) and use the reference implementations’ DNS or LDAP based certificate discovery channels.
Overview of Community Policy Decisions
The primary trust decision a Direct community must make is, how will private keys be granted and distributed. The Direct specification purposely allows a great deal of flexibility here, choosing to encapsulate all of the policy decisions into the pre-conditions that result in possession of a valid certificate and key pair. Some of the rationale and technical details informing the specification are found in the Security and Trust Workgroup Consensus Proposal. Please note that the term "trust" in this document refers specifically to the trust enabling policy and decisions required to establish "Messaging Handling Policy" as defined in that document, and in particular, in paragraph 1.4.
Question #1: Who is the Trust Anchor for the community?
Some entity must have the power to decide the criteria for which certificates are issued for the purpose of message exchange within their community. Examples of these entities may be: an HIE organization (e.g., MNHIE or Redwood Mednet), a distributed IDN (e.g., Kaiser or Group Health), a PHR system (e.g., HealthVault or Google Health), or a community of interest (e.g., NACHRI). This entity must have the ability to (1) at some level enforce compliance with community policies, and (2) physically issue certificates.
Pilot recommendation: The community should create their own root certificate and stand up their own certificate server to issue certificates to participating organizations (Can be done with Windows Certificate Server, OpenSSL or others). This will ensure flexibility during the pilot phase. Post-pilot, it probably makes sense for communities to contract with an entity that already has in place processes and procedures for validating conformance to policies and issuing certificates, such as Verizon, Verisign, Entrust or Thawte. Communities that wish to exchange data with Federal providers and agencies must have certificates that chain to the Federal Bridge Certification Authority. See the IDManagement.gov website for more details.
Question #2: Organization or end-user certificates or both?
Direct supports a model where certificates can be unique to individual addresses (foo@hospital.com) or the domain for the collective organization (hospital.com). The community may choose to make a policy that requires certificates be associated with addresses, however, this places a significant additional burden on either the community or participating organizations to issue and manage a large number of certificates. Note that there is some momentum towards individual certificates in the industry and the government, but they are not widely adopted yet.
The reference implementations do not issue certificates --- they merely allow administrators to associate certificates with endpoints and domains.
Pilot recommendation: Implementations may use organization-level certificates to minimize the complexity of provisioning and management. If participating organizations wish to use address specific certificates, take one of two approaches:
a. If the organization already has certificates it would like to use, have the other community members add the organization's trust anchor to their implementations. We hope that organizations will do this only if it is of significant benefit to their existing workflows and security processes; otherwise, using new certificates for Direct issued by the community authority will simplify overall configuration.
b. If the organization would like to issue new certificates for each endpoint, the community should make the organization a registration authority, so that the burden of address specific certificate management is on the participating organization, not the community.
The recommendation for organizational certificates is the same regardless of whether the organization's system is hosted in an external data center, with a HISP, or located at the organization's premises.
Question #3: What should be minimum identity and authorization requirements for a community?
A baseline policy might be simply that the participating organization has been physically verified to be a legitimate organization that sends or receives protected health information, and has confirmed their commitment to complying with HIPAA and/or other applicable regulations. This would provide basic assurance that the organization handles their technology systems in line with current expectations, including performing identity assurance consistent with at least NIST Level 2 for members and securing networks and data (see NIST special publication 800-63). Community policy should recognize existing methods of identity assurance and authentication; for instance, hospital credentialing, certificate issuance for scheduled medication prescribing, and identity assurance and authentication required to gain access to EHR systems or EHR modules will often provide sufficient levels of assurance and authentication to issue certificates and private keys. In cases where such pre-existing methods do not exist, we recommend the following best practice for identity assurance for providers:
- Verify the place of practice, through means such as by contacting (e.g., by phone) the practice or provider through independently sourced contact information (e.g., white or yellow pages directories) or through knowledge based methods
- Verify government issued IDs and licensure, including looking up licensure information in public registries
For patient-focused organizations, for the pilot phase a baseline policy may be that community members will only exchange messages with a patient address that was given to them in person, to ensure that the HIPAA disclosure made in sending to that address was authorized by an appropriate individual.
The identity and authorization requirements for certificate issuance must be uniform for issued certificates to have any meaning. Because identity assurance requirements will often be very different for certificates issued to patients and to patient organizations (e.g., PHR organizations) than those issued to providers, provider staff, and provider organizations, the trust anchors for each must be different.
Communities that are using separate certificate authorities for certificate issuance should ensure that the criteria for certificate issuance of the CA are consistent with the requirements of the community.
Pilot recommendation: While these notes attempt to posit an appropriate baseline, it is critical for success that pilot communities “own” their policy requirements and do not accept these recommendations blindly. Post-pilot, the Direct project team will evaluate success and challenges with various approaches with the goal of beginning to establish a national baseline that can accelerate truly ubiquitous Direct messaging.
Question #4: What should be the expiration policy for certificates?
Policy should balance the value of regular refreshing of anchors and certificates with the operational burden of doing so.
Pilot recommendation: Eighteen months seems a reasonable expiration policy for anchors and certificates, with an intent to refresh after 12 months.
Overview of Organization Policy Decisions
Organizations much decide with which communities they wish to exchange messages (including ad-hoc peer-to-peer “communities” created by exchanging self-signed anchor certificates). In the pilot phase, this may be a single community representing the pilot, but when adoption begins to scale organizations will almost certainly find themselves participating in multiple communities. This may resolve over time to a single national community, but there is no guarantee that will happen.
Question #5: Should our organization participate in a given community?
Pilot Recommendation: On a community-by-community basis, organizations should simply decide if:
1. There is benefit in exchanging messages with other members of the community.
2. They are willing to comply with the community policies required to obtain a community certificate.
3. They are comfortable that the community policies provide adequate protection for exchange.
If the answer to all of these questions is yes, the organization should obtain an organizational certificate from the community, and:
a. Configure the community’s trust anchor certificate in their implementation.
b. Associate their new certificate with their organization.
Question #6: How should I format Direct addresses for my organization?
Pilot Recommendation: So long as addresses conform to the Direct address specification (in effect they are “normal” e-mail addresses), there is no additional requirement on how endpoint names are chosen or domains associated with organizations. We recommend, however, that:
- Fully qualified domains be allocated for the purposes of health information exchange
- The domain name not imply membership is a particular trust circle (in particular, not imply membership in the Nationwide Health Information Network)
Many organizations have chosen a pattern of "direct.example.org".
Question #7: Can we re-use existing e-mail addresses for Direct messaging? Can we re-use existing e-mail clients for Direct Messaging
The core Direct Project specifications do not require special e-mail addresses or dedicated e-mail clients. Their use may, however, mitigate against the risk of inadvertent use or mixing of business and clinical exchange functions.
Pilot Recommendation: Each organization should do a risk assessment and make tradeoffs considering security, patient safety, impact on user workflow, likelihood of user error, etc. - and consider analysis conducted for the Threat Models for simple SMTP and SMTP With Full Service HISPs. The use of dedicated e-mail domains for exchange and dedicated e-mail clients may mitigate some of these threats.