As many of you may know, ONC has asked for comment on approaches that will enable providers and other healthcare entities to obtain and manage digital certificates that are cross- certified with the Federal Bridge. This comment period for the report is through June 5th.
Due to the short timeframe for comments, we would encourage anyone who is interested to submit comments through the S&I Framework wiki.
The comments on this report will help to shape the foundation for the S&I Framework Certificate Interoperability initiative (details which will follow).
Clarifying PKI interoperability
I am afraid the way we think about “interoperability” in PKI has been overly influenced by government secrecy classification, and old notions of “key exchange” (PGP) and the related idea of cross certification, which seeks to show that two strangers Alice and Bob have equivalent credentials. Equivalence is irrelevant in healthcare authentication. Counterparties may have totally different roles: one might be an insurance loss adjuster and the other a medical professional submitting a discharge summary in support of a claim, or one might be a government bureaucrat and the other a family physician reporting a case of a notifiable disease. In fact, it’s not always the case that both counterparties to an e-health transaction even have certificates: what can policy mapping and the like even mean then?
I submit here a few thoughts on how to think more clearly and elegantly about interoperability.
A senior finance sector executive once captured the uncertainty perfectly: “[PKI] interoperability is something of a will-o’-the-wisp. You think you understand what people mean by it, and then quickly realise that you don’t. In my experience, it’s possible when discussing interoperability to be at cross-purposes for all of the time. Interoperability between members of the same PKI is axiomatic. Certificates issued by one bank should be recognisable by another. Interoperability becomes an issue when it is between different PKIs … But this still leaves the basic question of interoperable in respect of what?”.
Indeed, interoperability is so very ‘axiomatic’ that many pivotal papers on the topic – like the PKI Forum’s 2001 whitepaper “CA-CA Interoperability” – omit to even define the term, or to spell out its precise objectives.
It really isn’t complicated. The best place to start thinking about interoperability is to revisit how digital certificates can help with the act of authentication. From the perspective of the Relying Party, the central question is very simple: What information is available – in the certificate chain and elsewhere – to help decide whether to accept or reject the certificate and hence the clinical document?
There are three main things the RP needs to know about a certificate.
1. What representations does the certificate make about its holder? Or equivalently, was the certificate intended to be used in the transaction concerned? Increasingly, digital certificates are used to represent specific credentials or memberships and to thereby confer particular authorisations (see also www.lockstep.com.au/library/pki/relationship_certificates). For example, a certificate issued by a medical authority can confer the rights of the holder to write prescriptions, claim government rebates and so on. Such digital credentials will bear a unique Policy OID, and perhaps the holder’s registration numbers as well.
2. Is the certificate subject still valid (i.e. not revoked)? Sometimes the question will be backdated, because significant time may elapse in healthcare between signing say an EHR entry or a prescription, and that document being relied upon. So the question is, was the certificate holder valid at the time they launched the transaction?
3. Was the certificate issuer acting in compliance with applicable standards and regulations? A CA’s status should be made available online in machine readable form; one way to do this is for a regulator to issue a compliance certificate to the CA in X.509 format, with the regulator acting as a trust anchor for all certificates issued within its domain.
All of this information can be incorporated into the certificate chain. A signed e-health transaction should in general be sent along with the entire certificate chain (along the same lines as S-MIME signatures). It is a simple matter for all software apps in a given e-health domain to come equipped with the appropriate trust anchors pre-configured (there won’t be all that many trust anchors, and e-health software is generally ‘high maintenance’, meaning lots of opportunities to install the roots).
The outcome then is “application level” interoperability: all the information an application needs in order to accept or reject a certificate can be found in the certificate chain.
Yet the now-orthodox way of approaching “interoperability” is through Bridge CAs and elaborate policy mapping. My analysis is that Bridge CAs might not be ideal in decentralised non-government environments.
When sender and receiver are in different domains, the fundamental outcome of PKI interoperability should be to deliver those three pieces of information described above to the systems that need it in order to tell if the sender’s certificate is fit for purpose. That is: (1) Does the sender’s Policy OID indicate suitable credentials? (2) Was the sender’s certificate valid at the time of signing? And (3) Was the CA valid at the time?
The orthodox approach of policy mapping is an exhaustive comparison of the Certificate Policies (and Certificate Practice Statements) of the CAs of each counter party. The desired end result is a cross-certificate that causes certificates from other domains to chain back to a local root, as if those certificates were equivalent to local ones, imbuing them with the same so-called “trust level”.
But cross-certification or policy mapping have several problems. It is laborious. More fundamentally it presupposes that the RP belongs to a PKI, which as mentioned may not be the case. Finally, the fitness for purpose of a certificate (especially in healthcare) is a different sort of property from “trust level”. Digital credentials come in all sorts of shades; it simply doesn’t make sense to compare the generic trust level of say a doctor’s certificate with that of an insurance agent, or bureaucrat, or even another medical professional. How are doctors and nurses “equivalent” for example? It’s a type of category error to construct authentication systems that are preoccupied with equivalence.
It is instructive to review why certificate equivalence became so enmeshed in thinking about PKI interoperability. Governments (especially defence agencies) were the first adopters of PKI. In a typical government PKI, trust levels are much like national security clearances. Officials in different domains need to know one another’s clearance levels, in order to judge whether classified information can be disclosed by senders and entrusted to receivers. So the central question historically was: Is your trust level equivalent to mine, or is it higher or lower?
The objective of a Bridge CA, in an environment where multiple CAs would otherwise seek cross certification, is to centralise all policy mapping. Instead of all CAs needing to cross-certify in a pair-wise fashion, the aim is that any two given certificates from participating systems can be tested in real time and chained together on the spot if they are deemed equivalent.
Yet policy mapping remains very expensive. One senior NIST expert admitted to me in 2008 “Cross-certification and policy mapping has been a rat hole that has sucked up vast amounts of energy better spent elsewhere”.
In contrast to classical government PKI, vertical or closed scheme-based PKIs can manage credentials issued for a particular purpose or business application. Trusted administrators vouch for “scheme” members, issuing certificates with a defined scope, which confer rights to carry out prescribed types of transactions governed by the scheme. A “scheme” can mean anything from an employer and their staff, an application with embedded certificates (like Skype), a consortium governing dedicated appliances (like the cable TV set-top box PKI) or an industry with existing business rules and credentialing processes (such as healthcare).
Now the Relying Party’s question is much more straightforward: Does your certificate show that you a legitimate member of a scheme I recognise? Unambiguous indication of the scheme to which a certificate belongs – and therefore its fitness for purpose –can be coded by the Policy Object ID, which originates from the scheme administrator, and which can be disseminated via regulators and others. Cross-recognition of these types of certificates is automatic if Relying Party software has knowledge of the expected Policy OID(s), via for example a Certificate Trust List.
For further reading, please see:
http://lockstep.com.au/library/babysteps/babystep_1_pki_in_health_welf.pdf
http://lockstep.com.au/library/babysteps/babystep_12_electronic_medic_.pdf
http://lockstep.com.au/blog/2011/01/16/embedded-pki-on-the-cards
http://lockstep.com.au/library/pki/known-customer-certificates-a
http://lockstep.com.au/library/pki/relationship_certificates
I trust that these thoughts are helpful.
Stephen Wilson
Managing Director
Lockstep Group
Sydney, Australia
E: swilson@lockstep.com.au
M: +61 (0)414 488 851
W: http://lockstep.com.au
T: @steve_lockstep
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy. Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft
Posted by: Steve_Lockstep | June 17, 2011 at 08:08 AM