360X Closed Loop Referral Project
Transport Workgroup
Wednesday, October 3, 2012
2PM
Meeting Minutes

Greg Meyer leads today’s workgroup in Paul’s absence.

Two main topics for today’s workgroup: certificate discovery & certificate policy.

Certificate discovery:
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
Greg begins with the groundwork and purpose for certificate discovery.
Everything inside of Direct uses certificates, both for encryption purposes and identity, i.e.
performing trust validation to determine who the sender is.
In order to do so, the sending party must discover the certificates of recipient, and vice
versa.
There are several different ways for this to be accomplished.
The easiest way is to have a public certificate of either sender/receiver directly inside
system, however this surfaces management issues. For example, if new users are
onboarded, sender or receiver has to then retrieve these new user certificates.
Also, if new certificates are issued even at an organization level, they need to get
redistributed in a streamlined way.
The Direct project tried to describe methodologies of dynamic discovery, meaning that
either sender/recipient may not have their public certificates in hand at time of
messaging.
The only prerequisite is having an email address and it discusses how to get the
appropriate certificate associated with that address.
The Applicability Statement defines using DNS as the methodology to do this and
provides specific detail on how to do so.
September of last year, S&I Framework created sub workgroup on Certificate Discovery
and generated the Certificate Discovery for Direct Project Implementation Guide.
This began with DNS, but the discussion grew to identify other mechanisms for certificate
discovery. The workgroup outcome was that DNS is still there, but can leverage LDAP as
well.
Guide describes how to use LDAP in combination with DNS using SRV records to
dynamically discover 1) location of LDAP server based on email address and 2) the
different LDAP queries used to discover these.
The Guide also lists precedence or order in which these should be executed. DNS should
be used first, then LDAP if first methodology doesn’t work.
From a certificate publisher’s perspective, you have a choice to publish via DNA or LDAP
in accordance to technical specifications outlined.
As a discoverer, you had to support both methodologies because you didn’t know which
method publishers were using.
This guide had been published by S&I framework groups.
Earlier this year, the MOD Spec Phase 2 and 3 team did assessment of Applicability
Statement and came out with testing guides and open questions to Direct project
community.
Direct project reviewed questions and generated Version 1.1 as a result.
o
o
o
o

Greg opens meeting for discussion on certificate discovery:
o
o
o
o
o
o
o
o
o
o
o
o
o

One question specifically addresses Certificate Discovery: Do we want to make it a
required component of the Applicability Statement, in accordance with the S&I
Framework?
Greg outlines that the Applicability Statement does not specifically state this, quoting
section 1.4 “The organization SHOULD publish the certificates for discovery by other
implementations for the purposes of encryption and signature verification. To support
universal certificate discovery, an organization that publishes certificates MAY do so
using either DNS (see Section 5 of this applicability statement) or LDAP as described in
the S&I Framework Certificate Discovery for Direct Project Implementation Guide.”
(Applicability Statement for Secure Health Transport, Version 1.1, Page 6).
However, in order to ensure universal interoperability, the use of one of these methods is
highly recommended.
For this 360X Workgroup, Greg recommends following along these same
recommendations and following S&I Framework because it promotes a higher level of
interoperability for the participants.
Peter Bachman agrees with each of these points and identifies two main streams:
discovery mechanism when you don’t know where the certificate is, and the question of
looking one up when you do know where it is.
In second use case for provider directory, it specifically has ability to store certificates. If
using HISP PD for example, or chained to other PDs through a mechanism, if you know
where to look for it then you don’t have to repeat discovery mechanism.
Greg agrees and explains that if you already do have certificate in a known location or
storage mechanism, these mechanisms are sufficient.
Peter suggests leveraging built-in referral mechanism that exists within LDAP and X500
that can contact other LDAP servers (part of their protocol). Can demonstrate this on
Federal Bridge and do a query.
Basic mechanism in X500 and LDAP is added to by the DNS if you do not know where to
look.
However, if you discover a path to go between other LDAP servers to discover, this is
valid as well.
Greg generalizes these two streams: if you do not know where to look, use
implementation guide as least common denominator. If you do have another mechanism
in place (LDAP, X500, etc.), you are more than welcome to use these.
Sab Monatesti asks if there is a rational as to why LDAP-to-LDAP chaining was removed
from document; suggests that there should be an audit trail for this.
Greg recommends speaking to Bob Dieterle on this point.
Stephen Beller suggests that there should still be a reference to this in the
implementation guidance.
Sab agrees and feels that when a project is ONC driven and attempting to satisfy
interoperability, removing a significant technology advantage sends the wrong message.
Greg further explains that this is published, and that using this implementation guide as
the baseline for our guide is the best way to stay within the standards without redefining
them. The caveat, however, is if there are alternative methods for certificate discovery
that the HISP has, they are welcome to use them (if they do not have certificate location).
Greg assures that the group agrees with this consensus (receives feedback) and
suggests moving on to policy.
Certificate policy:
o
o
Greg provides background on how Direct project uses certificate authorities or trust
anchors (universally used).
When a message is created and goes through the STA function, first discovers the
certificate for encryption (the recipients encryption). The sender then uses own private
o
o
o
o
o
o
o
o
o

