April 12, 2012
The Direct Project: A modular view - part three
In part
one of this series on the Direct Project, I discussed the backbone
transport and message gateway the program uses. In part
two, I explored Direct’s security and trust modules and the importance of
establishing meaningful trust relationships between HISPs. In this brief, final
post, I will define edge protocols and clients and briefly touch on a few
policy elements that govern the day-to-day operations of Direct.
Edge Protocols and Source/Destination Clients
Direct does not specify a set of applications or workflows, called
source and destination clients, for reading or processing the contents of
messages (done intentionally to leverage the genius of developers to innovate
uses of Direct). These applications either generate and/or receive messages. Email
applications like Microsoft Outlook or Mozilla Thunderbird are examples of
clients can both create and receive messages for simple correspondence. In
health care, an example would be a health system (using an EHR) generating a
structured continuity of care document when a patient is discharged and sending
it directly to the patient or another physician or practice. That's right,
Direct is not just email! In fact, I would be so bold as to say it isn’t email
at all. Direct is a set of standards that happens to use the same backbone
transport and payload as email. Email just happens to be one of Direct’s many
use cases.
So, how do the messages get to and from the HISP and to and from the
destinations and source clients? Direct uses a transport method called an edge
protocol to get a message from a source client to the HISP (the converse is
true for destination clients). Aside from using SOAP for XD messages, Direct
does not specify any edge protocols. Those offered by a HISP are offered at the
discretion of the HISP. They may be standard protocols such as SMTP or IMAP or
they may offer proprietary APIs using technologies such as REST, SOAP, or JMS. Some
HISPs may not offer any edge protocols, as they may prefer to only offer their
own Direct-based applications. An example could be a HISP that only offers a
web-mail based inbox. Allowing additional edge protocols supports and encourages
innovation at the edge.
Policy and Procedure
In my opinion, Direct is 30 percent technical and 70 percent policy
driven. The technical specifications and subsequent 1.0 release of the Direct
reference implementations took less than a year to produce from start to finish,
while policy discussions are still ongoing. The reference implementation is an
open source and pre-assembled implementation of the Direct specifications. An
implementation exists in both the .Net and Java languages and can be downloaded
freely from a handful of websites. A subproject of Direct, called Bare Metal,
contains a set of instructions on procuring the reference implementation and standing
up a reference HISP from scratch using only the reference implementation
assemblies.
The reference implementation is a fully working model with all sorts of
bells and whistles, but it's just a model. If you’ve ever delved into the world
of embedded hardware or robotics, the starting point is usually a reference
board. The board is a cookie cutter model with several modules, inputs,
outputs, and maybe an operating system or programmable circuits. However, the
reference board is not intended to be the final design that ultimately goes
into your finished solution. It is tweaked and extended with custom modules, or
some modules may be removed. The end product is a customized board that meets
the specific needs of your solution.
The same is true for Direct. The reference implementation comes with a
standard deployment model and software components such as the security and
trust agent, the messaging gateway, a certificate store and a simple web or
command line tool for configuration. However, the model does not meet the
requirements of an industry-class production system, such as high availability,
failover, scalability and disaster recovery. The only edge protocol supported
is XD and POP/SMTP, and although this may work well for email clients,
innovative edge clients and workflows may need other protocols such as REST,
SOAP, and custom authentication and authorization modules.
Finally, the reference implementation does not meet the policy
requirements emerging from the various governance agencies. For example, the
private certificate store in the reference implementation does not meet
auditing requirements for access to private keys. Another example, the auditing
subsystem does not write audit events to a storage mechanism with proper access
controls. The reference implementation is stubbed to meet these requirements
and supports plugging in custom instances of reference implementation
interfaces and/or modules. For a HISP to become fully compliant with industry
best practices, certificate policies and required operational procedures,
investment in infrastructure and some software development is necessary.
Policy and governance are at the heart of ongoing Direct discussion and
development. The list of policies and the agencies that are involved in
developing standards and governance is growing, and I could write another six-part
series on policy alone. However, I will briefly discuss two polices that are cornerstones
of a sound trust framework: identity proofing and vetting and certificate policy
and management.
Identify Proofing
Like so many other topics in Direct, identity proofing concepts and
procedures could make up an entire book. Grossly over-simplified, identity
proofing is the process of assuring that an entity really is what it says it
is. Entire workgroups are dedicated solely to the practice and policies of
identity proofing, and adherence to these policies is a requirement of a HISP.
In Direct there are two types of entities that are identity proofed:
individual users and organizations. In the case of users, a certificate is
issued to each email address. For organizations, a single certificate is issued
for an entire institution or larger entity, generally at the email domain level
though that’s not always the case. Only the organization is identity proofed
for the purpose of certificate issuance, and the organization is responsible
and liable for the vetting of each email address that is issued.
Certificate Policy
Every endpoint in Direct has an X509 certificate associated with it. A
certificate is an electronic credential, meaning it can be used to
unambiguously identify an entity within a certain level of assurance. Level of
assurance describes the policies and procedures used to identity proof the
entity. The higher the level of assurance, the higher the level of proof is
needed to validate the identity of the entity. In X509 certificates, levels of
assurance are asserted by the existence of an attribute called a certificate
policy. There are different types of certificate policies, however each
certificate policy is uniquely identified by an object identifier (OID), a
series of numbers organized in a hierarchical format to uniquely identify a
concept.
Another type of policy attribute is a certificate practice statement
(CPS), a document that outlines the procedures a certificate authority adheres
to when creating, revoking, renewing and validating certificates. It also
outlines technical and management procedures of the certificate authority's
lifecycle. This may include how the authority protects its private keys,
performs backups, audits access to private keys, and possibly how entities are
validated before issuing certificates. The CPS can be complimentary to a level
of assurance policy, and together they give legitimacy to the certificate
authority. Implementing procedures and polices set forth by a certificate
policy or a CPS is not free. In fact, entire business models have been
established around certificate policies. A legitimate HISP should only issue
certificates from an authority that has an established certificate policy and
is prepared to attest to following the policies set forth by their CPS.
Certificate Management
Certificate management refers to the policy and procedures used to
manage the lifecycle of a certificate. These include issuance, revocation,
renewal and rekeying. It can also refer to the procedures used to protect the
integrity of the PKI. This mainly covers protecting private keys, backing up
keys and auditing access to keys. Many of these procedures are outlined in a
CPS and handled by the certificate authority. In the case of HISPs, issued
certificates and their keys are held by the HISP, not the actual entities. This
model is slightly different from most PKIs, where the entities hold their own
certificates and private keys. Because the HISP is the steward of the keys, it
must take proper care in managing and protecting keys from unauthorized access
or malicious attacks.
DirectTrust.org
As I close out this series, I want to bring attention to an outstanding
new community in Direct. Being an engineer for the entirety of my
professional career, policy is not my native domain. I can only speak authoritatively
on a short list of subjects regarding policy, which is why I kept this part of
the series brief.
Over the last year I’ve had the opportunity to participate in
workgroups focused solely on shaping the policies that are driving the future
of Direct, and it has been quite an eye opening learning experience. The most
impressionable have been those within DirectTrust.org. As I’m writing this, DirectTrust.org
is an independent, soon to be incorporated non-profit organization whose goal
is to provide Direct best practices and policy guidance consistent with federal
standards, and to establish a national trust framework for Direct participants.
The organization originated from a workgroup inside the Direct community, and
has been able to attract as members exceptional talent in the security industry.
I highly encourage anyone interested in running or operationalizing a HISP to regularly
visit their website or become a participant in one of the workgroups.
Greg is a director and principal architect at Cerner. He’s responsible for the HISP architecture of the Cerner Direct solution and remains actively engaged in development/coding and mentoring new software engineers and upcoming architects. Also responsible for the Direct Project Java reference implementation architecture and a primary source contributor, Greg serves as co-chair for the Direct reference implementation workgroup and is a contributing member of ONC's Standards and Interoperability Framework initiative and DirectTrust.org.