Re: [jose] Beyond RFC 8785 (JSON Canonicalization Scheme)

Anders Rundgren <> Sat, 11 July 2020 13:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3EA93A0EE4 for <>; Sat, 11 Jul 2020 06:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L_0B3_sOHaYz for <>; Sat, 11 Jul 2020 06:10:47 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1BE573A0F21 for <>; Sat, 11 Jul 2020 06:10:47 -0700 (PDT)
Received: by with SMTP id l12so9017329ejn.10 for <>; Sat, 11 Jul 2020 06:10:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TA2yYaLH9qTPM9idBdaKj0sJkPHDQHArLaoQ7duYsw4=; b=CPRXOAHoDixiiCNDDNYSDT4rThBnFxLh2Ti9U9hjeZ+VI480mLSLJoC4nKKfzQ6yqU TmMsZ4L91ybuvVpqcvNfZtTc5TNTDIHAJRmv2o/4bPVJPt6/BGEBBRhv3b0AGHnjNErc lIm1H1Tp5BaDNzffciTpzXcpz3KeUJOD/8iU1+T1T7gaIpCKVZZ2tPBJ7dfnzeIGl252 pcaQQRhcY0cO49sSZ12Qjwn1DaIM0b4IzhJ0NcBlaToUKH22mdRhYDFXIvn2fI8w7dX9 IHIyb2k4bP7wx/2MFcAUJuVYUeVWdG1A68tZuYmvdXrVY006n8yKlDwNuny9pF085rlr zvDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TA2yYaLH9qTPM9idBdaKj0sJkPHDQHArLaoQ7duYsw4=; b=MeDYTAgaPFzixDuAr8e8JSWQpEancjIx/tEMo4Z3xu+gwXonXH0pFJE5rPUP7a/u2f 5HcQBO1fN+gNs/PZzLn41MpT+EDaS3xVln9iK0RF1cnqejQ3nYys1rt/6RZn2Pge/ynW tOVGCyHafcgr4zLw3kpYvfr6+SQjZD/BYsR3Kb3w5COYN+22pdMbJ332xy9FNzPyGoLQ rvkOCVUvdc8MSQaoyp1l5cqq1Xp6qRsX38otvJUpDL3EJSK1cWOB92vUOwv5y0IwzjYM enKaHAxdKapKoQdvBWQqqlA9dV22Fkmo4Dv0Uv9Ee+UhjIoU1ZtlHUoNFEgkZNgaUw9j wa5Q==
X-Gm-Message-State: AOAM532g+r3twVAspzMCisTLh+M3BlFit6U+5mn7O/oLjepLsEx84DxD q/9uWV4daQ51BcGMb/hk8/gZiyWm6mk=
X-Google-Smtp-Source: ABdhPJzVqSgANtvXVv/2WFyADyPBlK7zSjnX01xr2DnEX88pWfs8M+952bf3JjlEgq/Bv34H23rIRw==
X-Received: by 2002:a17:907:94cf:: with SMTP id dn15mr70473929ejc.457.1594473045161; Sat, 11 Jul 2020 06:10:45 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id f10sm6727321edr.69.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Jul 2020 06:10:44 -0700 (PDT)
To: Carsten Bormann <>, Mike Jones <>
Cc: "" <>
References: <> <>
From: Anders Rundgren <>
Message-ID: <>
Date: Sat, 11 Jul 2020 15:10:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [jose] Beyond RFC 8785 (JSON Canonicalization Scheme)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Jul 2020 13:10:49 -0000

On 2020-07-10 22:43, Carsten Bormann wrote:
> On 2020-07-10, at 22:21, Mike Jones <> wrote:
>> There are things I would have commented on in JCS
> Much of what discussion we had happened on the JSON mailing list.
> There is a map (JSON object) key ordering mechanism in there for which I only have the word “sick”, and this was commented on the JSON mailing list [1] (in slightly more elaborate wording).  That “feature” is still in there.  No comment.

Hi Carsten,

The chosen solution may not be "perfect" but it has no proven [1] downsides either unless JSON would be fundamentally revised or the Unicode consortium would suddenly pull the plug on UTF-16.  The chance/risk for that to happen seems minimal.  Therefore JCS simply followed its JavaScript origins.  An additional problem is that there is no consensus what the "right" solution is; some people advocate for UTF-8, while other camps insist that sorting must be based on Unicode.

However, if you stick to best practices for JSON keys, like spelled out in JWK Thumbprint (RFC 7638), it doesn't even matter if you sort on UTF-8, UTF-16, or Unicode!

Could we for fairness sake, take a peek at the existing JOSE standards from a "perfection" point of view?  All "blob" contents are coded in base64url with "x5c" as sole exception.  Although I know why, the (not mentioned) rationale is actually pretty weak.  Calling it "sick" is though taking things way too far since it obviously has no consequences except for JOSE implementers. The "none" algorithm is another non-obvious JOSE ingredient.

A JCS implementation recently published on the JSON list required less than 200 lines of GO code. XML canonicalization including schema support (for dealing with default values) could easily reach 10000 lines.

Anyway, the immediate issue the former JSON members may need to focus on is "Signed HTTP Requests".  I'm there as well :-)  Maybe we meet again at some future IETF!



> The disturbing part is that people are now running ahead and are trying to do run-arounds around the JOSE format based on the old XMLDSig thinking.  I certainly suspected that was the point of JCS, but it plaid no role in the IESG conflict review for this independent submission — I have seen very inconsistent levels of attention in IESG to considerations about how a spec will actually be used over time.
> Grüße, Carsten
> [1]: <>
> _______________________________________________
> jose mailing list