On Fri, 19 Jul 2013, Andrey Jivsov wrote:
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.
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.
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.
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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp