Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 88345 invoked from network); 21 Aug 2010 07:44:36 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 21 Aug 2010 07:44:36 -0000 Received: (qmail 51358 invoked by uid 500); 21 Aug 2010 07:44:35 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 51103 invoked by uid 500); 21 Aug 2010 07:44:33 -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 51093 invoked by uid 99); 21 Aug 2010 07:44:32 -0000 Received: from Unknown (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 21 Aug 2010 07:44:32 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of samuelgoto@gmail.com designates 209.85.216.52 as permitted sender) Received: from [209.85.216.52] (HELO mail-qw0-f52.google.com) (209.85.216.52) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 21 Aug 2010 07:44:10 +0000 Received: by qwj8 with SMTP id 8so5021752qwj.11 for ; Sat, 21 Aug 2010 00:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=JvpdmBa45lS2D0Xn/qCA2hTDuS5lSXZELbVsF1yAxIA=; b=aeTRTsyPpEXR+s9a1SJJTqXLiEsxa6vat40FQ1tlwSEGcLR0id63LTerVeB7mGVk/H f0//LN3XqxO4s9dQ4qtpeDdkrfOEKs3tAfLdTohD50PDfenpsUoBZEjTseb+tulXpE5R wxpe/VMxDWTgHp7MgR1t2vdzflQAu+9hyBcNA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=e1Ou+C0E3u2fB3jia4OLycJehG0iCA6jfD7gLpG5DDoShWCjMcQinfFTgN0FyEtTDk Pix9otKz35JwFAIwcoY81vhBJ9A8jZPSgv59U0OssQjo59R1aTr07xQZWvWqkSO/i8oT dnlCF/MjQPvgrfHmQYfDFfT3zUpsFe3/DX2gY= MIME-Version: 1.0 Received: by 10.224.46.15 with SMTP id h15mr1712501qaf.53.1282376629701; Sat, 21 Aug 2010 00:43:49 -0700 (PDT) Received: by 10.229.23.196 with HTTP; Sat, 21 Aug 2010 00:43:49 -0700 (PDT) In-Reply-To: <4A87AB54-5076-4A0A-8738-2CBE5CC5EB06@apache.org> References: <305377FE-ACE8-4D67-BB02-8B78BB2B45F8@apache.org> <4A87AB54-5076-4A0A-8738-2CBE5CC5EB06@apache.org> Date: Sat, 21 Aug 2010 00:43:49 -0700 Message-ID: Subject: Re: What are the contents of userCtx in validators ? From: sgoto To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=00151748db027b4d96048e509361 X-Virus-Checked: Checked by ClamAV on apache.org --00151748db027b4d96048e509361 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 20, 2010 at 10:22 PM, J Chris Anderson wrote: > > On Aug 20, 2010, at 9:31 PM, sgoto wrote: > >> > >> Hard part is getting something to sign. I have started this project > here: > >> > >> http://github.com/jchris/canonical-json > >> > >> > > this is a very interesting library @jchris. i'm not sure a canonical > > representation of a json is absolutely necessary, if you are signing > binary > > base64 data for example. > > > > i am interesting in having authentication and authorization to be done > with > > PGP/GPG certificates (to make sure replication works with untrusted > nodes). > > in my mental model of this, you'd not need login or the userCtx to be PGP > aware. You'd simple have a validation function that ensures that the > document is well formed (eg that the signature matches the content). > > that is correct: for documents to be trusted in a p2p environment of untrusted couchdb nodes i can't rely on user login (cookies, oauth, message digests, etc) for master-master replication (or any other setup that requires other nodes to write to my local node). as far as i can understand, validation functions can't change either, unless all previous documents get reapplied the same validation function, or else replication will create a non-backward compatible merging conflict to be resolved. the way i'm trying to solve this problem is having each database have one immutable validation rule: each document needs to be signed by a per-database-constant-public-key or by a PGP certificate signed by that public key (1 level of transitive trust, alla web of trust). does that make sense ? > it would be up to the human to decide if they trust the public key, and > there could be some application level tools to help verify trustworthiness. > (eg, 5 of my friends have signed documents that say they trust this key). > > > how far have you gotten with parsing/extracting/verifying PGP > certificates > > (you seem to be using the same library i am to parse/extract/verify PGP > > certificates > > I haven't made any progress since then (haven't really worked on it). I > think in order for JSON-signing to become useful we'd want to follow the > RFC-track, so that we get interoperable implementations across platforms. > > yeah, i'm trying to decide whether to use GPG messages, but there is almost anything done in javascript for parsing GPG certificates. most of the crypto primitives are available, but parsing the PGP message is somewhat non trivial. there is some work done for CA authorities (which we both know aren't the best solution, but it is right there), http://www9.atwiki.jp/kurushima/pub/jsrsa/sample-rsasign.html which may be a better solution than writing my PKI of my own from scratch like what this is proposing: http://wiki.apache.org/couchdb/SignedDocuments http://github.com/jchris/canonical-json suggestions ? > Chris > > > http://github.com/jchris/canonical-json/tree/master/www.hanewin.net/) ? > > -- f u cn rd ths u cn b a gd prgmr ! --00151748db027b4d96048e509361--