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 84509DF96 for ; Wed, 4 Jul 2012 18:43:35 +0000 (UTC) Received: (qmail 35075 invoked by uid 500); 4 Jul 2012 18:43:34 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 35042 invoked by uid 500); 4 Jul 2012 18:43:34 -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 35030 invoked by uid 99); 4 Jul 2012 18:43:34 -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 18:43:34 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FSL_RCVD_USER,HTML_MESSAGE,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 209.85.161.180 as permitted sender) Received: from [209.85.161.180] (HELO mail-gg0-f180.google.com) (209.85.161.180) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jul 2012 18:43:27 +0000 Received: by ggnf1 with SMTP id f1so7297591ggn.11 for ; Wed, 04 Jul 2012 11:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=57fQ4whvc9qnw901JBGJm9ievlwZm7mGd5+kmxJ7v6w=; b=gooXJ+klOEOWCN0cy0b2eZQDnmMOaEtcWhbeOq+HNLfYpKLGxgb+4Dl1aDFf1AgjNs XxSGwUSkmnpMGbVg8zS+fc81l1K0DyOqFm3ATTt7r9qjyG8RW5lvmBqzjHV908SmlArF vY7HKreaHgI/3sK/ytPx7XGY4HhWLWlLGlgmzA3IgntNz4vHPOCW3dSe7GIqozCbbLBo 6MfvPNHiGzdXlM5UJ9JwynpqVN7OVXfjZmjFZtgwKGX0dqHrbTPMhGiZnkcpLB6Psp+W TlngeMZN1qEMHYDwdofeDag6q0ZYmDNuz6MrhgOXZjMMSIhQ1gJ5TFbVqK+YFt1MyiXx VHjw== MIME-Version: 1.0 Received: by 10.236.201.195 with SMTP id b43mr6876840yho.27.1341427387140; Wed, 04 Jul 2012 11:43:07 -0700 (PDT) Received: by 10.236.216.40 with HTTP; Wed, 4 Jul 2012 11:43:07 -0700 (PDT) In-Reply-To: References: <79061073-7E58-4CBC-9DC1-8A98C6811796@sri.com> <0848BFC4-1340-4FF9-A04D-EE6D205A90A0@couchbase.com> Date: Wed, 4 Jul 2012 20:43:07 +0200 Message-ID: Subject: Re: Cryptograhically signed docs... From: =?ISO-8859-1?Q?Albin_Stig=F6?= To: "user@couchdb.apache.org" Content-Type: multipart/alternative; boundary=20cf305e2425e70a9904c405668f --20cf305e2425e70a9904c405668f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 ke= y > and check it server side with the public key could really make couchdb pa= rt > of the grid infrastructure. > > Cheers, > > Jan > > On Wed, Jul 4, 2012 at 11:17 AM, Albin Stig=F6 > > 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 > > wrote: > > > > > > On Jul 3, 2012, at 10:01 AM, Jim Klo wrote: > > > > > >> Yes, and as a matter of fact, i just got digital signature validatio= n > > 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 > >> isValid |=3D msg_list[i].verifySignature(); > > >> } > > > > > > It looks like msg_list is the actual document payload, which has to b= e > > 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 signatur= e. > > It's even possible to have multiple signatures on a document. > > > > > > =97Jens > > > --20cf305e2425e70a9904c405668f--