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 7A71495F8 for ; Tue, 3 Jul 2012 17:03:08 +0000 (UTC) Received: (qmail 96197 invoked by uid 500); 3 Jul 2012 17:03:06 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 96173 invoked by uid 500); 3 Jul 2012 17:03:06 -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 96163 invoked by uid 99); 3 Jul 2012 17:03:06 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jul 2012 17:03:06 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [128.18.84.132] (HELO brightmail-internal3.sri.com) (128.18.84.132) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jul 2012 17:02:58 +0000 X-AuditID: 80125484-b7f1e6d000001edb-b5-4ff325acd896 Received: from exchange-hub03.SRI.COM (exchange-hub03.SRI.COM [128.18.23.155]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by brightmail-internal3.sri.com (SRI Internal SMTP Gateway) with SMTP id DA.2E.07899.CA523FF4; Tue, 3 Jul 2012 10:02:36 -0700 (PDT) Received: from EXCHANGE-DB08.SRI.COM ([fe80::a11e:7c21:6886:9a20]) by exchange-hub03.SRI.COM ([fe80::8c0e:cf22:fef8:cb20%15]) with mapi id 14.02.0298.004; Tue, 3 Jul 2012 10:01:48 -0700 From: Jim Klo To: "" Subject: Re: Cryptograhically signed docs... Thread-Topic: Cryptograhically signed docs... Thread-Index: AQHNWTP6QRnFgf7rFUiFg2X9Tdl1iZcYPjmA Date: Tue, 3 Jul 2012 17:01:48 +0000 Message-ID: <79061073-7E58-4CBC-9DC1-8A98C6811796@sri.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.12.16.56] Content-Type: multipart/alternative; boundary="_000_790610737E584CBC9DC18A98C6811796sricom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsXSICQ+W3eN6md/g60bJS069+xlc2D02Pjh OGMAYxSXTUpqTmZZapG+XQJXxovmtWwFS3Qqfq2azdjAuEa1i5GTQ0LAROLh88+MELaYxIV7 69m6GLk4hAR2Mkl8+/ybBcLZyyhxZO0qJpAqNgF5icPbHzCD2CIClhK3FnxkAbGFBXQkJm1a xwoR15W49u0JUJwDyDaSOLjXDiTMIqAiceDzTrBlvAJWEt/mN4G1CgkESKx43ANWzikQKLH+ XAVImBHonu+n1oBtZRYQl7j1ZD4TxJ0CEkv2nGeGsEUlXj7+xwphK0gs637MClEfJ/GhaT87 xCpBiZMzn7BMYBSZhWTULCRls5CUQcT1JG5MncIGYWtLLFv4mhnC1pWY8e8QVI2ZxJTDi1HU LGDkWMUok1SUmZ5RkpuYmaMLiyljveKiTL3k/NxNjOA4C2nZwbhil+EhRgEORiUe3kSFz/5C rIllxZW5hxglOJiVRHi5z3zyF+JNSaysSi3Kjy8qzUktPsQozcGiJM4bZszvLySQnliSmp2a WpBaBJNl4uCUamCMPWzU5qW0M+wA/9y/k5iMcoyjXq0XvjHhZ0hGtRmr60m9MznrEuMebJ7d +kS9iqXnRFPl/0e6i9atuqGYrnIx6lOY8MK7P2XP389Z2fVV2u39O/dvkhdcFk+eP0FYbM2m NPe4QwclPnNw5dnve7X5ek2de1DMpo28bys7f6+1cPVoe1WWeidciaU4I9FQi7moOBEAgfHz Oq8CAAA= --_000_790610737E584CBC9DC18A98C6811796sricom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 I'm using my own slightly edited version of the OpenPGP.js (http://openpgpj= s.org/) project library. Essentially all I did was add a CommonJS exports.= openpgp declaration and some mock object declaration (navigator, localStora= ge, etc) The problem you run into however with what you want to do, is you will not = have access to the a user object inside or a userCtx since you're not actua= lly authenticating to pair a valid keyid with. The best you might do is use= a validate update doc function with a fixed set of whitelisted public keys= stored in your design doc. It's not very scalable, but really your only so= lution since you can't break the idempotency to fetch additional external p= ublic keys. Jim Klo Senior Software Engineer Center for Software Engineering SRI International On Jul 3, 2012, at 8:53 AM, Albin Stig=F6 wrote: Hi, Did anyone experiment with cryptographically signing docs as a method of "authentication"..? I was thinking something along these lines: Instead of using name/password login all posted docs must be signed with a private key. The server has a list of the public keys that are allowed to post. If the signature is not correct the validation function rejects the new/updated doc. I think this scheme could have many interesting use cases... It might also be a way of maintaining "ownership" across replication. Did anyone try this? --Albin --_000_790610737E584CBC9DC18A98C6811796sricom_--