Ian, Jim, et al when we first set up the tables for review tracking I argued that we need to store reviews per document *part* since a *document level* signature would allow adding parts without invalidating the signature. I still maintain the view that we need to safeguard against signed-scope manipulations.
However, I have come to think that I proposed the wrong (or rather short-sighted) solution to the problem: ticking off objects as we do still allows an attacker to change the *content* of existing, ticked off objects thereby slipping in fake signed objects under the radar. The real solution is - as always - proper application of cryptographic signing. So, the now-suggested reviewed root table would contain the following fields: key_context text key_id text sig text - key_id identifies the key within the domain defined by key_context - key_context would contain things such as "GPG key", "RIPE-MD160 hash", IOW it sets up the context needed to properly apply the key identified by key_id such as domain, hash algorithm, signature algorithm - sig would hold the signature for blobs.doc_obj.data when applying the key with id key_id in the context of key_context Now, Ian's argument was that medically it only makes sense to sign entire documents - which I do agree to, medically. My solution to this was to make the client aware of that business rule and have it sign whole documents at once. Given the above approach we *could* move up the attachment of the reviewed signature to the doc_med level - but we don't have to. Exactly *what* is put into the fields is up to the clients. V0.2 might constrain itself to key_context = 'md5 of "staff.short_alias + doc_obj.data + staff.short_alias"' key_id = dem.staff.pk sig = select md5(staff.short_alias || doc_obj.data || staff.short_alias); While vX.Y employs full-blown client-side memory-only GPG signing. So, what do you all think - about the approach and about attaching sigs directly to doc_med rows ? Note that at no time do we store key information or even passphrases etc in the database. Those need to be supplied by the client when validating a signature. A client might then display: - not reviewed - reviewed but signature not verifiable - reviewed but signature not valid - reviewed and good signature Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
