From user-return-21449-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Wed Jul 4 20:30:11 2012 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BCAF49E55 for ; Wed, 4 Jul 2012 20:30:11 +0000 (UTC) Received: (qmail 87426 invoked by uid 500); 4 Jul 2012 20:30:10 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 87391 invoked by uid 500); 4 Jul 2012 20:30:10 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 87381 invoked by uid 99); 4 Jul 2012 20:30:10 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jul 2012 20:30:10 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=FSL_RCVD_USER,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [74.125.82.180] (HELO mail-we0-f180.google.com) (74.125.82.180) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jul 2012 20:30:05 +0000 Received: by werf11 with SMTP id f11so4063866wer.11 for ; Wed, 04 Jul 2012 13:29:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version :x-gm-message-state; bh=6+4VUfShhHMnLERp4ysQ321UFwWg8Nkm0K7YbpFWbkg=; b=RkZ1XiG0QpW9+cncK7eyIYvij0T0JU5pD7FftD7wJUGXfqzHKre8g2ZmMRz8ZFNUJI 9VjWrWbB3c+sx3bYJfL7+C7toxM0Npiy1mqXjc/4eHLCRPiIcM5i3JzDUsGdY6xgGliW XseoKjik2Zf3beYkbzeTOyj4NSDHtI6nop7bLWLfzB6VETu4gDiDvwz5pzGUDKW+N8RL V2V1jRvwAuV6cWYPGmHh954XJpPaXCMW7QfbloUbj1sD77/S2OwEQOAlCRJIs/a+Fsot 4j10v8EcxsgAzP1b53GnRtKJ/m+Y510XfRH7LyXgVFIptI2S2zF/hTQbzjQPJkjyQTY7 Kp6g== Received: by 10.180.100.131 with SMTP id ey3mr23071109wib.15.1341433783187; Wed, 04 Jul 2012 13:29:43 -0700 (PDT) Received: from [192.168.1.2] (chello062178167102.12.14.vie.surfer.at. [62.178.167.102]) by mx.google.com with ESMTPS id fw4sm38738420wib.0.2012.07.04.13.29.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jul 2012 13:29:42 -0700 (PDT) Subject: Re: Cryptograhically signed docs... References: <79061073-7E58-4CBC-9DC1-8A98C6811796@sri.com> <0848BFC4-1340-4FF9-A04D-EE6D205A90A0@couchbase.com> <-3046869085809654149@unknownmsgid> From: Bernhard Gschwantner Content-Type: text/plain; charset=utf-8 X-Mailer: iPad Mail (9B206) In-Reply-To: Message-Id: Date: Wed, 4 Jul 2012 22:29:40 +0200 To: "user@couchdb.apache.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Gm-Message-State: ALoCoQmx2KbBv4l28n0Xh+J+lOX+55trMDgAjpAkDi11jU7xaLTjxPBQa+tLRguGir0+s4rtlDmv X-Virus-Checked: Checked by ClamAV on apache.org 1) The userCtx has nothing to do with the owner of the document (think repli= cation - the user who started the replicatipn is in the userCtx, not the sig= ner of each document) 2) you only get the user's groups in the userCtx, not all properties. So you can only store the keys directly in the design document. -- Bernhard Gschwantner=20 Unser Wein G&U OG=20 Kirchengasse 13/7, 1070 Wien mobil: +43 (6991) 971 32 96=20 tel: +43 (1) 971 32 95=20 e-mail: bernhard@unserwein.at=20 twitter: @bernharduw=20 web: www.unserwein.at Am 04.07.2012 um 22:10 schrieb Jan Bot : > Hi, >=20 > Wouldn't it be possible to just store the (public) key of a user within a > userdoc (under _users)? >=20 > Cheers, >=20 > Jan >=20 > On Wed, Jul 4, 2012 at 9:31 PM, Bernhard Gschwantner > wrote: >=20 >> If you are the only one controlling the keys, a really nice approach for >> managing the keys is with (the original python) couchapp: just store each= >> key as a single .json file in a subfolder, and couchapp takes care of >> encoding each key as a property of the design doc. From >> validate_doc_update, you can access the whole design doc via the this >> keyword. So this input: >>=20 >> public_keys >> Alice.json: ...public key as a string... >> bob.json: ...bob's key.... >>=20 >> Should be accessible in the validate function like this: >>=20 >> var keys =3D this.public_keys; >> keys.forEach(function(key){...}) >>=20 >> I'm on the iPad, so also a bit brief... ;-) >>=20 >> Bernhard >>=20 >> -- >>=20 >> Bernhard Gschwantner >> Unser Wein G&U OG >> Kirchengasse 13/7, 1070 Wien >>=20 >> mobil: +43 (6991) 971 32 96 >> tel: +43 (1) 971 32 95 >> e-mail: bernhard@unserwein.at >> twitter: @bernharduw >> web: www.unserwein.at >>=20 >> Am 04.07.2012 um 21:16 schrieb Simon Metson > >>> : >>=20 >>> You could use CommonJS (http://wiki.apache.org/couchdb/CommonJS_Modules)= >> to store the keys, that would make them available to views and validation= >> functions, and I think is a bit more efficient than !json (because you ca= n >> use them over multiple functions). It kind of depends on how much turnove= r >> you expect on the keys. >>>=20 >>>=20 >>> On Wednesday, 4 July 2012 at 20:11, Albin Stig=C3=B6 wrote: >>>=20 >>>> 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.. >>>>=20 >>>> 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. >>>>=20 >>>> Sendt fra min iPhone >>>>=20 >>>> Den 04/07/2012 kl. 21.00 skrev Bernhard Gschwantner < >> bernhard@unserwein.at (mailto:bernhard@unserwein.at >> >> )>: >>>>=20 >>>>> I've been following this thread and like the idea. I may be na=C3=AFve= 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,= >> put >>>>> the stuff into a validate_doc_update function, add the allowed public >> keys >>>>> to a design doc (easy with a couchapp), et voil=C3=A0: you get a compl= etely >>>>> replicable and transparent signature checker ;-) >>>>>=20 >>>>> If I find the time tomorrow, I'll take a shot on a proof of concept. >> The >>>>> building blocks are there already... >>>>>=20 >>>>> Cheers, >>>>> Bernhard >>>>>=20 >>>>> Am Mittwoch, 4. Juli 2012 schrieb Albin Stig=C3=B6 : >>>>>=20 >>>>>> 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.= . >>>>>>=20 >>>>>> Albin >>>>>>=20 >>>>>> onsdag den 4. juli 2012 skrev Jan Bot : >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>=20 >>>>>> key >>>>>>> and check it server side with the public key could really make >> couchdb >>>>>>=20 >>>>>> part >>>>>>> of the grid infrastructure. >>>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> Jan >>>>>>>=20 >>>>>>> On Wed, Jul 4, 2012 at 11:17 AM, Albin Stig=C3=B6 > (mailto: >> albin.stigo@gmail.com ) >>>>>> > >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> Jens, thanks for the link. Did you ever finish the app where you >> were >>>>>>>> using these techniques? >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> What you are suggesting using a canonical representation of of JSON= >>>>>>>> seems like a much better idea it also apparently what oauth uses. >>>>>>>>=20 >>>>>>>> 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..? >>>>>>>>=20 >>>>>>>> --Albin >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Wed, Jul 4, 2012 at 3:07 AM, Jens Alfke > (mailto: >> jens@couchbase.com ) >>>>>> > >>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> On Jul 3, 2012, at 10:01 AM, Jim Klo wrote: >>>>>>>>>=20 >>>>>>>>>> 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: >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>=20 >> https://github.com/jimklo/TheCollector/blob/master/dataservices/thecollec= tor-resources/views/lib/sig_utils.js >>>>>>>>>=20 >>>>>>>>> As far as I can tell, this code uses a data schema where the signe= d >>>>>>>> contents are wrapped in some kind of OpenPGP encoding: >>>>>>>>>=20 >>>>>>>>>> var msg_list =3D >>>>>>>> openpgp.read_message(doc.digital_signature.signature); >>>>>>>>>> for (var i=3D0; i>>>>>>>>> isValid |=3D msg_list[i].verifySignature(); >>>>>>>>>> } >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> It looks like msg_list is the actual document payload, which has t= o >>>>>> be >>>>>>>> decoded using openpgp.read_message. >>>>>>>>>=20 >>>>>>>>> This is IMHO not a very good solution because it hides the documen= t >>>>>>>> contents away =E2=80=94 for example, all the map functions and any a= pp logic >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> that >>>>>>>> uses documents will have to know to call read_message, which will >> also >>>>>>>=20 >>>>>>> make >>>>>>>> them slower. >>>>>>>>>=20 >>>>>>>>> The schema I implemented (see my previous message) doesn't alter >> the >>>>>>>> basic document format. The signature is in a nested object but >> applies >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> 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 >>>>>>>>=20 >>>>>>>=20 >>>>>>> you >>>>>>>> have to know about the signature scheme is while verifying the >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> signature. >>>>>>>> It's even possible to have multiple signatures on a document. >>>>>>>>>=20 >>>>>>>>> =E2=80=94Jens >>>>>=20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> Bernhard Gschwantner >>>>> Unser Wein G&U OG >>>>> Kirchengasse 13/7, 1070 Wien >>>>>=20 >>>>> mobil: +43 (6991) 971 32 96 >>>>> tel: +43 (1) 971 32 95 >>>>> e-mail: bernhard@unserwein.at (mailto: >> bernhard@unserwein.at ) >>>>> twitter: @bernharduw >>>>> web: www.unserwein.at (http://www.unserwein.at) >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >> -- >>=20 >> Bernhard Gschwantner >> Unser Wein G&U OG >> Kirchengasse 13/7, 1070 Wien >>=20 >> mobil: +43 (6991) 971 32 96 >> tel: +43 (1) 971 32 95 >> e-mail: bernhard@unserwein.at >> twitter: @bernharduw >> web: www.unserwein.at >>=20