Re: [jose] canonical JSON

Richard Barnes <rlb@ipv.sx> Thu, 21 February 2013 17:50 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 BF3CB21F8EEC for <jose@ietfa.amsl.com>; Thu, 21 Feb 2013 09:50:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.746
X-Spam-Level:
X-Spam-Status: No, score=-2.746 tagged_above=-999 required=5 tests=[AWL=0.230, 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 xrKF2GEPzifV for <jose@ietfa.amsl.com>; Thu, 21 Feb 2013 09:50:37 -0800 (PST)
Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id BB5A821F8EC3 for <jose@ietf.org>; Thu, 21 Feb 2013 09:50:31 -0800 (PST)
Received: by mail-oa0-f46.google.com with SMTP id k1so9538222oag.33 for <jose@ietf.org>; Thu, 21 Feb 2013 09:50:30 -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=peVHAtCwFQhtPCPtBH+6yv6MVSqBsM2dyXpAEwIJrRU=; b=ODJPa0/VvOw5PbAF9Ox30fC63JNaKF9b2B0KA2zjUffKvXl94i3Ockvlyn3q+01akY 7HTeFP6lj90qLpaVJeveeodncAVQIaR0iYS+vtnrqJ9CYAg8Fo2/zeHMikb+HSWwAy2n uFz4gNxD06dpVKqYXIDIBu2Fxt1QXOVKAZ948rNxyR4EqYVZpUc0K8Qes/oLxxGGqHxf B42xDuotJz99I6D/8AGN09EinLQZH5PxB6qbHJZAcXwuqTIBr08H+LOLuyAgqmJkCu6t RZUpcESEAcEZm47FPDbiWmGKhKMduz6ZAkuCHl0WZ68HHwZl5RyTV0vwBY0FavgNMt2Z UbkQ==
MIME-Version: 1.0
X-Received: by 10.60.11.168 with SMTP id r8mr837061oeb.136.1361469030000; Thu, 21 Feb 2013 09:50:30 -0800 (PST)
Received: by 10.60.60.98 with HTTP; Thu, 21 Feb 2013 09:50:29 -0800 (PST)
X-Originating-IP: [192.1.51.63]
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367477DB7@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> <7E415CBD-BA54-4E6A-8D16-2CE52C407260@ve7jtb.com> <4E1F6AAD24975D4BA5B1680429673943674777ED@TK5EX14MBXC284.redmond.corp.microsoft.com> <5123FF72.9060206@mitre.org> <4E1F6AAD24975D4BA5B168042967394367477DB7@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Thu, 21 Feb 2013 12:50:29 -0500
Message-ID: <CAL02cgQa438yvHCiWkEJ0xMafWYmTdm46uvEso_OBz2H5PbSHw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary="e89a8fb1f35ae7e9b404d63fb5d9"
X-Gm-Message-State: ALoCoQlnmoFR6ZQJHLdCzshW0NnPLTuypn60elH5R6sZNzGAVL+2JOgGq8hS15KAXRJJOGAoNQss
Cc: Daniel Holth <dholth@gmail.com>, jose <jose@ietf.org>, "Matt Miller (mamille2)" <mamille2@cisco.com>, John Bradley <ve7jtb@ve7jtb.com>, "Manger, James H" <James.H.Manger@team.telstra.com>, Justin Richer <jricher@mitre.org>
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:50:38 -0000

That doesn't solve the problem.  The point of a fingerprint is to have an
identifier for the key that is shorter than the key itself. So a JWS with a
JWK payload is irrelevant.  Likewise, any solution that requires
base64-encoding is also irrelevant, since you would need to carry the
encoded version along in order to interpret the fingerprint.

--Richard


On Tue, Feb 19, 2013 at 7:15 PM, Mike Jones <Michael.Jones@microsoft.com>wrote:

> Nothing's preventing people from using the JWK as the payload of a JWS if
> you want to sign/MAC it - just like Matt's draft uses it as the payload of
> a JWE.  Problem solved. ;-)
>
>                                 -- Mike
>
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Justin Richer
> Sent: Tuesday, February 19, 2013 2:41 PM
> To: Mike Jones
> Cc: Daniel Holth; Richard Barnes; jose; Matt Miller (mamille2); John
> Bradley; Manger, James H
> Subject: Re: [jose] canonical JSON
>
> Since JWKs are passed around as JSON documents, and
> order/spacing/formatting of JSON documents isn't guaranteed, this approach
> won't work.
>
>   -- Justin
>
> On 02/19/2013 05:19 PM, Mike Jones wrote:
> > A SHA-256 hash of the base64url encoding of the UTF-8 representation of
> JWK seems like a fine fingerprint that requires no canonicalization.
> >
> >                               -- Mike
> >
> > -----Original Message-----
> > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
> > Of John Bradley
> > Sent: Tuesday, February 19, 2013 2:16 PM
> > To: Matt Miller (mamille2)
> > Cc: Richard Barnes; Daniel Holth; Manger, James H; jose
> > Subject: Re: [jose] canonical JSON
> >
> > I suspect that a way to fingerprint a subset of a JWK is what is
> desired.  e.g. probably font want to include "kid" as you may want to use
> the fingerprint for that.
> >
> > I suspect that is possible without trying to come up with a general
> method to canonicallise JSON.
> >
> > One might be to ASN1 encode it:)  No that is crazy speak.
> >
> > I do empathize for the desire to have fingerprints without resorting to
> DER encoding.
> >
> > If we scope the problem down to having a canonical representation for a
> limited set of jwk elements that may be worth pursuing.
> >
> >
> > John  B.
> > On 2013-02-19, at 5:35 PM, "Matt Miller (mamille2)" <mamille2@cisco.com>
> wrote:
> >
> >> 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 mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>