Re: [jose] canonical JSON
Richard Barnes <rlb@ipv.sx> Thu, 21 February 2013 17:47 UTC
Return-Path: <rlb@ipv.sx>
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 CFB9E21F8EBC for <jose@ietfa.amsl.com>; Thu, 21 Feb 2013 09:47:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.733
X-Spam-Level:
X-Spam-Status: No, score=-2.733 tagged_above=-999 required=5 tests=[AWL=0.243, 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 ozRl3CNcd9gz for <jose@ietfa.amsl.com>; Thu, 21 Feb 2013 09:47:19 -0800 (PST)
Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5BF21F8F57 for <jose@ietf.org>; Thu, 21 Feb 2013 09:47:19 -0800 (PST)
Received: by mail-ob0-f170.google.com with SMTP id wc20so9130088obb.1 for <jose@ietf.org>; Thu, 21 Feb 2013 09:47:18 -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=2k1Jg59QywB59BLLAbZhCWvpWKyjQ0WvRJXfrmpQzg8=; b=o1ayyWC0Z6k1ExWngz03WSd3uOmCB/dQfdx21T3sI+NLSujaWio3OdjOCgXHf+XFzl PFOkEU/lyBIAiFgputkPhXwRr9zfwjIwQBX2TniZPtkbRGGZsY6US5CVklT4ITJKMtJO xPYYRImdngWxIdiEI+YEl8LrTri5kgGTaDJ1tv88Uhr2FSLz93Dumzim9LBiqFG10A+A hPSOgu3Osej7Y3rcWi6jkXRF+l3h8dLQl855ihvxxv37vIG0xbShhpLvwGN/9NNwwcvx TQECSUtNLT/ReDzUsoNIVaJnn7sbodcbil2OJ+OcE27VxXYlMWx7+V0DYJaoZZrrSHix zzsg==
MIME-Version: 1.0
X-Received: by 10.60.12.41 with SMTP id v9mr3001871oeb.75.1361468838738; Thu, 21 Feb 2013 09:47:18 -0800 (PST)
Received: by 10.60.60.98 with HTTP; Thu, 21 Feb 2013 09:47:18 -0800 (PST)
X-Originating-IP: [192.1.51.63]
In-Reply-To: <CE8995AB5D178F44A2154F5C9A97CAF40255110B3B4D@HE111541.emea1.cds.t-internal.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> <CAHBU6iu3soqk92j3tKpXNErFsgLm6SZ8V30A=Gf7DcbZCYFqkA@mail.gmail.com> <CE8995AB5D178F44A2154F5C9A97CAF40255110B3B4D@HE111541.emea1.cds.t-internal.com>
Date: Thu, 21 Feb 2013 12:47:18 -0500
Message-ID: <CAL02cgRo-OMu6vw5ugsrg86MCjtmGh_239yAKbH6_6TtF2O82Q@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Axel.Nennker@telekom.de
Content-Type: multipart/alternative; boundary="e89a8ff255d4817b4204d63faad4"
X-Gm-Message-State: ALoCoQmDRYV7a3svXnoDbisoS8SY6QlWRWJ+o+N67sFArQlIY1T7d3QaRX643XDBaiQJxRj5YJ/b
Cc: Daniel Holth <dholth@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, tbray@textuality.com, "jose@ietf.org" <jose@ietf.org>, Matthew Miller <mamille2@cisco.com>, James Manger <James.H.Manger@team.telstra.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: Thu, 21 Feb 2013 17:47:20 -0000
Axel, This comment is not very helpful without a technical argument. --Richard On Wed, Feb 20, 2013 at 1:07 AM, <Axel.Nennker@telekom.de> wrote: > Mike is right. Canonicalization is “evil”.**** > > Axel**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Tim Bray > *Sent:* Tuesday, February 19, 2013 9:50 PM > *To:* Mike Jones > *Cc:* Richard Barnes; Daniel Holth; Manger, James H; jose; Matt Miller > (mamille2) > > *Subject:* Re: [jose] canonical JSON**** > > ** ** > > 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:**** > > [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**** > > ** ** >
- [jose] JWK-specific key fingerprints? Daniel Holth
- Re: [jose] JWK-specific key fingerprints? Stephen Farrell
- Re: [jose] JWK-specific key fingerprints? Martin Thomson
- Re: [jose] JWK-specific key fingerprints? Daniel Holth
- Re: [jose] JWK-specific key fingerprints? Richard Barnes
- Re: [jose] JWK-specific key fingerprints? Daniel Holth
- Re: [jose] canonical JSON Manger, James H
- Re: [jose] canonical JSON Daniel Holth
- Re: [jose] canonical JSON Richard Barnes
- Re: [jose] canonical JSON Matt Miller (mamille2)
- Re: [jose] canonical JSON Mike Jones
- Re: [jose] canonical JSON Tim Bray
- Re: [jose] canonical JSON David Waite
- Re: [jose] canonical JSON John Bradley
- Re: [jose] canonical JSON Mike Jones
- Re: [jose] canonical JSON Justin Richer
- Re: [jose] canonical JSON Mike Jones
- Re: [jose] canonical JSON Axel.Nennker
- Re: [jose] canonical JSON Richard Barnes
- Re: [jose] canonical JSON Richard Barnes
- Re: [jose] canonical JSON Daniel Holth