dontspam-tzeruch(_at_)ceddec(_dot_)com writes:
It was and is. I think I was the only one to actually enable them. I
also enabled DSA/RIPEMD and such.
So does gnupg.
How about "Algorithms that are not 'MUST' or 'SHOULD' SHOULD NOT be
entered into the PGP PKI". This is perfectly reasonable - you wouldn't
want experimental algorithms widely published, nor keys that are rarely
implemented. Since ElGamal is MAY, keyservers SHOULD NOT accept them.
Current keyserves accept everything including faked user-ids and keys.
I talked to some keyserver people and we came to the conclusion that a
new keyserver software should address this problem by verifying at
least the self-signatures of all OpenPGP keys. As the design of gnupg
is based on keyservers, I have to write such software anyway and of
course it will support ElGamal signatures.
I would like to keep it at 20. I can move it, but that number was created
for the specific reason.
So do I. I saw the reason for the additional identifier 20 and
changed my software so that it now generates ElGamal keys with 20 and
inhibits the usage of v4 packets with pubkey 16 for signatures.
I can't count the hours of voluntary work on gnupg only to support
the changes in OpenPGP and I'm not willing to add code for another
algorithm identifier. The comment packet case and the reuse of
existing (rfc1991) packets for different purposes has been bothering
me enough. Every time I code some of these changes I am thinking why at
all using this ugly pgp format and not going for a more versatile
format and dropping any pgp support.
If we can stay with the current draft, I will make DSA the default
algorithm for gnupg.
Werner
p.s.
Signed with a ElGamal key in a v3 packet which is a RFC1991 compliant
extension - used due to the undocumented pgp5 format.
[finger gcrypt(_at_)ftp(_dot_)guug(_dot_)de for the pubkey]
pgpwkO1EzLQyZ.pgp
Description: PGP signature