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 albin.stigo@gmail.com
 designates 209.85.161.180 as permitted sender)
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>
 <CAKrvCPiuq9DAe_rHVeKW4c2iOe7snopuyJxJFOEexK8pV+o22w@mail.gmail.com>
 <CAMc++1VB-gNi=byzW_1to_EjWmZ4hvKmKC7-jAvupjSu7MQEsg@mail.gmail.com>
 <CAGUGYeiwmNwZ-wYrGOXB7Qym8yE+B-uSqKQyc83hC6qM_jsrCQ@mail.gmail.com>
From: =?ISO-8859-1?Q?Albin_Stig=F6?= <albin.stigo@gmail.com>
In-Reply-To: 
 <CAGUGYeiwmNwZ-wYrGOXB7Qym8yE+B-uSqKQyc83hC6qM_jsrCQ@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 4 Jul 2012 21:11:07 +0200
Message-ID: <-3046869085809654149@unknownmsgid>
Subject: Re: Cryptograhically signed docs...
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Yes, I agree with you, it can probably be done in JavaScript in a
normal validation function.. The only problem is how to maintain a
list of keys.. For a test version you can just have them stored along
with the code in the validation doc using ie couchapp's !json macro..
But I think it would be really neat with a _keys db..

Another way of doing it, that I think could be implemented quite
efficiently, is to have a separate worker process listening to changes
stream and have a validation doc that marks all new docs with
"verified: false. The worker process could then change this to true
after it checked the signature. Sorry if I'm a bit brief but I'm
typing this on an iPhone.

Sendt fra min iPhone

Den 04/07/2012 kl. 21.00 skrev Bernhard Gschwantner <bernhard@unserwein.at>=
:

> I've been following this thread and like the idea. I may be na=EFve or
> completely wrong, but all this sounds quite easy to solve in a design
> document and with pure javascript, although probably not very performant.
> Just take jens' structure proposal and modify openpgp.js a little bit, pu=
t
> the stuff into a validate_doc_update function, add the allowed public key=
s
> to a design doc (easy with a couchapp), et voil=E0: you get a completely
> replicable and transparent signature checker ;-)
>
> If I find the time tomorrow, I'll take a shot on a proof of concept. The
> building blocks are there already...
>
> Cheers,
> Bernhard
>
> Am Mittwoch, 4. Juli 2012 schrieb Albin Stig=F6 :
>
>> Sounds interesting.. I think I will take this to the developers mailing
>> list and see if I will be able to generate some interest in the idea..
>>
>> Albin
>>
>> onsdag den 4. juli 2012 skrev Jan Bot :
>>
>>> 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<j=
avascript:;>
>> <javascript:;>>
>>> wrote:
>>>
>>>> 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<javascr=
ipt:;>
>> <javascript:;>>
>>> 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/thecolle=
ctor-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
>> that
>>>> uses documents will have to know to call read_message, which will also
>>> make
>>>> 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
>>> you
>>>> have to know about the signature scheme is while verifying the
>> signature.
>>>> It's even possible to have multiple signatures on a document.
>>>>>
>>>>> =97Jens
>>>>
>>>
>>
>
>
> --
>
> Bernhard Gschwantner
> Unser Wein G&U OG
> Kirchengasse 13/7, 1070 Wien
>
> mobil: +43 (6991) 971 32 96
> tel: +43 (1) 971 32 95
> e-mail: bernhard@unserwein.at
> twitter: @bernharduw <http://twitter.com/bernharduw>
> web: www.unserwein.at