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