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

[Andrey Jivsov <[e-mail]>]

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.