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

Andrey Jivsov <openpgp@brainhub.org> Thu, 18 July 2013 20:07 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 4ECE321E80F7 for <openpgp@ietfa.amsl.com>; Thu, 18 Jul 2013 13:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.94
X-Spam-Level:
X-Spam-Status: No, score=0.94 tagged_above=-999 required=5 tests=[AWL=-1.377, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_BELOW2=2.154, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_45=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 7N2imAIDK7Fk for <openpgp@ietfa.amsl.com>; Thu, 18 Jul 2013 13:07:44 -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 9081B21E80F6 for <openpgp@ietf.org>; Thu, 18 Jul 2013 13:07:44 -0700 (PDT)
Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 1v7y1m0050mlR8UA1w7krQ; Thu, 18 Jul 2013 20:07:44 +0000
Received: from [127.0.0.1] ([69.181.162.123]) by omta11.emeryville.ca.mail.comcast.net with comcast id 1w7i1m00d2g33ZR8Xw7jov; Thu, 18 Jul 2013 20:07:43 +0000
Message-ID: <51E84A3C.8060800@brainhub.org>
Date: Thu, 18 Jul 2013 13:04:12 -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
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=1374178064; bh=7G0GlKwEFkFJ3hRqTzVHiJZYambI78dZ7CYT4ImWnCY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cODKm+JStDqV7XuS3xMeWdkhY6aWSqY2T8e4DavOwSCpJlAnh0cC1kiQNcluxyM2i eP0JMV7HPePfJITeNCh3Hmd7bjNK7BEaK1geLaypqmkuuqwHJxiCcOy29fDhTDG5Wh J7jTE1I8L7u2n7ft+/4vQAGKqWzpZSnAEoMXRN3QXtexH3mPfuSCCFzAa3YuWyh5+W yUvBPOT5vhuyJjOgqVfq9Kenc4SjQuOvauGwW6A8Z8j/ugexXXDufeqnNDB1FOyT1x LFXW10XRtJGyYf27lCBu4w0JafIfVAPeHLR6F1e0AZ6VSogHokr2LzVvhSdg3DC+NE zyYQLZWM/+bNQ==
Subject: [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: Thu, 18 Jul 2013 20:07:50 -0000

Hello.

I noticed one unfortunate inconvenience about ECC public key definition. 
Currently RFC 6637 defines two types of keys:

    ID 18: ECDH
    ID 19: ECDSA

but no "joint" or "unlimited" ID. As shown bellow, this is needed for 
easier interchangeability with PKI standards.

I was probably hypnotized by the already reserved ID 18 for ECDSA in RFC 
4880 to not think in general terms, which is:

    Given that EC keys can do both signing+encryption, just as RSA keys, 
why there isn't a single public key ID (i.e. the analog to ID 1 for RSA).

We have key usage flags to narrow down the usage.

The issue is that it's justifiable in many cases to have a single 
top-key only OpenPGP key and such a key should be capable of both 
signing+encryption.

In particular, this issue comes up when one tries to map an X.509 ECC 
certificate, as defined in RFC 5480, to RFC 6637.

As I understand it based on my observations of the current use of ECC 
X.509 certificates, the most common usage will be sec 2.1.1 of RFC 5480, 
which defines an "unrestricted" id-ecPublicKey algorithm identifier. The 
problem is that there is no way to map it cleanly into an RFC 6637 ID. 
RFC 5480 also has restricted id-ecDH (but not sign-only ID). 
Interestingly, there is no sign-only ID in RFC 5480, thus, even CA 
certificates that are restricted to signing will get id-ecPublicKey 
algorithm ID.

In RFC 6637, ID 18 (ECDH) is a superset of fields of ID 19 (ECDSA)

What are the possible fixes here?

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).

2. Overload ID 18 to allow ECDSA. One problem here is that it we loose 
the ability to map id-ecDH into ID 18.

3. Overload of ID 19 will not work, because it lacks KEK parameters that 
are needed for encryption. Plus, sign-only application are useful for 
regulatory compliance (because it's not encryption).

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 cases.

I see #1 as the only perfect solution for the problem. Does anybody have 
any other thought about how to proceed?

Thank you.