key (usually managed by the HISP or another equivalent mechanism) to find the
message. That certificate and private key, whenever a certificate is generated, must be
vetted or signed by an authority that vouches for the identity inside certificate. This entity
is a trust anchor.
In terms of doing trusted exchange, these certificate authorities used to sign them are
exchanged between the two entities doing message exchange.
When user A send certificate to user B, they sign the message with their private key.
When user B receives messages, discovers public certificate of user A, and public
certificate is able to figure out that message signature is verified and contents have not
been tampered with.
The last trust piece, is that the public certificate that was used to sign the message is
then taken and user B’s system looks to see if a trust anchor was used to sign the
certificate.
If it can chain the certificate up to a trust anchor, then a trusted sender is identified and
the message finishes the process.
Greg explains that the real questions is not technical aspect of Direct project, but what
are the policies that govern these certificate authorities, i.e. what policies and practices
are used to identify how these authorizes manage certificates, store private keys, do
identity vetting.
There a several workgroups focusing on this, i.ee Western Consortium and
Directtrust.org. Trying to determine common practices and policies that theses authorities
should abide by to secure trusted exchange.
Greg believes that in June or July, ONC published an implementation guide for state HIE
grantees on direct infrastructure and security trust measure of interoperability. 4-5 page
document that outlines best practices that authorities should be abiding by, feels that the
group should look at these as base guidelines. (Greg emails this to the group).
Greg describes the recommendations around STA guidelines that address policy within
the document.
Greg then suggests that the group should generate an implementation guidance around
some of the minimum level polices that a CA should abide by, i.e. certificate practice
statement on how their infrastructures run, a medium level assurance in terms of identity
vetting.
Greg opens meeting for discussion on certificate policy:
o
o
o
o
o
o
o
o
o
Direct was allowed temporarily to use a single certificate that allows signing and
encryption, however this may change.
Greg explains that this is being discussed within the Federal Bridge and waiting. This will
have policy and implementation effects as well because Direct implementations currently
will not be able to support this model.
Can you distinguish in DNS between two certificates?
Greg explains using policy based usage. However, nothing inside Applicability Statement
pertains to this.
Sab asks if the breakdown behind this undecidedness is if we go national, will there be a
need for exchange of specific keys.
Greg explains that this won’t change anything in privacy piece, but if you are signing and
encrypting there will need to be different certificates for both. It becomes a policy
question. Needing two certificates will be more costly as well.
Greg explains “good news” that there was an anticipated NPRM coming down on NwHIN
governance that you would have to use FBCA cross certified. However, this governance
did not occur.
There are some HISPs out there that decided to use FBCA, but for non-FBCA certificates
it is a non-issue.
Greg’s recommendation in terms of identity assurance of the certificates is that even
though State HIE from ONC is stating FBCA, the level assurance conforms to medium
o
o
o
o
o
o
level of identity assurance and other policies at least map equivalent of FBCA. However,
still unsure how to state this.
Greg then explains the discoverability of trust anchors.
Today in Direct project, there is not automatic or dynamic discovery of certificates,
instead described as out of band exchange of certificates.
The answer is that trust anchors don’t have to be root certificates, they can be
intermediate certificates. For the actual exchange of these types, there is no way of
dynamic discovery.
Automatically finding certificates is a secondary issue because before you want to add a
certificate to a list, you must decide that you want to trust it.
Greg brings the group back to two specific issues: 1) whether or not you actually want to
trust a certificate based upon policy, and 2) once trust is decided, now how do you go
obtain the certificate, i.e. provider directory. This second exchange is the most important
part; specifically, how you make sure the certificate authority that you are receiving is
trusted.
Greg suggests beginning next week’s workgroup from this point and focus on
recommendations for exchange of trust anchors, and group agrees.