You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@couchdb.apache.org by Albin Stigö <al...@gmail.com> on 2012/07/03 17:53:39 UTC

Cryptograhically signed docs...

Hi,

Did anyone experiment with cryptographically signing docs as a method
of "authentication"..? I was thinking something along these lines:
Instead of using name/password login all posted docs must be signed
with a private key. The server has a list of the public keys that are
allowed to post. If the signature is not correct the validation
function rejects the new/updated doc.

I think this scheme could have many interesting use cases... It might
also be a way of maintaining "ownership" across replication.

Did anyone try this?

--Albin

Re: Cryptograhically signed docs...

Posted by Robert Newson <rn...@apache.org>.

Remember that the erlang view server has no sandbox (an erlang map function can do anything, read/write/delete files, open sockets, etc)

B.

On 5 Jul 2012, at 18:50, Albin Stigö wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I had completely forgotten it's possible to write validation functions
> in Erlang.. That's an interesting way of doing it, also taking advantage
> of the faster and cleaner crypto primitives..
> 
> Why not the same database?
> 
> - --Albin
> 
> 
> Jens Alfke wrote:
>> On Jul 4, 2012, at 2:17 AM, Albin Stigö wrote:
>> 
>>> Jens, thanks for the link. Did you ever finish the app where you
>>> were using these techniques?
>> No, it's just experimental so far. It's a personal interest, and also
>> Couchbase has some potential future customers who would be interested
>> in such capabilities, so I think it's useful to do a bit of R&D on it
>> in advance. I'd be glad to share the code.
>> 
>>> What you are suggesting using a canonical representation of of
>>> JSON seems like a much better idea it also apparently what oauth
>>> uses.
>> I don't know that much about OAuth, but it apparently signs HTTP
>> request headers using canonicalization.
>> 
>> I stole most of my ideas from SDSI/SPKI, it's just that they used
>> S-expressions while I use JSON. Rivest & Lampson's original SDSI
>> spec[1] is highly recommended reading, for the clear way in which
>> they rethought certificates from the ground up without all the nasty
>> historical grunge of X.509 and ASN.1. They also did away with the
>> naïve assumption of a global hierarchical public key
>> infrastructure[2] that still plagues X.509.
>> 
>>> 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.
>> I agree that some extension will probably be needed for the general
>> case. Validating a signed document will require access to information
>> about the principal who owns the signing key, which as I said earlier
>> is not necessarily the same as the principal uploading the document.
>> 
>> It may be that CouchDB itself doesn't have to be modified; since the
>> validation function would probably be written in Erlang (to access
>> the fast Erlang crypto primitives) it's not sandboxed the way a JS
>> function is, so it could access an external key-to-principal mapping
>> (as long as that wasn't stored in the same database.)
>> 
>> —Jens
>> 
>> [1] http://people.csail.mit.edu/rivest/sdsi11.html [2]
>> http://world.std.com/~cme/html/spki.html
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJP9dPyAAoJELPYzeGWa4+lUpkIANgwY0iVmB7++4o8wJy2YZ3L
> 6rsN7mxTJ4tDzx1cbICIbNug7bZDm0z7KauWm0Wy70suKj5GsBPdNvwRD3NQaG+J
> IzVD1PRvnkp3Nxpp+xj1DH4DWfngIRC0i7FzY3RttQsAhdm9h5GVRhpTRaUz5ft9
> afHTHEOvxCleexoUT98EIosM3/F/qdRfPtwezeMSnkxyZ9s7WinukQqP63StU9Tl
> ip5qSEDykcGF2eUqsZ9ODd3hXriJb2WCmH7u1GVkfxT5yL5wBd3+99Nf+2qqZAFB
> OffJivapl2py7zhQe5b3U+bcMbtQhl1uGQlx2X5xtAm6jNStK40AXKBmz6+fl+c=
> =dQWj
> -----END PGP SIGNATURE-----

Re: Cryptograhically signed docs...

Posted by Albin Stigö <al...@gmail.com>.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I had completely forgotten it's possible to write validation functions
in Erlang.. That's an interesting way of doing it, also taking advantage
of the faster and cleaner crypto primitives..

Why not the same database?

- --Albin


Jens Alfke wrote:
> On Jul 4, 2012, at 2:17 AM, Albin Stigö wrote:
> 
>> Jens, thanks for the link. Did you ever finish the app where you
>> were using these techniques?
> No, it's just experimental so far. It's a personal interest, and also
> Couchbase has some potential future customers who would be interested
> in such capabilities, so I think it's useful to do a bit of R&D on it
> in advance. I'd be glad to share the code.
> 
>> What you are suggesting using a canonical representation of of
>> JSON seems like a much better idea it also apparently what oauth
>> uses.
> I don't know that much about OAuth, but it apparently signs HTTP
> request headers using canonicalization.
> 
> I stole most of my ideas from SDSI/SPKI, it's just that they used
> S-expressions while I use JSON. Rivest & Lampson's original SDSI
> spec[1] is highly recommended reading, for the clear way in which
> they rethought certificates from the ground up without all the nasty
> historical grunge of X.509 and ASN.1. They also did away with the
> naïve assumption of a global hierarchical public key
> infrastructure[2] that still plagues X.509.
> 
>> 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.
> I agree that some extension will probably be needed for the general
> case. Validating a signed document will require access to information
> about the principal who owns the signing key, which as I said earlier
> is not necessarily the same as the principal uploading the document.
> 
> It may be that CouchDB itself doesn't have to be modified; since the
> validation function would probably be written in Erlang (to access
> the fast Erlang crypto primitives) it's not sandboxed the way a JS
> function is, so it could access an external key-to-principal mapping
> (as long as that wasn't stored in the same database.)
> 
> —Jens
> 
> [1] http://people.csail.mit.edu/rivest/sdsi11.html [2]
> http://world.std.com/~cme/html/spki.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP9dPyAAoJELPYzeGWa4+lUpkIANgwY0iVmB7++4o8wJy2YZ3L
6rsN7mxTJ4tDzx1cbICIbNug7bZDm0z7KauWm0Wy70suKj5GsBPdNvwRD3NQaG+J
IzVD1PRvnkp3Nxpp+xj1DH4DWfngIRC0i7FzY3RttQsAhdm9h5GVRhpTRaUz5ft9
afHTHEOvxCleexoUT98EIosM3/F/qdRfPtwezeMSnkxyZ9s7WinukQqP63StU9Tl
ip5qSEDykcGF2eUqsZ9ODd3hXriJb2WCmH7u1GVkfxT5yL5wBd3+99Nf+2qqZAFB
OffJivapl2py7zhQe5b3U+bcMbtQhl1uGQlx2X5xtAm6jNStK40AXKBmz6+fl+c=
=dQWj
-----END PGP SIGNATURE-----

Re: Cryptograhically signed docs...

Posted by Jens Alfke <je...@couchbase.com>.

On Jul 4, 2012, at 2:17 AM, Albin Stigö wrote:

> Jens, thanks for the link. Did you ever finish the app where you were
> using these techniques?

No, it's just experimental so far. It's a personal interest, and also Couchbase has some potential future customers who would be interested in such capabilities, so I think it's useful to do a bit of R&D on it in advance. I'd be glad to share the code.

> What you are suggesting using a canonical representation of of JSON
> seems like a much better idea it also apparently what oauth uses.

I don't know that much about OAuth, but it apparently signs HTTP request headers using canonicalization.

I stole most of my ideas from SDSI/SPKI, it's just that they used S-expressions while I use JSON. Rivest & Lampson's original SDSI spec[1] is highly recommended reading, for the clear way in which they rethought certificates from the ground up without all the nasty historical grunge of X.509 and ASN.1. They also did away with the naïve assumption of a global hierarchical public key infrastructure[2] that still plagues X.509.

> 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.

I agree that some extension will probably be needed for the general case. Validating a signed document will require access to information about the principal who owns the signing key, which as I said earlier is not necessarily the same as the principal uploading the document.

It may be that CouchDB itself doesn't have to be modified; since the validation function would probably be written in Erlang (to access the fast Erlang crypto primitives) it's not sandboxed the way a JS function is, so it could access an external key-to-principal mapping (as long as that wasn't stored in the same database.)

—Jens

[1] http://people.csail.mit.edu/rivest/sdsi11.html
[2] http://world.std.com/~cme/html/spki.html

Re: Cryptograhically signed docs...

Posted by Albin Stigö <al...@gmail.com>.

Key id.

--Albin

Jan Bot wrote:
> But if you don't know the user who signed the document, how are you going
> to select the proper key to test against? Would the user specify which key
> he used to sign a doc?
>
> Jan
>
> On Wed, Jul 4, 2012 at 10:18 PM, Albin Stigö <al...@gmail.com> wrote:
>
>> It would, but then you also need to be logged in.. Which I guess sometimes
>> is what you want and sometimes not. If you're not logged in the validation
>> function doesn't have access to your userCtx.
>>
>> --Albin
>>
>> Jan Bot wrote:
>>> 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
>>> <be...@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
>>>>
>

Re: Cryptograhically signed docs...

Posted by Jens Alfke <je...@couchbase.com>.

On Jul 4, 2012, at 1:21 PM, Jan Bot wrote:

> But if you don't know the user who signed the document, how are you going
> to select the proper key to test against? Would the user specify which key
> he used to sign a doc?

Generally you put the public key itself (possibly wrapped in a certificate) into the document along with the signature.

Note that with signed documents, it becomes almost unimportant who the uploader of the document is. If someone PUTs a signed document to your database, its author is the principal who originally signed it; it doesn't matter who uploaded it. It could be uploaded anonymously and the system wouldn't necessarily lose any security. (This is very useful when designing P2P systems where documents might get routed/replicated to you via someone who's nearby but not necessarily trusted.)

—Jens

Re: Cryptograhically signed docs...

Posted by Jan Bot <ja...@gmail.com>.

But if you don't know the user who signed the document, how are you going
to select the proper key to test against? Would the user specify which key
he used to sign a doc?

Jan

On Wed, Jul 4, 2012 at 10:18 PM, Albin Stigö <al...@gmail.com> wrote:

> It would, but then you also need to be logged in.. Which I guess sometimes
> is what you want and sometimes not. If you're not logged in the validation
> function doesn't have access to your userCtx.
>
> --Albin
>
> Jan Bot wrote:
> > 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
> > <be...@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
> >>
> >
>

Re: Cryptograhically signed docs...

Posted by Albin Stigö <al...@gmail.com>.

It would, but then you also need to be logged in.. Which I guess sometimes is what you want and sometimes not. If you're not logged in the validation function doesn't have access to your userCtx.

--Albin

Jan Bot wrote:
> 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
> <be...@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
>>
>

Re: Cryptograhically signed docs...

Posted by Bernhard Gschwantner <be...@unserwein.at>.

1) The userCtx has nothing to do with the owner of the document (think replication - the user who started the replicatipn is in the userCtx, not the signer of each document)

2) you only get the user's groups in the userCtx, not all properties.

So you can only store the keys directly in the design document.
--

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 
web: www.unserwein.at

Am 04.07.2012 um 22:10 schrieb Jan Bot <ja...@gmail.com>:

> 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
> <be...@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
>>

Re: Cryptograhically signed docs...

Posted by Jan Bot <ja...@gmail.com>.

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
<be...@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
>