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

From: Andrey Jivsov <[email-masked]>
Date: Thu, 18 Jul 2013 13:04:12 -0700

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.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 18 Jul 2013 16:17:54 -0400

> any other thought about how to proceed?

Your first proposed solution (#1) seems reasonable to me, and not
without precedent.  It's similar to the asymmetric key IDs allocated for
RSA:

  https://tools.ietf.org/html/rfc4880#section-9.1

      1          - RSA (Encrypt or Sign) [HAC]
      2          - RSA Encrypt-Only [HAC]
      3          - RSA Sign-Only [HAC]

Regards,

	--dkg

---

From: Werner Koch <[email-masked]>
Date: Fri, 19 Jul 2013 14:34:37 +0200

On Thu, 18 Jul 2013 22:04, [email-masked] 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 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 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?

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 19 Jul 2013 13:23:05 -0700

He Werner.

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

> enitirely different and having the same algorthm numbers does not matter

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.

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

---

From: Paul Wouters <[email-masked]>
Date: Fri, 19 Jul 2013 16:32:57 -0400 (EDT)

>> needs to be allocated.  22 would be the next.

Indeed.

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

Those "benefits" are just coding errors waiting to happen in the future. A
switch statement seems much more appropriate.

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

Even with no implementation out there, the allocated numbers should not be
recycled, unless in extreme use cases, eg where we've ran out of
numbers.

Paul

---

From: Werner Koch <[email-masked]>
Date: Sat, 20 Jul 2013 10:20:02 +0200

On Fri, 19 Jul 2013 22:23, [email-masked] 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.

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

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

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

Salam-Shalom,

   Werner

---

From: Andrey Jivsov <[email-masked]>
Date: Sat, 20 Jul 2013 13:54:01 -0700

On 07/20/2013 01:20 AM, Werner Koch wrote:
...

> a few days.  This would avoid a '?' as algorithm in a key listing.

Your earlier e-mail leaves us with 22 for ECDSA+ECDH.

---

From: Werner Koch <[email-masked]>
Date: Sun, 21 Jul 2013 00:15:36 +0200

> Your earlier e-mail leaves us with 22 for ECDSA+ECDH.

Very well.  It is easy to remember.

Salam-Shalom,

   Werner