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

[Karsten Hilbert]

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
signatures.

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
        but
signature is null

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

> - reviewed and good signature
row in clin.review_root
        and
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 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

-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346