Re: [openpgp] PKI (RFC 5480) mapping to ECC keys (RFC 6637)

Werner Koch <> Sat, 20 July 2013 08:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA35B11E80CC for <>; Sat, 20 Jul 2013 01:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.949
X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vn7aMtS+Lwy7 for <>; Sat, 20 Jul 2013 01:24:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DC98811E8135 for <>; Sat, 20 Jul 2013 01:24:53 -0700 (PDT)
Received: from uucp by with local-rmail (Exim 4.80 #2 (Debian)) id 1V0ST2-0000h1-KD for <>; Sat, 20 Jul 2013 10:24:40 +0200
Received: from wk by with local (Exim 4.80 #3 (Debian)) id 1V0SOY-0003iQ-HM; Sat, 20 Jul 2013 10:20:02 +0200
From: Werner Koch <>
To: Andrey Jivsov <>
References: <> <> <>
Organisation: g10 Code GmbH
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
OpenPGP: id=1E42B367;
Date: Sat, 20 Jul 2013 10:20:02 +0200
In-Reply-To: <> (Andrey Jivsov's message of "Fri, 19 Jul 2013 13:23:05 -0700")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [openpgp] PKI (RFC 5480) mapping to ECC keys (RFC 6637)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 20 Jul 2013 08:24:59 -0000

On Fri, 19 Jul 2013 22:23, said:

> The simplification is generic. Now that we would have 3 IDs for ECC,
> it is more efficient to check 18 <= x <= 20 then for 3 arbitrary

Compared to the cyrpto operations any efficieny here is a joke.

> Do we know of at least one case when 20 is used in deployed
> applications? This will be enough to require 22 for ECDSA+ECDH.

GnuPG supported this from 1998 to 1.3.5 (2004-02-26).  I have hundreds
of those signatures in my keyrings despite that there is no more support
in GnuPG.  Recycling this identifier would be a Bad Thing™.  Internal
PGP versions used a couple of the lower numbered IDs and they have not
been recycled, either.

> Let me answer why do I think that ECDSA+ECDH ID is a useful feature.

I agree that it is useful; I only remarked that the X.509 based
rationale is a bit weak.

> right now. Assuming that most OpenPGP keys are RSA keys, they use
> sign+encrypt ID 1 and then use the appropriate key usage flags.

Or 2 or 3.  They still pop once once in a while.

> The compact ECC point representation plus ECDSA+ECDH ID in a single
> document is one way to do this.

>From my understanding of the IETF procedures this will indeed be the

> I was wondering, however, that given that ECDSA+ECDH ID is such an
> easy change that fits in a few sentences, it feels like an errata to
> the RFC 6637. All it needs to say is that "use ID 2x for ECDSA+ECDH"
> and then define that ID in another sentence.

Maybe, but recall rfc4880 states:

   initial values for this registry can be found in Section 9.  Adding a
   new public-key algorithm MUST be done through the IETF CONSENSUS
   method, as described in [RFC2434].

That is for an algorithm but not the id, though.  Please use whatever is
the easiest way for you.

I would appreciate if we could informally agree on an identifier right
now so that I can put it into the next GnuPG 1.4 release which is due in
a few days.  This would avoid a '?' as algorithm in a key listing.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.