You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by sgoto <sa...@gmail.com> on 2010/08/04 05:30:09 UTC
What are the contents of userCtx in validators ?
Hey everyone,
According to this page:
http://books.couchdb.org/relax/design-documents/validation-functions
An administrator could write validation function to ensure the data that
gets written to couchdb is validated. I'm interested in adding some PGP-like
signing of documents for authentication. I'm also interested in md5ing the
contents of the message to ensure integrity, but i'll leave that for later.
This leads me to the following question:
What are the contents of userCtx in the validator's signature ?
function(newDoc, oldDoc, userCtx) {
throw({forbidden : 'no way'});
}
would it be the contents of the authentication database ?
http://wiki.apache.org/couchdb/Security_Features_Overview
http://wiki.apache.org/couchdb/Authentication_and_Authorization
{
"_id" : "org.couchdb.user:joe",
"type" : "user",
"name" : "joe",
"roles" : ["erlanger"],
"password_sha" : "fe95df1ca59a9b567bdca5cbaf8412abd6e06121",
"salt" : "4e170ffeb6f34daecfd814dfb4001a73"
}
any existing work/library/method (eg CA vs web of trust, storing encrypted
documents, signing, integrity, etc) that I should be aware of ?
--
f u cn rd ths u cn b a gd prgmr !
Re: What are the contents of userCtx in validators ?
Posted by Robert Newson <ro...@gmail.com>.
The tweak to expose the md5 of the attachment is easy, but md5 is
broken for this purpose. It's fine to detect corruption, but you
shouldn't sign md5 values any more.
B.
On Sat, Aug 21, 2010 at 6:31 PM, J Chris Anderson <jc...@apache.org> wrote:
>
> On Aug 21, 2010, at 12:45 AM, sgoto wrote:
>
>> On Sat, Aug 21, 2010 at 12:43 AM, sgoto <sa...@gmail.com> wrote:
>>
>>> 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.
>
> yes, validation functions are not retroactive. furthermore, each user is in charge of her own validation functions, so some intermediate nodes may choose not to validate.
>
>>>
>>> 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).
>
> why not just ensure that it is signed by any well-formed key? (in my model each user has a key, and you might input a message on your localhost, that replicates via N hops, to eventually reach my localhost, at which point I know the signature applies cleanly, so all I need to do is decide if I trust the key).
>
>>>
>>> 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 ?
>>
>
> no, attachments are not sent to the JS process. however, there is a ticket out, for including the md5 checksum of the attachment as part of the attachment stub. in that case, the md5 hash could be signed as well.
>
> Chris
Re: What are the contents of userCtx in validators ?
Posted by J Chris Anderson <jc...@apache.org>.
On Aug 21, 2010, at 12:45 AM, sgoto wrote:
> On Sat, Aug 21, 2010 at 12:43 AM, sgoto <sa...@gmail.com> wrote:
>
>> 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.
yes, validation functions are not retroactive. furthermore, each user is in charge of her own validation functions, so some intermediate nodes may choose not to validate.
>>
>> 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).
why not just ensure that it is signed by any well-formed key? (in my model each user has a key, and you might input a message on your localhost, that replicates via N hops, to eventually reach my localhost, at which point I know the signature applies cleanly, so all I need to do is decide if I trust the key).
>>
>> 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 ?
>
no, attachments are not sent to the JS process. however, there is a ticket out, for including the md5 checksum of the attachment as part of the attachment stub. in that case, the md5 hash could be signed as well.
Chris
Re: What are the contents of userCtx in validators ?
Posted by sgoto <sa...@gmail.com>.
On Sat, Aug 21, 2010 at 12:43 AM, sgoto <sa...@gmail.com> wrote:
>
>
> On Fri, Aug 20, 2010 at 10:22 PM, J Chris Anderson <jc...@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 !
Re: What are the contents of userCtx in validators ?
Posted by sgoto <sa...@gmail.com>.
On Fri, Aug 20, 2010 at 10:22 PM, J Chris Anderson <jc...@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 !
Re: What are the contents of userCtx in validators ?
Posted by J Chris Anderson <jc...@apache.org>.
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).
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.
Chris
> http://github.com/jchris/canonical-json/tree/master/www.hanewin.net/) ?
Re: What are the contents of userCtx in validators ?
Posted by sgoto <sa...@gmail.com>.
On Wed, Aug 4, 2010 at 7:01 AM, J Chris Anderson <jc...@apache.org> wrote:
>
> On Aug 3, 2010, at 8:30 PM, sgoto wrote:
>
> > Hey everyone,
> >
> > According to this page:
> >
> > http://books.couchdb.org/relax/design-documents/validation-functions
> >
> > An administrator could write validation function to ensure the data
> that
> > gets written to couchdb is validated. I'm interested in adding some
> PGP-like
> > signing of documents for authentication. I'm also interested in md5ing
> the
> > contents of the message to ensure integrity, but i'll leave that for
> later.
> >
> > This leads me to the following question:
> >
> > What are the contents of userCtx in the validator's signature ?
> >
> > function(newDoc, oldDoc, userCtx) {
> > throw({forbidden : 'no way'});
> > }
> >
>
> the best way to learn this is to do
>
> log(userCtx) inside your function.
>
> the contents of the userCtx are minimal, just name and roles. The idea
> behind this is to make a narrow lowest common denominator so LDAP, kerberos,
> etc can all work with existing apps.
>
> >
> > would it be the contents of the authentication database ?
> >
> > http://wiki.apache.org/couchdb/Security_Features_Overview
> > http://wiki.apache.org/couchdb/Authentication_and_Authorization
> >
> > {
> > "_id" : "org.couchdb.user:joe",
> > "type" : "user",
> > "name" : "joe",
> > "roles" : ["erlanger"],
> > "password_sha" : "fe95df1ca59a9b567bdca5cbaf8412abd6e06121",
> > "salt" : "4e170ffeb6f34daecfd814dfb4001a73"
> > }
> >
> >
> > any existing work/library/method (eg CA vs web of trust, storing
> encrypted
> > documents, signing, integrity, etc) that I should be aware of ?
> >
>
> 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).
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
http://github.com/jchris/canonical-json/tree/master/www.hanewin.net/) ?
> (plz ignore the name)
>
> Chris
>
> > --
> > f u cn rd ths u cn b a gd prgmr !
>
>
--
f u cn rd ths u cn b a gd prgmr !
Re: What are the contents of userCtx in validators ?
Posted by J Chris Anderson <jc...@apache.org>.
On Aug 3, 2010, at 8:30 PM, sgoto wrote:
> Hey everyone,
>
> According to this page:
>
> http://books.couchdb.org/relax/design-documents/validation-functions
>
> An administrator could write validation function to ensure the data that
> gets written to couchdb is validated. I'm interested in adding some PGP-like
> signing of documents for authentication. I'm also interested in md5ing the
> contents of the message to ensure integrity, but i'll leave that for later.
>
> This leads me to the following question:
>
> What are the contents of userCtx in the validator's signature ?
>
> function(newDoc, oldDoc, userCtx) {
> throw({forbidden : 'no way'});
> }
>
the best way to learn this is to do
log(userCtx) inside your function.
the contents of the userCtx are minimal, just name and roles. The idea behind this is to make a narrow lowest common denominator so LDAP, kerberos, etc can all work with existing apps.
>
> would it be the contents of the authentication database ?
>
> http://wiki.apache.org/couchdb/Security_Features_Overview
> http://wiki.apache.org/couchdb/Authentication_and_Authorization
>
> {
> "_id" : "org.couchdb.user:joe",
> "type" : "user",
> "name" : "joe",
> "roles" : ["erlanger"],
> "password_sha" : "fe95df1ca59a9b567bdca5cbaf8412abd6e06121",
> "salt" : "4e170ffeb6f34daecfd814dfb4001a73"
> }
>
>
> any existing work/library/method (eg CA vs web of trust, storing encrypted
> documents, signing, integrity, etc) that I should be aware of ?
>
Hard part is getting something to sign. I have started this project here:
http://github.com/jchris/canonical-json
(plz ignore the name)
Chris
> --
> f u cn rd ths u cn b a gd prgmr !