Re: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers

Stephen Farrell <> Thu, 07 July 2016 11:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD87C12D757 for <>; Thu, 7 Jul 2016 04:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Status: No, score=-5.727 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_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qy9S1ZTKmOuN for <>; Thu, 7 Jul 2016 04:33:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68F8B12D74A for <>; Thu, 7 Jul 2016 04:33:40 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E4E3BE2F; Thu, 7 Jul 2016 12:33:38 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XFTS5yT8iY41; Thu, 7 Jul 2016 12:33:37 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id E89A0BE59; Thu, 7 Jul 2016 12:33:22 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1467891203; bh=qIKlsSCYXhVkcFdWaecC8NJ1jaP7w7zgCVLFWOzLNcE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=4LIOYJrXEFSG5aEu0Jb3lxxE0y5Ie5zbIH0uAW9iAvtTKJMHxv8p39w4NCUFKXhhc UYzGjFIQpMY7uDlg1NCSgvMY9zF3alfihBr5Ecp0DTSojCuvNrHnEdwDueAwuvacvc 45Sf4EI013B32+HssB2uDzfOK6hTRO+F9qNS5bn0=
To: Derek Atkins <>
References: <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Thu, 07 Jul 2016 12:33:22 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030802070003070403010503"
Archived-At: <>
Subject: Re: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers
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: Thu, 07 Jul 2016 11:33:44 -0000

Hi Derek,

On 07/07/16 12:21, Derek Atkins wrote:
> Hi,
> On Thu, July 7, 2016 5:23 am, Stephen Farrell wrote:
> [snip]
>> I forget if this cfrg posting [1] on AE was made visible here
>> or not. Apologies if this is repetitive but that posting from
>> Kenny Paterson on 20151113 seems quite relevant as it says:
>> "
>> My colleague Simon Blackburn and his collaborators have just
>> published an attack on the Algebraic Eraser scheme, breaking the
>> scheme at the designers' claimed 128-bit security level. Their
>> attack recovers the shared key using 8 CPU hours and 64MB of
>> memory. Their paper is here:
> And there was a paper published in response to this:

The discussion of the relative merits of those would be better
on cfrg. (I don't recall the latter having been posted there
for example, but I do recall hearing about/seeing it before

>> With no hats, I'd be against adding an algorithm, even as an
>> option, if there are current serious questions about it's real
>> security level. I do get the arguments for and against, but in
>> such cases am against adding codepoints where there is no way
>> to flag the codepoint as "likely dangerous" or some other
>> similarly negative/scary warning. And while it's good to go to
>> the effort to deprecate old codepoints that are now likely
>> dangerous, I don't see that it's a good idea to add new ones
>> "born" in that state.
> Note again that it's just reserving the number; it's completely
> underspecified.

The patch mentioned AE methods explicitly. Allocating codepoints
for underspecified algorithms would seem pretty odd.

> [snip]
>> Putting my AD hat back on: if the WG do reach consensus to
>> add such codepoints, then when it comes time to publish, I'll
>> be looking back to the list to ensure that consensus was very
>> clear on the list. For the AE ones, that's clearly happening
>> via this thread which is fine process-wise, assuming more folks
>> opine and the chairs declare consensus. I'm just noting that
>> so we ensure the same clarify if there are other similarly
>> contentious codepoint requests in order to avoid having to
>> revisit stuff at publication time.
> Frankly, we are already using code point 23 in production. I grabbed that
> point years ago when I wrote the original I-D and posted it here (in
> coordination with Werner, who grabbed 22 for EdDSA), well before this WG
> reopened.  I doubt there will be a large contingent looking to implement
> it, which is fine.  But I'd like to make sure nobody else uses that code
> point.

So I've no clue how this WG or the openpgp community regard
squatting but if codepoints aren't scarce marking some as
reserved could be an option. (FWIW, I'm not fussed about doing
such things if codepoints aren't scarce.)

Marking some codepoints as being reserved for an undespecified
algorithm with an uncertain strength however is not something
I'd support.


> -derek