DSA2 and recipient preferences

[Qed]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Playing with DSA2 keys(gnupg 1.4.4-svn4149) I've noticed a potentially
problematic behaviour when mixing old and new keys.

Suppose you have three keys:
# <mybigDSA2> is your key and is a 3072DSA(q=256)
# <recentKEY> is a key that has the following digest prefs: SHA1,
SHA256, RIPEMD160
# <oldKEY> is a key with the following(rather common) digest prefs:
SHA1, RIPEMD160
and you have personal-digest-preferences "H10 H9 H8 H3 H2" in your
gpg.conf.

with "gpg -u <mybigDSA2> -s -e --encrypt-to <mybigDSA2> -r <recentKEY>"
we obtain a DSA/SHA256 signature, correct.

with "gpg -u <mybigDSA2> -s -e --encrypt-to <mybigDSA2> -r <oldKEY>"
we obtain a DSA/SHA512(truncated to 256bits) signature without ANY warning.

with "gpg -u <mybigDSA2> -s -e --encrypt-to <mybigDSA2> -r <recentKEY>
- -r <oldKEY>"
again we obtain a DSA/SHA512 sig without warnings, thus violating the
preferences of both recipients.

This latter behaviour is obviously a bug, RFC2440 says about symmetric
ciphers:
> An implementation MUST NOT use a symmetric algorithm that is not in
> the recipient's preference list. When encrypting to more than one
> recipient, the implementation finds a suitable algorithm by taking
> the intersection of the preferences of the recipients.
but future DSA keys with q>160 would inevitably break this rule when the
recipient is a key with digest prefs set to "H2 H3".
Decrypting the message with such a key and veryfing doesn't generate any
warning, again RFC2440:
> If an implementation can decrypt a message that a keyholder doesn't
> have in their preferences, the implementation SHOULD decrypt the
> message anyway, but MUST warn the keyholder that the protocol has
> been violated.

Obviously my statements are based assuming that the same considerations
for symmetric algorithms apply to digest algorithms, section 12.2 says:
> Other algorithm preferences work similarly to the symmetric
> algorithm preference, in that they specify which algorithms the
> keyholder accepts.

Must be said that section 12.2.2(Hash algorithm preferences) doesn't
specify explicitly what MUST be done, so if my assumptions are wrong,
please ignore me.
- --

  Q.E.D.

ICQ UIN: 301825501
OpenPGP key ID: 0x58D14EB3
Key fingerprint: 00B9 3E17 630F F2A7 FF96  DA6B AEE0 EC27 58D1 4EB3
Check fingerprints before trusting a key!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEgfIGH+Dh0Dl5XacRAwQYAJ0T2dUHW4h3KTkDInOtz09R2mjXygCfSsbh
cJXPC2Qy+wirA45qwey32To=
=D8uH
-----END PGP SIGNATURE-----