couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sgoto <samuelg...@gmail.com>
Subject Re: What are the contents of userCtx in validators ?
Date Sat, 21 Aug 2010 07:43:49 GMT
On Fri, Aug 20, 2010 at 10:22 PM, J Chris Anderson <jchris@apache.org>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<http://github.com/jchris/canonical-json/tree/master/www.hanewin.net/>

suggestions ?


> Chris
>
> > http://github.com/jchris/canonical-json/tree/master/www.hanewin.net/) ?
>
>


-- 
f u cn rd ths u cn b a gd prgmr !

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message