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

Benjamin Kaduk <> Fri, 10 July 2020 21:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E80923A09DD for <>; Fri, 10 Jul 2020 14:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JqunXdi_G9hV for <>; Fri, 10 Jul 2020 14:21:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A4D703A09E0 for <>; Fri, 10 Jul 2020 14:21:39 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 06ALLY51014849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jul 2020 17:21:37 -0400
Date: Fri, 10 Jul 2020 14:21:33 -0700
From: Benjamin Kaduk <>
To: Carsten Bormann <>
Cc: "" <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
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: Fri, 10 Jul 2020 21:21:42 -0000

On Fri, Jul 10, 2020 at 10:43:46PM +0200, 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.
> 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. seems pretty clear that the
IESG reviews the work that is being presented for publication on the
Independent Submission stream, which would seem to exclude extensive
consideration of what might be done later that builds upon such work.  I'm
not sure which of the 5 "types of conclusion" from RFC 5742 you are
proposing should have been sent (and why)...