Re: [openpgp] rfc4880bis and draft-openpgp-iana-registry-updates-01

Benjamin Kaduk <kaduk@mit.edu> Mon, 03 December 2018 01:02 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079C1130DE7 for <openpgp@ietfa.amsl.com>; Sun, 2 Dec 2018 17:02:06 -0800 (PST)
X-Quarantine-ID: <JccMVSrCRBB7>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 JccMVSrCRBB7 for <openpgp@ietfa.amsl.com>; Sun, 2 Dec 2018 17:02:04 -0800 (PST)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34285130DE1 for <openpgp@ietf.org>; Sun, 2 Dec 2018 17:02:04 -0800 (PST)
X-AuditID: 12074422-b33ff70000005b85-25-5c048088824e
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 9E.EE.23429.980840C5; Sun, 2 Dec 2018 20:02:02 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.14.7/8.9.2) with ESMTP id wB311uIT030102; Sun, 2 Dec 2018 20:01:57 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wB311qfV016469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 2 Dec 2018 20:01:54 -0500
Date: Sun, 2 Dec 2018 19:01:51 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Ronald Tse <tse@ribose.com>
Cc: "openpgp@ietf.org" <openpgp@ietf.org>, "Mark D. Baushke" <mdb@juniper.net>, Derek Atkins <derek@ihtfp.com>
Message-ID: <20181203010151.GG54918@kduck.kaduk.org>
References: <87y3aosju2.fsf@wheatstone.g10code.de> <B64F4A5B-1894-4B01-9DAE-3C7A19C772BF@ribose.com> <14036.1543342928@contrail-ubm16-mdb.svec1.juniper.net> <B6F2B98A-E960-4189-A579-E29916079904@ribose.com> <875zwhvef3.fsf@wheatstone.g10code.de> <sjmmuptyszn.fsf@securerf.ihtfp.org> <20181201001941.GE87441@kduck.kaduk.org> <348B9107-4726-4899-A980-FD3BEB2A0BA5@ribose.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <348B9107-4726-4899-A980-FD3BEB2A0BA5@ribose.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42IRYrdT0e1qYIkx2LlUwmLlpB3sFl13rrNZ NPx7yG7Ruu0ImwOLx5IlP5k8ln99wOJxvekqu8fV+VPYAliiuGxSUnMyy1KL9O0SuDLm3l3D WrCNr+LPl10sDYyfuLoYOTgkBEwkLq1N7WLk4hASWMMkcW7fVlYIZwOjxOEjL5i6GDmBnDtM Eu3H7UBsFgEViRmPfoLF2YDshu7LzCC2iIC8xOnpK9lAbGaBcon3t9+A1QgL+Ejcb90IVsML tGxKw24WiJnNzBK776lBxAUlTs58wgLRqyVx499LJpDjmAWkJZb/4wAJcwrYSfRdeMwKEhYF Wvt5gcAERoFZSJpnIWmehdC8gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6pXm5miV5qSukm RnAguyjtYJz4z+sQowAHoxIP74xElhgh1sSy4srcQ4ySHExKorxORUAhvqT8lMqMxOKM+KLS nNTiQ4wSHMxKIrwFhUA53pTEyqrUonyYlDQHi5I47x+Rx9FCAumJJanZqakFqUUwWRkODiUJ XrtaoEbBotT01Iq0zJwShDQTByfIcB6g4Xlgw4sLEnOLM9Mh8qcYdTlezOiYwSzEkpeflyol znu1DqhIAKQoozQPbg4oAUlk7695xSgO9JYwrzxIFQ8wecFNegW0hAloSc4WJpAlJYkIKakG RtPC+DTjpooTtZNt78UfXJGo8alRbNKWwMa88ht3vwY3mn7Zs3Otc0+7pfKR3fIvpCYf3Gvz ot1/1UXpZ5a60Se215V/PJgin5TKtXBKzJtEyQa571sdKqWU5s8zsjgQbnZv25SWnQ1d8o// HmK2c0xcvLt8yymez0KXps+d9KT0gkrQdS0PfiWW4oxEQy3mouJEAI5l2DIbAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/yfgATXq83JOO7E4xjZGoALRAXmU>
Subject: Re: [openpgp] rfc4880bis and draft-openpgp-iana-registry-updates-01
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Dec 2018 01:02:06 -0000

On Sat, Dec 01, 2018 at 07:21:43AM +0000, Ronald Tse wrote:
>    Hi Ben, Derek,
> 
>      Derek is absolutely right, here.
> 
>    I fully agree that managing two documents is more complex than handling
>    one.
> 
>      I'll note that for TLS 1.3 we did separate documents, RFCs 8446 and
>      8447,
>      since there were a *lot* of registry changes and we did want a permanent
>      record of them, but that split caused a lot of extra work to ensure
>      things
>      were synchronized during AUTH48.
> 
>    However, the OpenPGP IANA update document was created from a suggestion by
>    the Security AD, where the TLS registry update model was the acceptable
>    role model to follow. RFC 8447 is at 17 pages; this document is close to
>    30 - the OpenPGP IANA registries are numerous and changes to them many,
>    since a lot of them have been dilapidated since the days of 2440.
>    If we merge this into 4880bis and remove them at publication, we're adding
>    30 pages (temporarily) and then maybe removing 25 at publication. And we
>    lose the permanent record that RFC 8447 provides for TLS. Perhaps there is
>    an argument that the registries of OpenPGP aren't as important (!) as
>    TLS's for permanent record keeping, and therefore should be relegated to
>    an Internet-Draft, but it doesn't sound like a good reason to forgo that.
>    Given that the IETF process has already processed the pair of 8446/8447
>    successfully in a synchronized way, would it be possible that it's even
>    easier this time round?

Most of the pain of 8447 was on the WG chairs and AD to manually do
consistency checks.  I don't expect much of an efficiency gain from
practice, but I suppose there are probably ways to distribute the work that
we did not explore very well for 8447.

-Ben