From user-return-21468-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Fri Jul 6 16:37:37 2012 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6C7A7DAFB for ; Fri, 6 Jul 2012 16:37:37 +0000 (UTC) Received: (qmail 88939 invoked by uid 500); 6 Jul 2012 16:37:35 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 88852 invoked by uid 500); 6 Jul 2012 16:37:35 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 88834 invoked by uid 99); 6 Jul 2012 16:37:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Jul 2012 16:37:35 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jens@couchbase.com designates 206.225.164.29 as permitted sender) Received: from [206.225.164.29] (HELO EXHUB020-2.exch020.serverdata.net) (206.225.164.29) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Jul 2012 16:37:30 +0000 Received: from EXVMBX020-1.exch020.serverdata.net ([169.254.4.9]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Fri, 6 Jul 2012 09:37:09 -0700 From: Jens Alfke To: "user@couchdb.apache.org" Date: Fri, 6 Jul 2012 09:37:08 -0700 Subject: Re: Cryptograhically signed docs... Thread-Topic: Cryptograhically signed docs... Thread-Index: Ac1blZXTP52iAXS6RY+2AYAVDQ6f0A== Message-ID: References: <79061073-7E58-4CBC-9DC1-8A98C6811796@sri.com> <0848BFC4-1340-4FF9-A04D-EE6D205A90A0@couchbase.com> <7149BF67-2B75-4687-868C-47F8811ED26A@sri.com> In-Reply-To: <7149BF67-2B75-4687-868C-47F8811ED26A@sri.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org On Jul 5, 2012, at 9:31 AM, Jim Klo wrote: > That's one area where I think your proposal is lacking is that there's no= t really a method to exclude fields from the signature except via underscor= e fields. The key thing to note is we had a document model before object si= gning requirement; so we had to design a signature solution that was additi= ve in order to not change object model field names for risk of blowing back= wards compatibility. It's definitely possible to do this, at the cost of complicating the spec. = Two possibilities: (a) Add optional (mutually exclusive) 'include' and 'exclude' properties of= the 'signature' property; they would contain arrays of strings naming top-= level properties. If 'include' is present, only the named properties are si= gned; if 'exclude', the named properties are not signed. or (b) Allow the 'signature' property to appear below the top level of a docum= ent. If it's in a nested object, the signature applies only to that object.= (This is nice in that it allows multiple signed objects to be combined in = a document; but it requires validation to search recursively through the wh= ole document for 'signature' properties.) > If you haven't been following IETF's JOSE, you should take a look at it h= ttp://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/?include_= text=3D1 It's not very CouchDB friendly I looked at it briefly; it seems pretty lame. The major flaw is that it doe= sn't specify how to canonicalize JSON, so it's really only useful for signi= ng strings. (Of course you can encode the JSON as a string, but then it's '= dead' and not part of the document. This may be what you mean by 'not very = CouchDB friendly'.) The other weird thing I noticed is that they insist on = base64 encoding data before signing it, which is totally pointless and make= s me wonder how much these people understand about cryptography. > FWIW canonical JSON is very difficult to make portable (ordered maps aren= 't supported across many languages) You just need to define an ordering for the keys in a dictionary, as I did.= Then you write a simple JSON encoder that sorts the keys before writing th= em out. =97Jens=