Re: [jose] canonical JSON

Richard Barnes <> Tue, 19 February 2013 14:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D934021F8D03 for <>; Tue, 19 Feb 2013 06:59:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q1nxqJyGz01Y for <>; Tue, 19 Feb 2013 06:59:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CDF0E21F8806 for <>; Tue, 19 Feb 2013 06:59:35 -0800 (PST)
Received: by with SMTP id l20so6866728oag.23 for <>; Tue, 19 Feb 2013 06:59:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=SixjOt9ntht6R0GW411BijH/HDK9qBzTuOkggZavRVw=; b=EypucAbLfry7b95AhtUcXWGB14Va6vV43wIVNdT8fD/66gIMoYb+0EWSTIn9dp6f2b GNtr14v5oWLX9ZE00fjJHzLR1LuLds8juACgGQrbrxin45ZzRIJ0WBUasUCpe8PQVRGT vvbbtpTMzdn0X0916Yb3FlQaFpAxup1DJutUcbcxNeE+LyrgkQGyNdi9U0SAI+8caYy9 /n0kARMtWFh2LzTDqV4/uP4ei122gl+uFvqCEEyt8gaxqH8LGO1eZN6Cj0Z6NBMhc9Mu nBLKpLomoz1LdMLkosm+PClM5iu0JDxNYKM893nF+8JrRLLqUqOlWbicce9a7zRUJGQ5 yY8Q==
MIME-Version: 1.0
X-Received: by with SMTP id bf13mr7972620oec.83.1361285975281; Tue, 19 Feb 2013 06:59:35 -0800 (PST)
Received: by with HTTP; Tue, 19 Feb 2013 06:59:35 -0800 (PST)
X-Originating-IP: [2606:4100:3880:2520:9cad:df5f:cf4a:f05c]
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Tue, 19 Feb 2013 09:59:35 -0500
Message-ID: <>
From: Richard Barnes <>
To: Daniel Holth <>
Content-Type: multipart/alternative; boundary=bcaec54b4aa2fe91aa04d61516c4
X-Gm-Message-State: ALoCoQnxAZg46e4mcYRWo4McHKhzHmjhN+RpdF9qfJav2Z7S4h9EfMTOWVgMqzOoeT3P//j2GEQE
Cc: "Manger, James H" <>, jose <>
Subject: Re: [jose] canonical JSON
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Feb 2013 14:59:37 -0000

So your fingerprint algorithm would be something like the following?

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
-- 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 <> wrote:

> On Tue, Feb 19, 2013 at 1:57 AM, Manger, James H <
>> wrote:
>> A canonical form of JSON might be fairly easy, but the one you quote (
>> 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.