On Sat, Aug 21, 2010 at 12:43 AM, sgoto <[email protected]> wrote:
> > > On Fri, Aug 20, 2010 at 10:22 PM, J Chris Anderson <[email protected]>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 ? > > ah, one more question: does validation functions have access to the binary data of attachments ? how can i make sure that the attachments are also signed ? > 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 ! > -- f u cn rd ths u cn b a gd prgmr !
