Hello Horst, I appreciate that the timestamps are not secure, and I fact mentioned that. To fix that the PKI API would have to securely call a function on a timestamp server, much like codesigning applications do.
The sequential reference number is designed to overcome this to some extent. I does however make it hard for the average doctor to change the date of a letter after the fact and do a poor quality scan to satisfy some HIC requirement. I would think that the external signature solution, while better, would be more of an impost, not less. In a way it makes the current requirements easier to comply with. Not perfect, but a compromise solution. This is the link to the HIC, it covers the other requirements so that we are talking about the same thing. http://www.medicareaustralia.gov.au/resources/pki/ma_notice_of_it_standards_electronic_and_paper_011005.pdf Andrew Wednesday, March 1, 2006, 7:00:13 AM, you wrote: HH> On Tue, 28 Feb 2006 22:25, Andrew McIntyre wrote: >> For medico-legal purposes signing all incoming documents with a >> location key would make them fairly secure against tampering and >> provide absolute integrity checking, this is something we can do. If >> you do that with scanned documents and follow the other storage >> requirements then its a legally valid document as per the HIC >> guidelines. HH> Doubt it very much. HH> Firstly, signing an incoming document with your location key proves absolutely HH> *nothing* - since you can set your own computer's date at will and sign HH> whatever you want whenever you want it. And whether you store your document HH> on DVDs on the moon or on a harddisk in your waiting room again changes - HH> zilch. HH> The only possible way of proving document content and integrity as per a HH> certain date is per *external* certification - anything that gets stored by a HH> third party outside of your reach HH> What I proposed several years ago (the gnotary system) was a peer to peer HH> based solution: in intervals every users determines himself, the system HH> generates hashes of files he wants to certify, and transfers these hashes to HH> other systems where he cannot access them. As "payment", he receives and HH> stores hashes from other systems. HH> Advantages: HH> 1.) costs nothing (other than a tiny bit of bandwidth and some digital storage HH> space HH> 2.) The further the hashes get replicated, the less likely anybody could ever HH> modify them all regardless of effort HH> 3.) reliability through redundancy - if your hashes get transferred to HH> hundreds of systems it is most unlikely all of them will have failed by the HH> time you need the proof HH> 4.) Full control of the owner of the data what gets certified when HH> 5.) No patient related information ever leaves the system - no privacy issues HH> Alas, nobody here seemed to understand why they would want such thing and HH> participation was near zero (3 or 4 GPs participated for some time in Oz, but HH> it has taken off in Germany and Holland and is rather widely used there now) HH> Horst -- Best regards, Andrew mailto:[EMAIL PROTECTED] Andrew McIntyre Buderim Gastroenterology Centre www.buderimgastro.com.au PH: 07 54455055 FAX: 54455047 _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
