> > 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
