From user-return-21461-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Jul 5 17:51:14 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 05442DD12 for ; Thu, 5 Jul 2012 17:51:14 +0000 (UTC) Received: (qmail 89425 invoked by uid 500); 5 Jul 2012 17:51:12 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 89391 invoked by uid 500); 5 Jul 2012 17:51:12 -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 89381 invoked by uid 99); 5 Jul 2012 17:51:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jul 2012 17:51:12 +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 (athena.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; Thu, 05 Jul 2012 17:51:07 +0000 Received: by eeke53 with SMTP id e53so3292777eek.11 for ; Thu, 05 Jul 2012 10:50:46 -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:x-enigmail-version:content-type :content-transfer-encoding; bh=04OQzMIMZcylD2INj5AJ9CDF4QGEm7SX45bqEvW8nL0=; b=JCAar0fH/6cBY0XbQCmUX1VOr57DVKRXzTcoQQBrJQw6KxnszbeYH/Of/Qz21myUZO 8yPU3gFy1tEovKGJF5QtHakiIvSTiMSiZbZgRopsFw0rCaBI6OszcGiZd1rQeBX6YstS eVf5o3DCxjl/NZN1qkFtOoaUc22em2TB3X8xE94O+8zm7TQ4KrNu3Ure65cvZhlHkIkA fjOFDXAvetqsT0+RJa//q+Vz7P/CDtmx4CCdR4U9yRITBwbgzAjYoMYt1OfOwKa1OGe2 iCJaAkPdod6kEgHzGp6xiXrnT/AwzZFnFk84zJO2MamMTXUsrXUrURM6RLT6sbV7ZsiD DQSA== Received: by 10.14.101.138 with SMTP id b10mr6588157eeg.56.1341510645736; Thu, 05 Jul 2012 10:50:45 -0700 (PDT) Received: from [192.168.1.115] ([84.238.125.19]) by mx.google.com with ESMTPS id a16sm64889857eeg.0.2012.07.05.10.50.44 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 10:50:44 -0700 (PDT) Message-ID: <4FF5D3F2.1040205@gmail.com> Date: Thu, 05 Jul 2012 19:50:42 +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> In-Reply-To: X-Enigmail-Version: 1.2.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I had completely forgotten it's possible to write validation functions in Erlang.. That's an interesting way of doing it, also taking advantage of the faster and cleaner crypto primitives.. Why not the same database? - --Albin Jens Alfke wrote: > On Jul 4, 2012, at 2:17 AM, Albin Stigö wrote: > >> Jens, thanks for the link. Did you ever finish the app where you >> were using these techniques? > No, it's just experimental so far. It's a personal interest, and also > Couchbase has some potential future customers who would be interested > in such capabilities, so I think it's useful to do a bit of R&D on it > in advance. I'd be glad to share the code. > >> What you are suggesting using a canonical representation of of >> JSON seems like a much better idea it also apparently what oauth >> uses. > I don't know that much about OAuth, but it apparently signs HTTP > request headers using canonicalization. > > I stole most of my ideas from SDSI/SPKI, it's just that they used > S-expressions while I use JSON. Rivest & Lampson's original SDSI > spec[1] is highly recommended reading, for the clear way in which > they rethought certificates from the ground up without all the nasty > historical grunge of X.509 and ASN.1. They also did away with the > naïve assumption of a global hierarchical public key > infrastructure[2] that still plagues X.509. > >> 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. > I agree that some extension will probably be needed for the general > case. Validating a signed document will require access to information > about the principal who owns the signing key, which as I said earlier > is not necessarily the same as the principal uploading the document. > > It may be that CouchDB itself doesn't have to be modified; since the > validation function would probably be written in Erlang (to access > the fast Erlang crypto primitives) it's not sandboxed the way a JS > function is, so it could access an external key-to-principal mapping > (as long as that wasn't stored in the same database.) > > —Jens > > [1] http://people.csail.mit.edu/rivest/sdsi11.html [2] > http://world.std.com/~cme/html/spki.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP9dPyAAoJELPYzeGWa4+lUpkIANgwY0iVmB7++4o8wJy2YZ3L 6rsN7mxTJ4tDzx1cbICIbNug7bZDm0z7KauWm0Wy70suKj5GsBPdNvwRD3NQaG+J IzVD1PRvnkp3Nxpp+xj1DH4DWfngIRC0i7FzY3RttQsAhdm9h5GVRhpTRaUz5ft9 afHTHEOvxCleexoUT98EIosM3/F/qdRfPtwezeMSnkxyZ9s7WinukQqP63StU9Tl ip5qSEDykcGF2eUqsZ9ODd3hXriJb2WCmH7u1GVkfxT5yL5wBd3+99Nf+2qqZAFB OffJivapl2py7zhQe5b3U+bcMbtQhl1uGQlx2X5xtAm6jNStK40AXKBmz6+fl+c= =dQWj -----END PGP SIGNATURE-----