The group also recognized that both Direct and NwHIN exchange can use the same technology. A point I made in S/MIME vs TLS -- Two great solutions for different architectures.
What is very exciting is that the group did come to the conclusion that HHS/ONC should take a leadership role in managing certificate trust, specifically recommending that there be a certificate authority that is available for building a Nationwide Health Information Network (NwHIN) that is cross-certified with the Federal PKI Bridge. The good news on this is that the CA that the NwHIN Exchange uses today is cross-certified with the Federal PKI Bridge. So, I think this simply means continued funding and explicit endorsement of this model. This would make managing trust across the nation 'easy'.
As soon as anyone says that managing trust is 'easy' those in the security domain get worried. This worry is well founded as security is hard. One timely and specifically targeting of certificate management is the "Compromise of SSL Digital Certificates". This news has gotten some people to question the X.509 PKI model, and even the SSL/TLS protocols. In both of these cases the technology are in no way flawed. The technology is still the best technology available today. What is broken is the way that certificates are managed for Internet based Web-Servers. This broken part is very different between Internet based Web-Servers and the way that HIT Standards expect NwHIN to operate.
1) Default - No Trusted Certificates
- The recommendation for the Direct Project is that there are no assumed certificates, that a site explicitly trust certificate roots only when there is known and validated reason to trust.
- In the NwHIN Exchange there is ONLY one Certificate Authority that is 'trusted' by the systems
- In IHE ATNA there is a warning about the need to have a different trust pathway for healthcare than is used for internet web servers (See IHE ITI 2a:220.127.116.11)
- Essentially for Healthcare Information, there should be a totally independent analysis of 'who should you trust'
- Direct fully recognizes this, and the report out showed this. Indeed it recognizes that sometimes in e-mail communication one trusts specific certificates and not necessarily all certificates issued from a Certificate Authority.
- The participants in the NwHIN Exchange will likely need to have more than the one Certificate Authority in order to support the local connections.
- IHE specifically recognizes both of these as fact. And points to an excellent white paper from NEMA
3) Certificate Revocation mechanism are needed
- Direct didn't fully specify this, but did include it in the Security Model
- The NwHIN exchange includes certificate revocation
- IHE recommends that systems support both OCSP and CRL mechanisms.
- In all cases a certificate should not be 'trusted' unless it has been fully validated. Full validation does include checking the signature and how it chains to the set of trusted certificates, that the certificate has not expired, and that it is not revoked.
This mechanism is not typically used for root certificates. This is the problem that is being exercised with the current SSL Digital Certificate Compromise, in that there is a Certificate Authority 'Comodo' that had it's infrastructure compromised. Thus there is a need to tell the world that their root certificate needs to be un-trusted. As scary as this situation is, it doesn't happen very often. Given that it doesn't happen very often, there is little energy spent on trying to automate it. Given the breath of 'trust' that all of the copies of Internet Browsers have (the distribution mechanism); this un-trust is a very big problem.
The result is that X.509 and Certificate Management is the right technology for building technical trust for Healthcare. But this does not mean that we can relax and not continuously think about this trust. We should recognize that the way that Internet Web-Servers is a different management model than we will use in Healthcare. This is the key to why a system that seems broken for Internet Web-Servers should be considered highly secure for Healthcare Information.
Which leads to the second part of the presentation. a topic I covered Healthcare Provider Discoverability and building Trust