[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] on meaningfully signing off reviewed items

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] on meaningfully signing off reviewed items
Date: Thu, 26 Jan 2006 20:18:35 +0100
User-agent: Mutt/1.5.11

To make a long story short: we weren't that bad, actually.
My basic grudge with (my) initial design holds true: setting
a "reviewed" flag (that is, a review row exists for a
content row) doesn't really have much of a meaning without
it being possible to re-validate *what* was reviewed.

For which problem I just had to add the three fields
mentioned below to the review_root table. Which still leaves
us free in the decision at which level to attach document

To be a little more concise:

> - not reviewed
no row in clin.review_root for row in question

> - reviewed but signature not verifiable
row in clin.review_root
signature is null

> - reviewed but signature not valid
row in clin.review_root
signature fails verification

> - reviewed and good signature
row in clin.review_root
signature passes verification

On Wed, Jan 25, 2006 at 06:04:42PM +0100, Karsten Hilbert wrote:

> 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]