As before, I would like to express my concerns about allowing a choice of
hash algorithms. Here's some detail:
A complete break (feasible reversal) of ANY ONE of the supported hash
algorithms would allow generating keys with arbitrary long key IDs, possibly
colliding with an attacked key. This was a major problem with v3 and v4 was
a giant step in the right direction. This would be a small step backwards.
For MDC purposes, it's even worse.
Since collisions are of no concern in the case of the key fingerprint and
MDC, I would just stick to SHA1 for the time being.
Precisely because of this, assuming a full-strength hash function, half of
the hash suffices. This is just a remark to the length requirement. 128 bit
fingerprints are secure for the forseable future, but using the 160 bit SHA1
(with all its problems), is a reasonable overdesign taking into account what
we don't know.
Collision resistance is important for signatures and even more so for
certifications, but it is of no concern whatsoever for fingerprints and MDC.
Where RFC2440 has SHA1 hardwired into the spec, it is completely safe and
even somewhat of an overkill. Using Ian's terminology, it's still pareto-secure
and even pareto-complete. No alternative would provide more security.
Signatures and certifications are a completely different issue altogether.
--
Daniel