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 2409B9226 for ; Wed, 4 Jul 2012 20:24:41 +0000 (UTC) Received: (qmail 74209 invoked by uid 500); 4 Jul 2012 20:24:39 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 74170 invoked by uid 500); 4 Jul 2012 20:24:39 -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 74158 invoked by uid 99); 4 Jul 2012 20:24:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jul 2012 20:24:39 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FSL_RCVD_USER,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of albin.stigo@gmail.com designates 74.125.83.52 as permitted sender) Received: from [74.125.83.52] (HELO mail-ee0-f52.google.com) (74.125.83.52) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jul 2012 20:24:33 +0000 Received: by eeke53 with SMTP id e53so2988248eek.11 for ; Wed, 04 Jul 2012 13:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=dzT+3PxkDhu24i0vTd9o387pQIE1UegowXJ2IO0z8Nc=; b=A9WYpyJDeFt2jlkipCDqP0aETao2qynR7uEAE7zfdlZYBe/kgkRtvFD+Y471DyDyvS rkliMw9qqUjM31jLL8PimkbLZboHTYQYqD/qyBnCl30vT+7kK+6+Skb8g1fD5+gCueXq ZUQIOvYcfApNF3NoXK1UdBERe3Q4yzn/SpXZock/bL8EylGIYW3dSPlc40XZ4IDhTOA2 Cwi/2Y/w8kXNRhpK2A4W4I2ihKW1nQcXryfSJy/1Fhptuc56F9yCCJnyoaFcJggWUOiP 91wFzKMlFUZMHAMf3ZJmkoHFe9yaj6imeZkauS8X0mZ/c2XDHFYZTcxspGH3ew1GA3mv ZR0w== Received: by 10.14.119.3 with SMTP id m3mr5559118eeh.204.1341433452867; Wed, 04 Jul 2012 13:24:12 -0700 (PDT) Received: from [192.168.1.115] ([84.238.125.19]) by mx.google.com with ESMTPS id y54sm56888153eef.10.2012.07.04.13.24.11 (version=SSLv3 cipher=OTHER); Wed, 04 Jul 2012 13:24:12 -0700 (PDT) Message-ID: <4FF4A669.2010306@gmail.com> Date: Wed, 04 Jul 2012 22:24:09 +0200 From: =?UTF-8?B?QWxiaW4gU3RpZ8O2?= User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: user@couchdb.apache.org Subject: Re: Cryptograhically signed docs... References: <79061073-7E58-4CBC-9DC1-8A98C6811796@sri.com> <0848BFC4-1340-4FF9-A04D-EE6D205A90A0@couchbase.com> <-3046869085809654149@unknownmsgid> <4FF4A4F8.70809@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Key id. --Albin Jan Bot wrote: > But if you don't know the user who signed the document, how are you going > to select the proper key to test against? Would the user specify which key > he used to sign a doc? > > Jan > > On Wed, Jul 4, 2012 at 10:18 PM, Albin Stigö wrote: > >> It would, but then you also need to be logged in.. Which I guess sometimes >> is what you want and sometimes not. If you're not logged in the validation >> function doesn't have access to your userCtx. >> >> --Albin >> >> Jan Bot wrote: >>> Hi, >>> >>> Wouldn't it be possible to just store the (public) key of a user within a >>> userdoc (under _users)? >>> >>> Cheers, >>> >>> Jan >>> >>> On Wed, Jul 4, 2012 at 9:31 PM, Bernhard Gschwantner >>> wrote: >>> >>>> 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: >>>> >>>> public_keys >>>> Alice.json: ...public key as a string... >>>> bob.json: ...bob's key.... >>>> >>>> Should be accessible in the validate function like this: >>>> >>>> var keys = this.public_keys; >>>> keys.forEach(function(key){...}) >>>> >>>> I'm on the iPad, so also a bit brief... ;-) >>>> >>>> Bernhard >>>> >>>> -- >>>> >>>> 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 >>>> web: www.unserwein.at >>>> >>>> Am 04.07.2012 um 21:16 schrieb Simon Metson >>> >>>>> : >>>>> 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 >> can >>>> use them over multiple functions). It kind of depends on how much >> turnover >>>> you expect on the keys. >>>>> On Wednesday, 4 July 2012 at 20:11, Albin Stigö wrote: >>>>> >>>>>> 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 (mailto:bernhard@unserwein.at >>>> >>>> )>: >>>>>>> I've been following this thread and like the idea. I may be naïve 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à: 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ö : >>>>>>> >>>>>>>> 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ö < >> albin.stigo@gmail.com >>>> (mailto: >>>> albin.stigo@gmail.com ) >>>>>>>> > >>>>>>>>> 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 >>> (mailto: >>>> 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/thecollector-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 = >>>>>>>>>> openpgp.read_message(doc.digital_signature.signature); >>>>>>>>>>>> for (var i=0; i>>>>>>>>>>> isValid |= 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 — 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. >>>>>>>>>>> —Jens >>>>>>> -- >>>>>>> >>>>>>> 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 (mailto: >>>> bernhard@unserwein.at ) >>>>>>> twitter: @bernharduw >>>>>>> web: www.unserwein.at (http://www.unserwein.at) >>>>>>> >>>>>> >>>> -- >>>> >>>> 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 >>>> web: www.unserwein.at >>>> >