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

Carsten Bormann <cabo@tzi.org> Fri, 10 July 2020 21:34 UTC

Return-Path: <cabo@tzi.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 93CAA3A0A6E for <jose@ietfa.amsl.com>; Fri, 10 Jul 2020 14:34:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id it-gCtzvSDlV for <jose@ietfa.amsl.com>; Fri, 10 Jul 2020 14:34:52 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9A93A0A73 for <jose@ietf.org>; Fri, 10 Jul 2020 14:34:52 -0700 (PDT)
Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B3RCF25PMzyWh; Fri, 10 Jul 2020 23:34:49 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20200710212133.GA16335@kduck.mit.edu>
Date: Fri, 10 Jul 2020 23:34:48 +0200
Cc: "jose@ietf.org" <jose@ietf.org>
X-Mao-Original-Outgoing-Id: 616109688.3934391-9167ce34334cd3696bc93da231be7048
Content-Transfer-Encoding: quoted-printable
Message-Id: <40A9B27A-40E9-4FDF-848C-3A52240DAC30@tzi.org>
References: <MN2PR00MB06880AA5E91B9DC72AF93D25F5650@MN2PR00MB0688.namprd00.prod.outlook.com> <5DA4F0DB-8579-40CD-B1A9-9AB40C09F839@tzi.org> <20200710212133.GA16335@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/jg_Dt3L6AOZH_AcSEiibjraYbRA>
Subject: Re: [jose] Beyond RFC 8785 (JSON Canonicalization Scheme)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 10 Jul 2020 21:34:56 -0000

Hi Ben,

> https://tools.ietf.org/html/rfc5742#section-3 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)...

I understand that the rules are somewhat limiting the scope of consideration.

Hmm, if I were to try to publish an independent submission that defines a YANG module for TLS implementations to make their ephemeral keys available over NETCONF, I’m sure I wouldn’t even get beyond the ISE, much less the IESG — you *would* consider "what might be done later that builds upon such work", and would choose 3 or 5.

But I didn’t write this to criticize the IESG (and my objective is certainly not to make it harder to publish independent submissions; I think overall we got this about right at the moment), but more to lay out to JOSE the inevitable consequences to what’s ahead of us.

Grüße, Carsten