IETF Logo Mail Archive

Re: [Json] Canonicalization

Francis Galiegue <fgaliegue@gmail.com> Wed, 20 February 2013 01:39 UTC

Return-Path: <fgaliegue@gmail.com>
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 475F321F882A for <json@ietfa.amsl.com>; Tue, 19 Feb 2013 17:39:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.508
X-Spam-Level:
X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 8GPDMrQx3sG6 for <json@ietfa.amsl.com>; Tue, 19 Feb 2013 17:39:43 -0800 (PST)
Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 62A2D21F8815 for <json@ietf.org>; Tue, 19 Feb 2013 17:39:43 -0800 (PST)
Received: by mail-ee0-f45.google.com with SMTP id b57so3763659eek.18 for <json@ietf.org>; Tue, 19 Feb 2013 17:39:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TsjKDpruKzLjz25qiuyCcc1sTe/urTXOdqndZowQ7zw=; b=eQryFMQWKxjIVPxAVdM+6CHdaVV5/Lcjben+nBdch1c2EJiF5bsMtiFEsY9+gkKzCi /YDkWNUxdcuxTHYL05qDUMOq4xSLVHBiB6lk5GpR7a6jDpmHkBOeBseNB3+k3TCr2iL8 1vE180BLI6zKymzKvrNG7epvgnD/J6xBwdQVAkwDCgPWstqSExHVznJ4rnFratVwAqNB 4C5f+0dgmwcKy81wb0RAfU2sZGYFHRol5mONTh3VU9iPj7CuXofQw1Wl/4UUSxPPBC4S f3vPcXLWOVlzQqKiVIOFxMna6zP8BvCc9IkKgInd6v2jmEgURPsFrowd/k8RGtrbzbas ZvQg==
MIME-Version: 1.0
X-Received: by 10.14.175.129 with SMTP id z1mr63606339eel.7.1361324382465; Tue, 19 Feb 2013 17:39:42 -0800 (PST)
Received: by 10.14.1.7 with HTTP; Tue, 19 Feb 2013 17:39:42 -0800 (PST)
In-Reply-To: <1361323974.9790.41.camel@pbryan-wsl.internal.salesforce.com>
References: <BF7E36B9C495A6468E8EC573603ED9411513E818@xmb-aln-x11.cisco.com> <A723FC6ECC552A4D8C8249D9E07425A70F897263@xmb-rcd-x10.cisco.com> <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> <CAK3OfOhkSdi_4kuM3SG2N=bcfAwE-3E9+_SWW8ULSfedO8HAkQ@mail.gmail.com> <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> <CALcybBDfyDGh-Gt9v-94OBM7XFzzSwywZJW_fECuig6hrN0cCw@mail.gmail.com> <1361323974.9790.41.camel@pbryan-wsl.internal.salesforce.com>
Date: Wed, 20 Feb 2013 02:39:42 +0100
Message-ID: <CALcybBAkJg1JyMwPc-xsCv_GvROPE696-4ak8YqaO2vXcQ+QHA@mail.gmail.com>
From: Francis Galiegue <fgaliegue@gmail.com>
To: "Paul C. Bryan" <pbryan@anode.ca>
Content-Type: text/plain; charset="UTF-8"
Cc: 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 01:39:44 -0000

On Wed, Feb 20, 2013 at 2:32 AM, Paul C. Bryan <pbryan@anode.ca> wrote:
> Because in some cases, there's no guarantee that the JSON value being
> verified will be transmitted identically as an octet-string.

Given the amount of discussion generated by this topic alone, it seems
that these "some cases" are more than "some". What would be such a
case?

> Canonicalization, in theory, allows it to be represented during signature
> verification the same way it was when it was originally signed. I've seen
> some (ugly) ways of working around this by base64-encoding the entire JSON
> value and putting it in a JSON string.

Ick. OK, well, the answer seems pretty simple: UTF-8. It is already
recommended, I guess making is a MUST in RFC 4627bis will solve the
issue without even the need for c14n...

Nothing to lose, everything to gain.

-- 
Francis Galiegue, fgaliegue@gmail.com
Try out your JSON Schemas: http://json-schema-validator.herokuapp.com

v2.23.0 | Report a Bug | By Email