[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 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 + + staff.short_alias"'
 key_id =
 sig = select md5(staff.short_alias || || 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

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]