Trusting e-Mail

The "The Direct Project" re-branded from "NHIN-Direct Project" - is addressing the use-cases where the very small healthcare clinic that has little or no current Healthcare IT technology can take some initial steps into the Healthcare IT world. I very much support this usecase, as this audience really needs low-tech solutions. Getting this audience to think in terms of electronic documents (text, PDF, CDA, or any other) is more important than getting them convinced on a specific method of exchanging the documents. A component of the Direct Project that has not been totally settled is Trust, that is the 'why' of Trust.

The Direct Project has nice formal "Overview" document. Given that I was a contributor to this document, I think it is a good document. This document is a really good introduction, it is not a technical document, specification, or deployment guide. These other topics are covered elsewhere on The Direct Project wiki

The Direct Project is recommending that Secure E-Mail be used to enable the very small doctor office to communicate Patient information with others. In short, replacing their FAX machine with e-Mail; but e-Mail that is 'secured'.  So, how does e-mail get 'secured'? There are a few ways to do this with the most common being an isolated and/or proprietary messaging system (e.g., the old AOL network). This is clearly not a solution, as it is not standards based nor open. In standards there is PGP and S/MIME (I am not going to spell out the acronyms as it is really not that helpful here). The Direct Project choose to specify S/MIME. This answers the question of the standards to protect the content, but does not address why someone should trust the content.

The technical answer is X.509 Digital Certificates, and Public Key Infrastructure (PKI).  More technology, that I really don't think needs to be fully understood by you, right now. These are technologies that are really good and really mature. They give us a technology equivalent of credit cards. With credit cards there is a known system behind them, there are online ways that merchants can verify they are not stolen. We trust credit cards because we have built up trust in them. They are not all issued by the same company, most are issued by the big credit card agencies, but there are still some that are issued by a local store. The important part is that we as consumers don't know how this all works, but we have come to trust them.

Trust is not easy, I could go deep into the X.509 technical details; But ultimately trust is more of a soft art, it needs to be built and maintained. Trust can be one-on-one, like you and your closest friends; Trust can be built in a close social group, like your church or work; or Trust can be brokered by large institutions. The X.509 system can scale like this as well.

Starting big, the USA has an Infrastructure (PKI) where many federal partners have 'cross-certified'; essentially they have agreed that each-other's way of issuing X.509 Digital Certificates (credit-cards) are good-enough. There is technology behind 'cross-certifying', but I am keeping this blog to softer arts. This cross-certifying allows someone looking at another identity to be sure that it was issued by someone they 'should trust'. Meaning the federal partners have a way to know that the other guy should be trust-able. This cross-certifying has been extended to others. I cover this in more detail elsewhere

This wonderful system says I 'should trust' this identity, but I might not really want to trust them for sending or receiving Patient Data. As a doctor, why would I trust a EVERYONE who has a federal issued identity to send me Patient Data. So, this still means that I need to include some subset that I Trust. I have a number of communications with DoD and VA customers. These certificates chain to the Federal PKI bridge, and I know that they require far more identity assurances than our GE certificate authority. Even with this fact, I do NOT TRUST ALL certificates issued by the Federal PKI bridge. I trust those that I know I should.

In my job as a Healthcare Standards developer, I work with GEs competitors. So I also have signed e-mail conversations with specific individuals in companies like Siemens, Philips, etc. Clearly I do NOT want to trust all of their corporate issued certificates. But I do want to trust their standards developers. I also deal with individual consultants, that use self-signed certificates.

My solution is to leverage the functionality of my email application. When I want to send something securely with someone else, my email application will look into my local directory of trusted X.509 certificates. If it doesn't find one it tells me that it can't send the message securely. If this happens then I send that person a simple email telling them who I am and that I want to send them something securely. I tell my email application to sign this email with my GE issued X.509 Digital Certificate. Eventually I get back an email from this person that is signed by them, thus giving me their X.509 Digital Certificate. Now that I have their X.509 Digital Certificate I can send my original message securely to them.

Trust happened in there. I didn't detail how trust was built, so let me do that now. When anyone receives a signed email, the email application will verify the signature and indicate if it was good, bad, or unverified. Good means that it fully checks out, bad clearly says that there is falsification going on. Unverified means that it checks out, but that the identity is not known. This will happen for any first-contact. If I am not expecting this email, I will likely simply delete it. If I am feeling generous I might read the email to see if there is a reason I should follow up. If I am uncomfortable, I might call the person. It is only after I am comfortable that this is a legitimate email from someone I should trust; then I explicitly tell my email application to trust that certificate.

Today there is not much risk that someone will send me a signed email that I should not trust. I am confident that I can weed these out. The number of individuals that I should trust is likely 100 or less, a rather easily managed number.  I prefer that my X.509 Digital Certificate is NOT published on a white-pages Directory. I am far more worried  that someone will use my publicly available GE issued X.509 Digital Certificate to send me encrypted SPAM, as encrypted email can't be inspected by the GE SPAM filters.

I offer here a way to get started at the 'why' of Trust. Start with the small number of connections that this small provider needs to communicate with. I really don't think that we need a large system of Trust. Like the credit-card industry, starting with the local department-store and building upward is a good roadmap. Setting expectations is the factor we need to teach in awareness. Awareness of what certificates are, what encrypted email is, what signed email is... These tools, just like any new tool needs to be explained to the community. Once they know what the tool is and how it should be used; they can better understand and use it. Encrypted email from someone they have never worked with before is 'unexpected'.