Re: [openpgp] call for adoption of draft-koch-openpgp-rfc4880bis

"Robert J. Hansen" <> Mon, 27 June 2016 19:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85E1612D5B9 for <>; Mon, 27 Jun 2016 12:35:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DaRy2jXCBvun for <>; Mon, 27 Jun 2016 12:35:40 -0700 (PDT)
Received: from ( [IPv6:2001:4f8:3:36:211:85ff:fe63:a549]) by (Postfix) with ESMTP id F2C0712D7A8 for <>; Mon, 27 Jun 2016 12:35:39 -0700 (PDT)
Received: from quorra.local ( []) (Authenticated sender: rjh-sixdemonbag) by (Postfix) with ESMTPSA id 7AE0D5BBD28 for <>; Mon, 27 Jun 2016 12:35:39 -0700 (PDT)
References: <> <> <> <>
From: "Robert J. Hansen" <>
Message-ID: <>
Date: Mon, 27 Jun 2016 15:35:38 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 ( []); Mon, 27 Jun 2016 12:35:39 -0700 (PDT)
Archived-At: <>
Subject: Re: [openpgp] call for adoption of draft-koch-openpgp-rfc4880bis
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jun 2016 19:35:42 -0000

> Let me give two answers -- one a crypto answer and the other a
> standards answer.


Jon, it seems like you're saying "since this is a purely normative
document we can be as extensive as we want, and there are good reasons
for purely normative documents to be extensive."

The presence of an algorithm in the spec tends to create pressure on
implementations to support that algorithm.  When RFC2440 had reserved
entries for TIGER192, there was a small but vocal crowd in the GnuPG
community crying out, "we need TIGER192, it's in the spec!"  And as soon
as TIGER192 was removed, those voices died out -- because hey, it's no
longer in the spec.

I am completely and vigorously in favor of OpenPGP retaining the ability
to be agile with respect to algorithms.  (In fact, I'd like to see more
work go into this.)  But with respect to adding new reserved numbers,
due to the tendency of users to see the spec as prescriptive rather than
normative, I'd like to see us be more conservative.

Also, on a somewhat tangential note -- for more than twenty years we've
been talking off and on about a prescriptive OpenPGP RFC, one that would
focus on what was a good idea as opposed to what was strictly legal.
We've never done it.  I'd like to see that change.