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

Andrey Jivsov <openpgp@brainhub.org> Fri, 19 July 2013 20:26 UTC

Return-Path: <openpgp@brainhub.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89FF11E81AD for <openpgp@ietfa.amsl.com>; Fri, 19 Jul 2013 13:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.807
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBZ01R+EtgWx for <openpgp@ietfa.amsl.com>; Fri, 19 Jul 2013 13:26:48 -0700 (PDT)
Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 368FC11E8141 for <openpgp@ietf.org>; Fri, 19 Jul 2013 13:26:41 -0700 (PDT)
Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 2JtM1m0051ZMdJ4A1LSgbj; Fri, 19 Jul 2013 20:26:40 +0000
Received: from [127.0.0.1] ([69.181.162.123]) by omta16.emeryville.ca.mail.comcast.net with comcast id 2LSf1m0072g33ZR8cLSgjb; Fri, 19 Jul 2013 20:26:40 +0000
Message-ID: <51E9A029.6000303@brainhub.org>
Date: Fri, 19 Jul 2013 13:23:05 -0700
From: Andrey Jivsov <openpgp@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: openpgp@ietf.org
References: <51E84A3C.8060800@brainhub.org> <87a9lid8yq.fsf@vigenere.g10code.de>
In-Reply-To: <87a9lid8yq.fsf@vigenere.g10code.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; 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-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openpgp>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=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, openpgp@brainhub.org 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,

http://www.ietf.org/mail-archive/web/openpgp/current/msg01742.html

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
>