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

Andrey Jivsov <> Fri, 19 July 2013 20:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A89FF11E81AD for <>; Fri, 19 Jul 2013 13:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.807
X-Spam-Status: No, score=0.807 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_45=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_54=0.6, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PBZ01R+EtgWx for <>; Fri, 19 Jul 2013 13:26:48 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe2d:43:76:96:30:16]) by (Postfix) with ESMTP id 368FC11E8141 for <>; Fri, 19 Jul 2013 13:26:41 -0700 (PDT)
Received: from ([]) by with comcast id 2JtM1m0051ZMdJ4A1LSgbj; Fri, 19 Jul 2013 20:26:40 +0000
Received: from [] ([]) by with comcast id 2LSf1m0072g33ZR8cLSgjb; Fri, 19 Jul 2013 20:26:40 +0000
Message-ID: <>
Date: Fri, 19 Jul 2013 13:23:05 -0700
From: Andrey Jivsov <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1374265600; bh=Zsb75CjucMOSDuH5uducCTzTyLBNyZvPWzvfvesUohw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kAXzac/AH31U/PLe33P5QxPQsVT3oXTeIWbEkoWE9srBYBEmP7Q4TGnmOFQoPQ6VJ Gm84SHr9hbEnvaUV/ilxTM2WeyLCvOYt2zFUf/bTAR8Kv89jA/xNxjIH7PwsgreX1H Yf4fmgzFYRaPY1TfPvcdhS8y6JDQ4dJC5KOgZnv+fVTsbzyXxMeopFCsT22A7tz1H1 6TPCryBNVdRDeNLY8jKGIcaTaZT5B8ZQjj58xrtm41EXbr9uK1SS6GMgjLWRAlQRyo igc4s/UoWK1fXx8Zs84GV2FmN7GtqT1PnNZtRwu4a5FViDvSfDiJtBW/MRARrsMIY0 vXZR4dlkrn3tg==
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: Fri, 19 Jul 2013 20:26:52 -0000

He Werner.

On 07/19/2013 05:34 AM, Werner Koch wrote:
> On Thu, 18 Jul 2013 22:04, said:
>> 1. Add ID 20 that is ECDH+ECDSA. It will be defined identically to ID
>> 18 (ECDH), but will also be allowed to perform the
>> signature/verification functionality of ID 19 (ECDSA).
> You can't use 20 because it was used for Elgamal in rfc2440.  A new one
> needs to be allocated.  22 would be the next.

I was thinking about recycling ID 20, given that there is small benefit 
for the IDs to be consecutive.

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 IDs. Also, 
consecutive IDs allow easy transition to zero-based indexing (just 
subtract 18).

Current definition of 20 in RFC 4880 is:

    20         - Reserved (formerly Elgamal Encrypt or Sign)

In RFC 2440 it is:

    20         - Elgamal (Encrypt or Sign)

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.

>> I assume that it will be common (or at least possible) to issue
>> end-user X.509 certificates for SMIME that are
>> signing+encryption. Thus, even though current PKI CA certificates can
>> be mapped to ID 19 based on keyUsage flags, we cannot do this in all
> Frankly I can't see why this is an advantage.  X.509 and OpenPGP are
> enitirely different and having the same algorthm numbers does not matter
> at all.

I am not sure what exactly do you mean.

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

Alignment with the PKI standard is helpful in applications where one 
maps an X.509 certificate into an OpenPGP key. See, for example,

Turns out that ECC certificates use id-ecPublicKey and then restrict 
usage with key flags, exactly as most of OpenPGP keys are doing it right 
now. Assuming that most OpenPGP keys are RSA keys, they use sign+encrypt 
ID 1 and then use the appropriate key usage flags.

Often the key usage needs to be adjusted after the key generation. For 
example, it was an encryption-only subkey originally and the user wants 
to make it sign+encryption. OpenPGP doesn't offer this feature right now 
for ECC keys (while it does so for RSA). With current RFC 6637 this 
usage change would mean a new KeyID.

>> I see #1 as the only perfect solution for the problem. Does anybody
>> have any other thought about how to proceed?
> The IETF consonsus method shall be used for new algorithms.  Thus you
> need to write an I-D.  IIRC, you are already working on a compressed ECC
> key specification.  What about using the new algorithm for this - or at
> least to use that I-D for adding a new algorithm number?

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

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.

The compact point document is a logically different document.

RFC 6637 attained the "Standards Track", while the compact point will 
likely be "Informational" and optional.

> Shalom-Salam,
>     Werner