Skip to content. Skip to main navigation.


Blog


  • April 12 2012


    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.

  • Comment
  • Bookmark
  • Print

5 Comment(s)

in response to The Direct Project: A modular view - part three

Therasa Bell

5/1/2012 11:36:29 AM

Thanks Greg! The articles were very concise and a great education tool that I will use for employees and customers as we introduce them to Direct concepts. Thanks again.

Christopher Bischoff

7/31/2012 11:14:12 AM

Excellent overview - however I am looking for design specifics - with individual user certificates for encryption (SSMIME); how are traditional email controls applied in a centralized fashion by the HISP (AV, Malware, DLP scanning of the contents of the message)? Unless the email controls are applied in the user "presentation" layer before encryption - user creates message and hits send - message is scanned - encrypted then sent (via SMTP) and stored in user mailbox.

Greg Meyer

8/9/2012 2:05:34 PM

Christopher, Excellent question. This is specific design issue my HISP had to deal with as well. There a quite a few ways this could be addressed, but I'll break it down into two generic categories: 1. Application layer: This would be logic specific in the edge client (or presentation layer as you called it) where content based rules would be applied directly in the client before the message is sent over the edge protocol. Same could be said for the receiving edge client. Example would be the virus scanning done in gmail with attachments. 2. HISP layer: This is a little trickier. HISPs are intended to be service providers, and as service providers, they take on the burden of certification management, encryption, trust validation, message delivery etc. For the most part they are decoupled from the edge client, so control policies would be a service provided by the HISP. If a HISP want to add supports for it, it could provide tooling to control centralized polices at an organizational or even individual user level. These are all value adds, but could definitely be added to a HISP's offerings. As an example, a HISP could automatically scan messages for viruses or malware after they received over the edge protocol, but before they are encrypted. The reverse could be done for the receiving system. I know these are general answers, but I hope they lead you down the right direction.

Andrew P

1/5/2013 4:18:58 PM

Thanks Greg for explaing the concepts in a very simple yet insightful way . I especially found the part about establishing trust very helpful including the challenges associated with it.

Greg Meyer

1/10/2013 3:09:05 PM

Andrew, I'm thrilled to hear you found the content valuable. Trust, specifically scalable trust, is the hot topic in Direct right now. I highly encourage you to keep follow the new trust focused workgroups forming in the Direct community via the wiki (wiki.directproject.org).