Re: [Json] Canonicalization

"Paul C. Bryan" <pbryan@anode.ca> Wed, 20 February 2013 03:21 UTC

Return-Path: <pbryan@anode.ca>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CFF21F8901 for <json@ietfa.amsl.com>; Tue, 19 Feb 2013 19:21:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CryGHtqBUSHx for <json@ietfa.amsl.com>; Tue, 19 Feb 2013 19:21:42 -0800 (PST)
Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 45ECC21F88B9 for <json@ietf.org>; Tue, 19 Feb 2013 19:21:42 -0800 (PST)
Received: from [10.216.41.33] (unknown [199.119.234.213]) by maple.anode.ca (Postfix) with ESMTPSA id 300706174; Wed, 20 Feb 2013 03:21:40 +0000 (UTC)
Date: Tue, 19 Feb 2013 19:21:34 -0800
Message-ID: <fa2gnjyy06b79yjgpt7531ot.1361330494445@email.android.com>
From: "Paul C. Bryan" <pbryan@anode.ca>
To: Tim Bray <tbray@textuality.com>, Nico Williams <nico@cryptonector.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Cc: Francis Galiegue <fgaliegue@gmail.com>, Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Canonicalization
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2013 03:21:42 -0000

+1

Tim Bray <tbray@textuality.com> wrote:

>OK, this discussion has convinced me that there’s no real need for this
>group to proactively take up JSON c14n.  If at some future point there’s a
>strong demonstrated real (not hypothetical) use case, it’s a fairly
>tractable problem.  But for now, it’s unnecessary work.
>
>-T
>
>
>On Tue, Feb 19, 2013 at 7:11 PM, Nico Williams <nico@cryptonector.com>wrote:
>
>> On Tue, Feb 19, 2013 at 9:00 PM, Francis Galiegue <fgaliegue@gmail.com>
>> wrote:
>> > On Wed, Feb 20, 2013 at 3:36 AM, Nico Williams <nico@cryptonector.com>
>> wrote:
>> > [...]
>> >>
>> >> Yes and no.  If the verifier and the signer both have the same
>> >> document then no c14n is needed.  If the verifier must reconstruct the
>> >> signed document -as opposed to receiving it from the signer- then the
>> >> verifier must reconstruct exactly the signed document or the signature
>> >> will not verify.
>> >>
>> >
>> > There is one thing I don't get: in any case, what is transmitted over
>> > the network is just a stream of bytes. One end writes that stream, the
>> > other reads it.
>>
>> No, in this one case the two ends construct some data.  A good example
>> would be channel bindings (RFCs 5056, 5929), except that mostly that
>> has no structure, so it's not really a good example after all, but it
>> illustrates the point.
>>
>> > In order for the receiving end to interpret that data, should signing
>> > be used, it needs to verify that the _byte stream_, not its
>> > interpretation, is correct. That byte stream MAY be JSON. It may not
>> > be.
>>
>> That's just it: in this case the data isn't transmitted, only the
>> signature.  There's many protocols that transmit signatures (or
>> hashes) but not necessarily contents.  E.g., rsync.  What if you had a
>> JSON-based synchronization protocol and you're sending file metadata,
>> only there's a lot of it (e.g., large ACLs), and you're trying to
>> avoid sending it, so you send file names and metadata hashes, and if
>> the receiver's don't match then you send the actual metadata?
>>
>> Nico
>> --
>> _______________________________________________
>> json mailing list
>> json@ietf.org
>> https://www.ietf.org/mailman/listinfo/json
>>