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