[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interop grill-off



On Mon, Sep 19, 2005 at 02:05:19PM -0700, Jon Callas wrote:

> I think it would be good for us to have some sort of interoperability  
> test and event. Putting on my PGP Corporation hat, I'm happy to  
> sponsor it. However, it doesn't *have* to be a physical event. Does  
> anyone else think it would be a good idea? Does anyone want to help  
> put it on, come up with test cases, that sort of thing?

How about simply posting test cases with descriptions here, and testing on
various OpenPGP implementations, also posting the results to the mailing
list. Then you (or someone else) could post a summary here and/or to some
webpage.

I'm also wondering what are you more after: unusual data conforming to
RFC2400 (or RFC2440bis) or slight (but logical) deviations, extensions?

I guess, many of us have already identified interoperability problems. Would
it make sense to collect them first, before going into testing questionable
cases?

Here's my list of problematic cases that I have encountered:
(offenders: HushMail, PKS, SKS, GnuPG)

1. HushMail's idea of signed and encrypted messages is encrypting a
clearsigned message as canonical text, including the message boundary and
the armored signature. Other applications usually don't verify the
signature, though, of course, it's easy to do "by hand" (by running a second
pass). In the other direction, it's worse: HushMail decrypts the properly
signed and encrypted message, but keeps silent about the one-pass signature
within the encrypted payload; the message is identified as encrypted but not
signed.

2. Some keyservers omit canonization before hashing the key packet. If the
key packet is shorter than 256 bytes (typically the case for 1024-bit RSA
keys) and uses the shortest possible packet header with a one-byte length,
the fingerprint and the key IDs are mis-calculated. PKS is guilty of this.

3. Some keyservers do not return matching keys, if searched by the long
(16 byte) key ID of a subkey. SKS is guilty of this.

4. Some implementations give up before trying all possible ways of
decrypting a message. For example, GnuPG gives up if it encounters a
passphrase-derived symmetric key specifier and the entered passphrase is
wrong, even if it is followed by an asymmetrically encrypted symmetric key
for which it does have access to the corresponding private decryption key.

-- 
Daniel