santronics.com exposes it supports the algorithms:
k=sha1, sha256, sha512, whirlpool, other;
If bankofamerica.com had a relationship with one of our
users, it can
lookup the santronics.com capability and choose the highest
strength.
I do not think this works at all. If we could predict where email was
going to end up the problem would be one heck of a lot easier.
From a practical point of view the only mechanism that has worked to
date is to have a small number of algorithms that are universally
supported. The problem with options is that you usually end up with the
strength being set by the weakest algorithm, not the strongest.
I would be much happier with a suites approach, vis
Suite1: RSA 1024 with SHA-256
Suite2: ECDSS 256 with SHA-3/256
Aiming to begin introducing Suite2 in the 2009-2010 time period, after
the digest algorithm contest is complete and after we get some clarity
on which forms of ECC are definitively unencumbered. ECC was first
proposed in 1985, therefore the original patents have expired and there
are at least some forms that are not encumbered. I will happily trade
speed, key size and Suite B compliance for unencumbered.
In rebuttal to Doug's point about not depending on the DNS supporting
longer key sizes, an ECDSA key that gives equivalent strength to a 128
bit symmetric cipher is 256 bits with point compression and 512 bits
without. An equivalent ECDSA signature is 512 bits in either case. The
comparable key size for RSA is 3072 bits for key and signature.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html