Re: [jose] canonical JSON

Tim Bray <tbray@textuality.com> Tue, 19 February 2013 20:50 UTC

Return-Path: <tbray@textuality.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873E121F8901 for <jose@ietfa.amsl.com>; Tue, 19 Feb 2013 12:50:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gz4hH-8TEuA3 for <jose@ietfa.amsl.com>; Tue, 19 Feb 2013 12:50:14 -0800 (PST)
Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 726F521F88FB for <jose@ietf.org>; Tue, 19 Feb 2013 12:50:14 -0800 (PST)
Received: by mail-da0-f44.google.com with SMTP id z20so3146932dae.3 for <jose@ietf.org>; Tue, 19 Feb 2013 12:50:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=mPUBZKDYcyHAKOW76bzz2rIWWfkPuyRZLlwNOMDfHTE=; b=doGVx3satTNaP4yzWtci+GKbMUiIDBqzvX3bIZqr8FgzI8sc9KloqHajQwqhLDU8JZ Rh7dJPPUnCjDYe+RyQ66QdZBYtfs6UyiuO7vK2Lu5Rr4APJW+/fFe1apdkpgN2eocYAp OOoNAJzqOU4xo+OnPjIaQKkSove0RlcTL+vk5UiC+8FaMWkZTv9vK12vrmubdmfF8KpY cB5gaQe6tlvHO4Z1ywELL2hp2fmM1Y22mhocse0nKf37YIdlA2ZSLU0F19fSweRUcCNj qmywsPq86Wim74UMfgjXtapzPgSRSYskbngIxRx3qcFmCcMQqVZ3QBFcRImxhXH7fnXI 72tQ==
MIME-Version: 1.0
X-Received: by 10.66.52.79 with SMTP id r15mr48965154pao.46.1361307014034; Tue, 19 Feb 2013 12:50:14 -0800 (PST)
Received: by 10.66.249.129 with HTTP; Tue, 19 Feb 2013 12:50:13 -0800 (PST)
X-Originating-IP: [172.29.161.33]
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674774DA@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <CAG8k2+4xaAUBPs=Kw-=eBHZNyOMs6VYByPEb1jnAv1aGjLupng@mail.gmail.com> <CABkgnnWzdoo6b0ZymF0cv_v9zOjJKTWuUhkWuxiA-cM9qgu0jg@mail.gmail.com> <CAG8k2+47GQXHhWBdqd82UEAPZUfAigYE-vwxpaMJm4F5i8098A@mail.gmail.com> <CAL02cgQ3Oh1D9qHW7XWAZqzmfnE5T6-FjNydjpMEMhaHf2d7Xw@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1150757902D@WSMSG3153V.srv.dir.telstra.com> <CAG8k2+5mVYJ6TgQHJ9juXEaWkfMteG6gV8w_dCoShP4-9fPqMA@mail.gmail.com> <CAL02cgRZkf8rR=gAuR6ZT61WCah3aWQNAq8d+GLWweehH7jN6A@mail.gmail.com> <BF7E36B9C495A6468E8EC573603ED9411513E85D@xmb-aln-x11.cisco.com> <4E1F6AAD24975D4BA5B1680429673943674774DA@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Tue, 19 Feb 2013 12:50:13 -0800
Message-ID: <CAHBU6iu3soqk92j3tKpXNErFsgLm6SZ8V30A=Gf7DcbZCYFqkA@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=bcaec543094c0073d804d619fd64
X-Gm-Message-State: ALoCoQnSh0OfDI6BXc1tJu7UTsg3ySSDuHO1mg0zlhLVpmJJCrcIOe5h+NZ1lwPLjVW+0LEKoLG7
Cc: Richard Barnes <rlb@ipv.sx>, Daniel Holth <dholth@gmail.com>, "Manger, James H" <James.H.Manger@team.telstra.com>, jose <jose@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>
Subject: Re: [jose] canonical JSON
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Feb 2013 20:50:15 -0000

My instinct, as the author of a reasonably popular library that generates
canonical XML, is that JSON ought to be quite a bit easier.  But that’s
only interesting if Mike is wrong and there aren’t better alternatives. -T


On Tue, Feb 19, 2013 at 12:48 PM, Mike Jones <Michael.Jones@microsoft.com>wrote;wrote:

