[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] on meaningfully signing off reviewed items
From: |
Karsten Hilbert |
Subject: |
[Gnumed-devel] on meaningfully signing off reviewed items |
Date: |
Wed, 25 Jan 2006 18:04:42 +0100 |
User-agent: |
Mutt/1.5.11 |
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] on meaningfully signing off reviewed items,
Karsten Hilbert <=