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

[Andrey Jivsov <[e-mail]>]

He Werner.

On 07/19/2013 05:34 AM, Werner Koch wrote:
> On Thu, 18 Jul 2013 22:04, [e-mail] 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
>