> [Repeating this on the correct thread...]
>
> I'm strongly against canonicalization.  The XML canonicalization
> experience was horrible and resulted in more interop bugs than any other
> aspect of XML DSIG, XML ENC, etc.  Let's not repeat the mistakes of our
> elders. ;-)
>
> I also haven't seen a clear use case that canonicalization solves that
> can't be more easily solved another way.
>
>                                 -- Mike
>
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Matt Miller (mamille2)
> Sent: Tuesday, February 19, 2013 12:35 PM
> To: Richard Barnes
> Cc: Daniel Holth; Manger, James H; jose
> Subject: Re: [jose] canonical JSON
>
> I know I'm still reeling from canonicalization (c14n) issues in XML, but I
> can put that aside.  It would be nice to have JWK fingerprinting.
>
> I can see value in each JWK type defining what is canonical; I'm less
> thrilled limiting metadata to a specific place, but could live with that.
>  I can see where excluding metadata can get us in trouble later, but I
> think that would mean having a much more robust c14n approach.
>
> By the way, there is going to be a JSON BoF in Orlando, and c14n seems
> like a good thing to bring up there.
>
>
> - m&m
>
> Matt Miller < mamille2@cisco.com >
> Cisco Systems, Inc.
>
> PS: 42 vs 4.2e0 vs 4.2e1
>
> On Feb 19, 2013, at 7:59 AM, Richard Barnes <rlb@ipv.sx> wrote:
>
> > So your fingerprint algorithm would be something like the following?
> >
> > INPUT: JWK
> > 1. Remove "metadata" fields.  So, for RSA, you would be left with
> > {"kty", "n", "e"} 2. Convert stripped JWK to canonical form 3. Compute
> > digest over canonical form
> >
> > That seems generally agreeable to me.
> >
> > For (1) to be possible, you would need to define which fields are
> > covered in the fingerprint for each key type ("kty" value).  Or,
> > alternatively, you could restructure JWK so that metadata fields are
> grouped into a "meta"
> > sub-dict.  Which might be nice anyway.
> >
> > For (2), I agree that there is probably a better canonicalization than
> > CJSON.  The code I pasted earlier implements the following changes
> > from RFC
> > 4627:
> > -- Object fields must be in lexicographic order, sorted by field name
> > -- No white space allowed
> > -- Numbers: Exponent part must use 'e'
> > -- Numbers: Exponent part must not use '+'
> > -- Numbers: Fraction part must not have trailing zeros
> > -- Strings: All characters must be escaped ISTM that those changes are
> > fairly minimal, and avoid some of the CJSON problems that have been
> > discussed above. Reasonably people can disagree over the string
> > aspect; if you want less expansion, you could do things like exempt
> > printable ASCII.
> >
> >
> >
> >
> > On Tue, Feb 19, 2013 at 8:56 AM, Daniel Holth <dholth@gmail.com> wrote:
> >
> >> On Tue, Feb 19, 2013 at 1:57 AM, Manger, James H <
> >> James.H.Manger@team.telstra.com> wrote:
> >>
> >>> A canonical form of JSON might be fairly easy, but the one you quote
> >>> (
> >>> http://wiki.laptop.org/go/Canonical_JSON) can't handle floating
> >>> point numbers (or very large integers), and produces invalid JSON if
> >>> a string includes a tab! Fix those (escaping control chars
> >>> [\u0000-\u001f]; use normalized scientific notation for numbers) and
> >>> it might be worth
> >>> considering.****
> >>>
> >>> ** **
> >>>
> >>> Defining JOSE calculations in terms of 1 or more byte arrays, the
> >>> first of which is a UTF-8-encoded JSON header, would be useful. It
> >>> can then be packaged as dot-separated base64url-encoded segments to
> >>> be HTTP-header-friendly, or packaged as a single JSON object to be
> >>> programmer-friendly, or packaged as raw bytes to be efficient.
> >>>
> >>
> >> I am only proposing a key fingerprinting specification that does not
> >> employ DER encoding. JWKs do not contain tabs or floating point numbers.
> >>
> > _______________________________________________
> > jose mailing list
> > jose@ietf.org
> > https://www.ietf.org/mailman/listinfo/jose
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>