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
