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

Jon Callas <> Mon, 27 June 2016 22:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2EC812D9E9 for <>; Mon, 27 Jun 2016 15:20:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LuoP9_l_ek7Z for <>; Mon, 27 Jun 2016 15:20:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E6B9C12D9FE for <>; Mon, 27 Jun 2016 15:20:13 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built Sep 8 2015)) id <> for; Mon, 27 Jun 2016 22:20:13 +0000 (GMT)
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built Sep 8 2015)) with ESMTPSA id <>; Mon, 27 Jun 2016 22:20:12 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-06-27_15:,, signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1606270224
Content-type: text/plain; charset="us-ascii"
MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jon Callas <>
In-reply-to: <>
Date: Mon, 27 Jun 2016 15:20:07 -0700
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <> <> <> <> <>
To: "Robert J. Hansen" <>
X-Mailer: Apple Mail (2.3124)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=4d515a; t=1467066013; bh=xUNC79AFO1osNBYUe2mAK0u86aaq6hgOc5FBHfYLV+0=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=ECvct0azKlQGcx/h9H0o6vjsxSb8wMJaKqNaRr36FVC3ZUJs1P5HEebwIWCxLnEOt v9eXmtJHEc4Mrmy5Mudb5051JUpWZhEPo5tTE1b1O5DJbv3cvwWHpnZEZsSYUgD7y3 howycELPzZ7QX5wIotkEBgFALvrHyomPp1x4RhOyVE7T4w2LoVIHE09DuVe0I7OQ3Z vfbmOeG4bFh3RiKa/UE7RlTtgCfDd+6xfOtyCvzWKEFoSa/iQMH1QVHmTlsYfckjcA R8oz5bjMssa0ANb7FEWZq1pl4PGuwc7IGJ5nnNWrZqdBKMPUDj2DhivKTuYUcn6GEx aLhXPaHc+z4Bw==
Archived-At: <>
Cc:, Jon Callas <>
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 22:20:16 -0000

> On Jun 27, 2016, at 12:35 PM, Robert J. Hansen <> wrote:
>> Let me give two answers -- one a crypto answer and the other a
>> standards answer.
> [de-lurks]
> 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."

Well, no, that's not what I'm saying.

It seems to me that you're setting up a straw man. I realize you're probably not, but that's what I'm saying.

What I am saying is that in this *specific* case, the risks of adding it are low.

I recognize that options are good and options are bad. There's a cost to options, but there's a cost to not having them.

> 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 think I disagree, because one of the reasons Tiger and others were removed is that they essentially weren't being used.

But -- let me just concede the point. We made a mistake in removing Tiger, then. We removed it because there was no constituency. If there *was* a constituency and we didn't realize it, we made a mistake. 

However, let me address your larger point, the "pressure" to support an algorithm.

In 2440/4880 there were two reference implementations, PGP and GnuPG. For better or worse, PGP did not implement Blowfish (actually, it's more complex than that -- PGP would *decrypt* a message encrypted with Blowfish because some versions of GnuPG didn't do cipher negotiation properly, but it wasn't offered as a choice and never encrypted to it). It didn't implement SAFER nor DES/SK. It did not implement Elgamal signatures. It didn't implement Tiger nor Haval nor MD2. 

GnuPG took the admirable stand of implementing everything in the standard, but still didn't implement RSA until the patents expired. (But that is also something that's more complex than the simple preceding sentence.)

I know that today, there are a number of implementations that don't do Camellia. 

You are absolutely right that in some places implementers just go and implement whatever. The OpenPGP community hasn't ever been one of those places, it's been a raucous group of people with definite opinions and tastes. That has never been a problem here. OpenPGP is designed so that people can go play in their own sandbox with no detriment to the people who don't want to play.

Rich Salz brought up a great suggestion -- put the identifier registry outside the main document, which would help as well. That takes pressure off of the casual reader.

> 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.

Okay. That gets to the core of it. If the standard is prescriptive with everything as MUST, then sure, you have to be difficult about what you allow.

If you don't want AE because it's an impediment to a prescriptive, that's a different discussion. We should have the discussion of a prescriptive standard on its own.