On Sun, 2003-12-21 at 07:26, Richard D Piper wrote: > > Some of the deficiencies of the HeSA system have been addressed - such > > as a simplified user agreement (the original was over 50 pages long) - > > and client software libraries (for Java I think) which now support Linux > > and Mac OS X systems as well as Windows. But it is still a closed source > > system, and still uses dongles or tokens to hold the user's private > > signing and encryption keys (which has good and bad points - personally > > I think hardware devices are unnecessary but I concede that secure > > management of private keys without them is a non-trivial issue). Not > > sure if facilities for automated look-up of certificate revocation files > > has improved - that was also a problem. > > I have been trying to get them to support Mozilla for some time (even on > Windows), there is a "beta" guide to this which I am looking at. I find > it hard to understand how they could have implemented a system that was > meant to embrace and open standard, and then only really supported > windows for so many years.
Indeed. Many tens of millions of taxpayer's money have been spent on the HeSA PKI so far, with apparently a rather small take-up. Of course, the primary motivation for it was to enable HIC (our national, universal, govt-run health insurance system) to securely collect Medicare (which has universal coverage here in Oz) forms from GPs and thus avoid the huge cost of processing paper claims forms. So they designed the system with this goal in mind, but forgot that there needed to be some incentives for GPs to use it, beyond saving HIC money (which GPs don't care about). The software choices, the use of a full X.509 PKI, and the modus operandi of generating keys on the user's behalf were all dictated by the need to adhere to the Federal govt's Gatekeeper standards (which were in turn designed by the national security agencies) - they lost sight of the real-life needs of practicing clinicians - primarily the need to be certain that their communications about their patients are indeed private - and that is not certain in any system in which another party generates keys on your behalf. Pity, but it is not too late for them to fix the system, and there are signs this is happening (albeit slowly). > One of the real problems with there approach is that it is a huge amount > of work to verify identities on a national basis, and keep up with the > re-issuing certificated that have to be revoked. Identifying someone who > works in the same hospital is easy ... but not someone you have not met > who lives on the other side of the country. It was slow and complicated > applying for the HESA dongle, ... just imagine that replicated for every > medical practitioner in the country (to start and then each time they > loose there dongle). Sure. By far the hardest part of any PKI (X.509 or otherwise) is the task of ensuring and proving that a public key really does belong to the person it is supposed to belong to. Doing that requires a chain-of-evidence - you can't avoid that. Handling the turnover in certificates (keys) due to expiry or compromise/loss of private keys is the next biggest problem, followed by how to maintain the security of private keys on shared computer systems while still permitting automated encryption using those private keys. So yes, a PKI which supports every health professional in the country would be expensive to establish and operate, but you need to view such expense in the context of the AUD$45 billion p.a. public sector health budget (and privae sector on top of that, I think), and the huge efficiency gains which such a widespread infrastructure would provide. If your personal belief system allows it, align yourself to face south-west and pray to the deities in Canberra... (Apologies to non-Australian subscribers to this list for the parochial nature of this and related postings). -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0
signature.asc
Description: This is a digitally signed message part
