Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jens@mooseyard.com designates
 208.97.132.202 as permitted sender)
Message-Id: <3BC004F2-6BF3-43BA-94D9-FB8D4E8DEE99@mooseyard.com>
From: Jens Alfke <jens@mooseyard.com>
To: user@couchdb.apache.org
In-Reply-To: <e282921e0903081014v5734608axa203fa7569590445@mail.gmail.com>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Proposal for digital signatures of documents
Date: Sun, 8 Mar 2009 10:48:22 -0700
References: <283A6EDD-6701-4A6A-88AE-8B97E6D11D9E@mooseyard.com>
 <e282921e0903081014v5734608axa203fa7569590445@mail.gmail.com>


On Mar 8, 2009, at 10:14 AM, Chris Anderson wrote:

> I think you'll want to add to the signature field, a list of the
> signed fields. This way _rev can change freely, and intermediate users
> can add new fields, without breaking the signature.

That would be one way to do it. Another is to apply the signature not =20=

to the top-level document itself but to an object nested inside it. =20
The nice thing about this signature schema is that it has a very =20
flexible topology, so you can sign pieces of objects, have multiple =20
signed pieces in an object, etc.

> There are reliable JS md5 and sha1 libs. Will that get you there?

No, unfortunately. Verifying a signature requires re-running the =20
public-key algorithm over the message digest. So this would require an =20=

implementation of RSA or the equivalent.

(RSA is ubiquitous but getting old; apparently elliptic-key systems =20
are gaining favor because they provide more security per bit of key =20
length. I don't know whether they're any less compute-intensive than =20
RSA. I'll do some research and try to find JS impls of any of these.)

=97Jens=