couchdb-user mailing list archives

On Sat, Aug 21, 2010 at 12:43 AM, sgoto <samuelgoto@gmail.com> wrote:
>
>
> 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 ?
>
>
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 !