Jon,
Is there any issue in regards to the idea of having a signer/validator
capability logic?
We can have a base defaults (SHA1, SHA-256) or whatever you experts deem
necessary. But in an advanced implementation, the validator can define its
cryptographic validation strengths which a signer can look up and use. This
will give the signer HIGHER CONFIDENCE that a reception will not fail due to
hashing mismatches.
Example:
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.
It will work very nicely for a direct (1 to 1) transaction (which I happen
to believe most high-value transactions will take place with DKIM).
But its not limited to just 1 to 1. It can also work for a 1 to many
transactions. The signer simply looks up all the targets and get the least
common denominator (and may also exclude those that might be problematic).
This can also be cached too possibly, so it only need to be done once.
I see this as realistic for a high-value domain transaction.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Jon Callas" <jon(_at_)callas(_dot_)org>
To: "Tony Hansen" <tony(_at_)att(_dot_)com>
There is nothing that SAAG or anyone else can do for us. We happen to
be living in a time where we *know* that the cryptographic primitives
we have handy in our toolkit are not what we like. We live in what
the Chinese and Scots each call "interesting times."
The only question facing us is whether we jump straight to SHA-256
now, or allow both. Jumping is cryptographically wiser as it gets us
off the weak hash. Allowing both is engineeringly wiser as it forces
us to be agile now. Neither is a bad choice, sadly. If one were a bad
choice, then it would be easy. As things sit, we have a hard choice,
and no matter what we do, people will look back with the wisdom of
hindsight and cluck their tongues sadly about how stupid we were and
how *clearly* it would have been better to do the other thing.
Jon
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html