On Sat, 18 Jul 1998, Werner Koch wrote:
Hal Finney <hal(_at_)rain(_dot_)org> writes:
No PGP 5.x version will support "identifier 20" ElGamal keys for
decryption or signature verification. Neither does the forthcoming
^^^^^^^^^^
So PGP is not able to decrypt a valid OpenPGP message, tsss...
And will your implmentation correctly process all combinations of all
algorithms? This is really hard to get right, and it is better not to
support something than to support it badly or incorrectly.
One of the reasons there are preferred algorithm lists is to allow for
this type of thing. RSA is a not a MAY but a SHOULD, but I don't think
every implementation will allow for it. If you sign with
RIPEMD-160/ElGamal, compress with zip/15bit, encrypt with SAFER/RSA, not a
lot of things are going to be able to read it regardless of whether or not
it is "valid". You should take a look at what SSL implmementations have
to go through in their negotiation. And Email doesn't have that luxury.
It doesn't make much sense to implement MAYs before SHOULDs, at least not
if you want to interoperate. Nor is it reasonable to expect keyservers to
allow for MAY algorithm keys (even if they don't verify the keys
themselves). Everyone is going to do DSA, and most will do RSA. And I
hope ElGamal is superceeded by something better, and probably should have
been marked reserved in this spec. The technical arguments are valid, but
no one proposed any alternatives, and we need an alternative to RSA and
DSA (the former is encumbered, and the latter is restricted in size).
And there are lots of new things which PGP isn't (and probably won't be)
able to properly handle. V4 Signatures and V4 RSA keys aren't in the old
PGP, and I don't know what 6.0 is planned to do. The old one requires
SHA1 for DSA, but the OpenPGP spec would allow for RIPEMD-160.
Even my implementation which is designed as a library has lots of things
which it won't do without any additions. This is intentional since
interoperability is the primary goal.
It doesn't make sense for a commercial product to implement everything
possible to implement. All it does is bloat and complicate the code,
which is bad if code integrity is important. And it is important in any
privacy software.
--- reply to tzeruch - at - ceddec - dot - com ---