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

Barry Leiba <> Tue, 28 June 2016 08:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D999012DB4B for <>; Tue, 28 Jun 2016 01:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 qGVtg4OALdgm for <>; Tue, 28 Jun 2016 01:18:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 802F012B051 for <>; Tue, 28 Jun 2016 01:18:46 -0700 (PDT)
Received: by with SMTP id f6so19787622ith.0 for <>; Tue, 28 Jun 2016 01:18:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-transfer-encoding; bh=qkLnYzIqnIhPnFQU87+rFBtFLGKKhpxaz2FaF6+OqkY=; b=r9r3AW/MrvOg19zAbKQx4aXxKKoF6aURPRZ0yboQPedoLumvDHNcg6eYDTeM61ulHj lsTCwOhk2BxWRqmLfrL7HuzkjNk5fJW26215jQJ5uDo3enlAvpP98Nxzuk2X9C0TiNj2 mV6ZTQZva5DnbQVIY+EOsur5PqUhDAEzsRcZllb1iXQSIBa4BpwxFpOKnx66w8BKmw0/ E1WA7Dt8e+vZR6MDZbfDnroimo01OTDS4E2PvPW3c4m7S8gjN3VSq/YnRPBPuZGNhN4n JjSmamWUtQvLB1XR+zbE2rpGkieTBfIFkK+5Er1QcaYX0pLKm4hvmZ0v/mghSb2kdmPW hfsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-transfer-encoding; bh=qkLnYzIqnIhPnFQU87+rFBtFLGKKhpxaz2FaF6+OqkY=; b=XDn2W+UW6n+fzgmitytDxkdl7hKnThBxKq0TKh0BtopHtkr1KmOzeq+K9iFqTxVzbQ voRugbEClvP9jRSSddGNtVcm/VDsxhGmyXpsnaGV6CXs9ujul9EeaRS7SCAoYI5Md6au vK5WsC+DOt1O1u+4TqYaTOQygHKv+NtdCyEFYqOHqEWJMQPkT19erwzcfj2HKis8GlZY lflWoYQpT09vP9IKJOlCs4h+39R4F8pW2QZASMfHE8Bitw+f+1GrGf0r1YDzctRansz+ ucYokc1s0VRPxu0qzV9FBZBYUevG1EJwR7HEi52mJ85SSihRp8IWqo4BLATqi4eZYF/W XFAw==
X-Gm-Message-State: ALyK8tKG9lchuAmfYOic9g/YxzIS/4OslFyUPQdgRQE9YY+dzm8LHn+PTgP08UFSl5Uz0QnooLXIfM/HCAm1wQ==
X-Received: by with SMTP id m77mr12500358ita.96.1467101925707; Tue, 28 Jun 2016 01:18:45 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Jun 2016 01:18:44 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Barry Leiba <>
Date: Tue, 28 Jun 2016 04:18:44 -0400
X-Google-Sender-Auth: YQE_cEpeI8NsoqytEgRoRm4lDhA
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Tue, 28 Jun 2016 08:18:49 -0000

Folks, if you want to discuss the document itself, please change the
subject line appropriately, to start a new thread.  Please leave this
thread for comments about using this draft as the starting point for
the work.

Barry, as chair

On Mon, Jun 27, 2016 at 6:20 PM, Jon Callas <> wrote:
>> 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.
>         Jon
> _______________________________________________
> openpgp mailing list