Re: [jose] canonical JSON

Justin Richer <jricher@mitre.org> Tue, 19 February 2013 22:41 UTC

Return-Path: <jricher@mitre.org>
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 AED0A21F89AE for <jose@ietfa.amsl.com>; Tue, 19 Feb 2013 14:41:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level:
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 LJFZYEDQS9ek for <jose@ietfa.amsl.com>; Tue, 19 Feb 2013 14:41:43 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD8C21F89A3 for <jose@ietf.org>; Tue, 19 Feb 2013 14:41:43 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E7C8D5311CD5; Tue, 19 Feb 2013 17:41:42 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BB61A5311CC6; Tue, 19 Feb 2013 17:41:42 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 19 Feb 2013 17:41:42 -0500
Message-ID: <5123FF72.9060206@mitre.org>
Date: Tue, 19 Feb 2013 17:40:50 -0500
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Mike Jones <Michael.Jones@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>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674777ED@TK5EX14MBXC284.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Cc: Daniel Holth <dholth@gmail.com>, Richard Barnes <rlb@ipv.sx>, jose <jose@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, John Bradley <ve7jtb@ve7jtb.com>, "Manger, James H" <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: Tue, 19 Feb 2013 22:41:44 -0000

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