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