He Werner.
On 07/19/2013 05:34 AM, Werner Koch wrote:
On Thu, 18 Jul 2013 22:04, openpgp(_at_)brainhub(_dot_)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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp