Detecting PGP 2.6.x keys

[Aleksandar Milivojevic]

David Shaw wrote:
> It's not just that the person with the PGP 2.x key must have IDEA -
> it's that people with OpenPGP might not.  Take this case: User A has a
> PGP 2.x key.  User B has an OpenPGP key.  In an effort to accomodate
> user A, you encrypt using IDEA.  However, user B does not have IDEA.
> By trying to be backwards compatible with user A, you accomplish
> locking out the modern user B.  The only really safe way to handle PGP
> 2.x users is to encrypt twice - once for the PGP 2.x people, and once
> for everyone else.

Let say somebody implements option in GnuPG so that user can choose to 
have GnuPG go into PGP 2.x compatible mode automatically if PGP 2.x key 
is used. And let say option would be turned off by default, so for all 
current GnuPG users there is no change in how GnuPG behaves.

In this case, if I turn that option on (in my gpg.conf file for 
example), and try to encrypt to users A and B from your example, GnuPG 
could bark that it can't find set of compatible ciphers to accomodate 
both user A and user B, and that I should encrypt to them separately. 
When I get such an error from GnuPG, it would be my problem, since I was 
warned what might happen if I use option like that.  Same thing if my 
correspondent (who uses his old PGP 2.x key with GnuPG) barks at me that 
he no longer can use IDEA, and that I should upgrade from PGP 2.x to 
GnuPG ;-)

Having options in GnuPG to make it compatible with PGP 2.x (eihter short 
--pgp2 or mile long one specifying cipher, compresison, etc separately) 
is great.  But for somebody who has lots of PGP 2.x correspondents, 
option that will have GnuPG automatically turn those on would be much 
more usable (with appropriate warnings in the documentation, of course).

-- 
Aleksandar Milivojevic <amilivojevic at pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7