incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bot <janj...@gmail.com>
Subject Re: Cryptograhically signed docs...
Date Wed, 04 Jul 2012 20:10:16 GMT
Hi,

Wouldn't it be possible to just store the (public) key of a user within a
userdoc (under _users)?

Cheers,

Jan

On Wed, Jul 4, 2012 at 9:31 PM, Bernhard Gschwantner
<bernhard@unserwein.at>wrote:

> If you are the only one controlling the keys, a really nice approach for
> managing the keys is with (the original python) couchapp: just store each
> key as a single .json file in a subfolder, and couchapp takes care of
> encoding each key as a property of the design doc. From
> validate_doc_update, you can access the whole design doc via the this
> keyword. So this input:
>
> public_keys
>     Alice.json: ...public key as a string...
>     bob.json: ...bob's key....
>
> Should be accessible in the validate function like this:
>
>    var keys = this.public_keys;
>    keys.forEach(function(key){...})
>
> I'm on the iPad, so also a bit brief... ;-)
>
> Bernhard
>
> --
>
> Bernhard Gschwantner
> Unser Wein G&U OG
> Kirchengasse 13/7, 1070 Wien
>
> mobil: +43 (6991) 971 32 96
> tel: +43 (1) 971 32 95
> e-mail: bernhard@unserwein.at <javascript:;>
> twitter: @bernharduw
> web: www.unserwein.at
>
> Am 04.07.2012 um 21:16 schrieb Simon Metson <simon@cloudant.com
> <javascript:;>
> >:
>
> > You could use CommonJS (http://wiki.apache.org/couchdb/CommonJS_Modules)
> to store the keys, that would make them available to views and validation
> functions, and I think is a bit more efficient than !json (because you can
> use them over multiple functions). It kind of depends on how much turnover
> you expect on the keys.
> >
> >
> > On Wednesday, 4 July 2012 at 20:11, Albin Stigö wrote:
> >
> >> Yes, I agree with you, it can probably be done in JavaScript in a
> >> normal validation function.. The only problem is how to maintain a
> >> list of keys.. For a test version you can just have them stored along
> >> with the code in the validation doc using ie couchapp's !json macro..
> >> But I think it would be really neat with a _keys db..
> >>
> >> Another way of doing it, that I think could be implemented quite
> >> efficiently, is to have a separate worker process listening to changes
> >> stream and have a validation doc that marks all new docs with
> >> "verified: false. The worker process could then change this to true
> >> after it checked the signature. Sorry if I'm a bit brief but I'm
> >> typing this on an iPhone.
> >>
> >> Sendt fra min iPhone
> >>
> >> Den 04/07/2012 kl. 21.00 skrev Bernhard Gschwantner <
> bernhard@unserwein.at <javascript:;> (mailto:bernhard@unserwein.at
> <javascript:;>
> )>:
> >>
> >>> I've been following this thread and like the idea. I may be naïve or
> >>> completely wrong, but all this sounds quite easy to solve in a design
> >>> document and with pure javascript, although probably not very
> performant.
> >>> Just take jens' structure proposal and modify openpgp.js a little bit,
> put
> >>> the stuff into a validate_doc_update function, add the allowed public
> keys
> >>> to a design doc (easy with a couchapp), et voilà: you get a completely
> >>> replicable and transparent signature checker ;-)
> >>>
> >>> If I find the time tomorrow, I'll take a shot on a proof of concept.
> The
> >>> building blocks are there already...
> >>>
> >>> Cheers,
> >>> Bernhard
> >>>
> >>> Am Mittwoch, 4. Juli 2012 schrieb Albin Stigö :
> >>>
> >>>> Sounds interesting.. I think I will take this to the developers
> mailing
> >>>> list and see if I will be able to generate some interest in the idea..
> >>>>
> >>>> Albin
> >>>>
> >>>> onsdag den 4. juli 2012 skrev Jan Bot :
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> This would really be a great feature: I'm using CouchDB to manage
> grid
> >>>>> compute jobs and having the ability to sign a document using a
> private
> >>>>>
> >>>>
> >>>> key
> >>>>> and check it server side with the public key could really make
> couchdb
> >>>>
> >>>> part
> >>>>> of the grid infrastructure.
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Jan
> >>>>>
> >>>>> On Wed, Jul 4, 2012 at 11:17 AM, Albin Stigö <albin.stigo@gmail.com
> <javascript:;>(mailto:
> albin.stigo@gmail.com <javascript:;>)<javascript:;>
> >>>> <javascript:;>>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> Jens, thanks for the link. Did you ever finish the app where
you
> were
> >>>>>> using these techniques?
> >>>>>>
> >>>>>> First I naively thought that it would be enough to hash the
body of
> >>>>>> what you are going to PUT/POST and then sign that hash and include
> the
> >>>>>> signature as a custom http header. I guess this would work for
> >>>>>> verifying the data on the first post but you would not be able
to
> >>>>>> verify the signature later if couchdb does any parsing of the
> >>>>>> transported data.
> >>>>>>
> >>>>>> What you are suggesting using a canonical representation of
of JSON
> >>>>>> seems like a much better idea it also apparently what oauth
uses.
> >>>>>>
> >>>>>> I guess this would require some hacking on couchdb. It would
be
> really
> >>>>>> neat to have a _keys database much like the _users and for for
> >>>>>> documents to have a _signature field. What do you thin..?
> >>>>>>
> >>>>>> --Albin
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Jul 4, 2012 at 3:07 AM, Jens Alfke <jens@couchbase.com
> <javascript:;>(mailto:
> jens@couchbase.com <javascript:;>)<javascript:;>
> >>>> <javascript:;>>
> >>>>> wrote:
> >>>>>>>
> >>>>>>> On Jul 3, 2012, at 10:01 AM, Jim Klo wrote:
> >>>>>>>
> >>>>>>>> Yes, and as a matter of fact, i just got digital signature
> >>>> validation
> >>>>>> using OpenPGP within a map function working a few minutes ago!
> >>>>>>>> Here's a link to the relevant code:
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
>
> https://github.com/jimklo/TheCollector/blob/master/dataservices/thecollector-resources/views/lib/sig_utils.js
> >>>>>>>
> >>>>>>> As far as I can tell, this code uses a data schema where
the signed
> >>>>>> contents are wrapped in some kind of OpenPGP encoding:
> >>>>>>>
> >>>>>>>> var msg_list =
> >>>>>> openpgp.read_message(doc.digital_signature.signature);
> >>>>>>>> for (var i=0; i<msg_list.length; i++) {
> >>>>>>>> isValid |= msg_list[i].verifySignature();
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> It looks like msg_list is the actual document payload, which
has to
> >>>> be
> >>>>>> decoded using openpgp.read_message.
> >>>>>>>
> >>>>>>> This is IMHO not a very good solution because it hides the
document
> >>>>>> contents away — for example, all the map functions and any
app logic
> >>>>>>
> >>>>>
> >>>>
> >>>> that
> >>>>>> uses documents will have to know to call read_message, which
will
> also
> >>>>>
> >>>>> make
> >>>>>> them slower.
> >>>>>>>
> >>>>>>> The schema I implemented (see my previous message) doesn't
alter
> the
> >>>>>> basic document format. The signature is in a nested object but
> applies
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> to
> >>>>>> the entire document contents (minus the signature itself of
course).
> >>>>>> There's no need to change any code that reads documents; the
only
> time
> >>>>>>
> >>>>>
> >>>>> you
> >>>>>> have to know about the signature scheme is while verifying the
> >>>>>
> >>>>>
> >>>>
> >>>> signature.
> >>>>>> It's even possible to have multiple signatures on a document.
> >>>>>>>
> >>>>>>> —Jens
> >>>
> >>>
> >>> --
> >>>
> >>> Bernhard Gschwantner
> >>> Unser Wein G&U OG
> >>> Kirchengasse 13/7, 1070 Wien
> >>>
> >>> mobil: +43 (6991) 971 32 96
> >>> tel: +43 (1) 971 32 95
> >>> e-mail: bernhard@unserwein.at <javascript:;> (mailto:
> bernhard@unserwein.at <javascript:;>)
> >>> twitter: @bernharduw <http://twitter.com/bernharduw>
> >>> web: www.unserwein.at (http://www.unserwein.at)
> >>>
> >>
> >>
> >>
> >
> >
>
>
> --
>
> Bernhard Gschwantner
> Unser Wein G&U OG
> Kirchengasse 13/7, 1070 Wien
>
> mobil: +43 (6991) 971 32 96
> tel: +43 (1) 971 32 95
> e-mail: bernhard@unserwein.at
> twitter: @bernharduw <http://twitter.com/bernharduw>
> web: www.unserwein.at
>

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