Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of janjbot@gmail.com designates
 209.85.160.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAMc++1VzimcH8sFzYunE2PSANz_8+4ufzv0H0HQoCYRUQpq2oQ@mail.gmail.com>
References: 
 <CAMc++1U53sht7v24j+ktQyNe=e2cDTkCsdsX3Bm-KY-0rLR=Eg@mail.gmail.com>
	<79061073-7E58-4CBC-9DC1-8A98C6811796@sri.com>
	<0848BFC4-1340-4FF9-A04D-EE6D205A90A0@couchbase.com>
	<CAMc++1VzimcH8sFzYunE2PSANz_8+4ufzv0H0HQoCYRUQpq2oQ@mail.gmail.com>
Date: Wed, 4 Jul 2012 20:40:01 +0200
Message-ID: 
 <CAKrvCPiuq9DAe_rHVeKW4c2iOe7snopuyJxJFOEexK8pV+o22w@mail.gmail.com>
Subject: Re: Cryptograhically signed docs...
From: Jan Bot <janjbot@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=e89a8fb205f2d85cce04c4055b52

--e89a8fb205f2d85cce04c4055b52
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,

This would really be a great feature: I'm using CouchDB to manage grid
compute jobs and having the ability to sign a document using a private key
and check it server side with the public key could really make couchdb part
of the grid infrastructure.

Cheers,

Jan

On Wed, Jul 4, 2012 at 11:17 AM, Albin Stig=F6 <albin.stigo@gmail.com> wrot=
e:

> Hi,
>
> Jens, thanks for the link. Did you ever finish the app where you were
> using these techniques?
>
> First I naively thought that it would be enough to hash the body of
> what you are going to PUT/POST and then sign that hash and include the
> signature as a custom http header. I guess this would work for
> verifying the data on the first post but you would not be able to
> verify the signature later if couchdb does any parsing of the
> transported data.
>
> What you are suggesting using a canonical representation of of JSON
> seems like a much better idea it also apparently what oauth uses.
>
> I guess this would require some hacking on couchdb. It would be really
> neat to have a _keys database much like the _users and for for
> documents to have a _signature field. What do you thin..?
>
> --Albin
>
>
>
> On Wed, Jul 4, 2012 at 3:07 AM, Jens Alfke <jens@couchbase.com> wrote:
> >
> > On Jul 3, 2012, at 10:01 AM, Jim Klo wrote:
> >
> >> Yes, and as a matter of fact, i just got digital signature validation
> using OpenPGP within a map function working a few minutes ago!
> >> Here's a link to the relevant code:
> https://github.com/jimklo/TheCollector/blob/master/dataservices/thecollec=
tor-resources/views/lib/sig_utils.js
> >
> > As far as I can tell, this code uses a data schema where the signed
> contents are wrapped in some kind of OpenPGP encoding:
> >
> >>         var msg_list =3D
> openpgp.read_message(doc.digital_signature.signature);
> >>         for (var i=3D0; i<msg_list.length; i++) {
> >>             isValid |=3D msg_list[i].verifySignature();
> >>         }
> >
> > It looks like msg_list is the actual document payload, which has to be
> decoded using openpgp.read_message.
> >
> > This is IMHO not a very good solution because it hides the document
> contents away =97 for example, all the map functions and any app logic th=
at
> uses documents will have to know to call read_message, which will also ma=
ke
> them slower.
> >
> > The schema I implemented (see my previous message) doesn't alter the
> basic document format. The signature is in a nested object but applies to
> the entire document contents (minus the signature itself of course).
> There's no need to change any code that reads documents; the only time yo=
u
> have to know about the signature scheme is while verifying the signature.
> It's even possible to have multiple signatures on a document.
> >
> > =97Jens
>

--e89a8fb205f2d85cce04c4055b52--