----- Original Message -----
From: "Dave Crocker" <dcrocker(_at_)bbiw(_dot_)net>
To: "Eliot Lear" <lear(_at_)cisco(_dot_)com>
Cc: "Ned Freed" <ned(_dot_)freed(_at_)mrochek(_dot_)com>;
<ietf-dkim(_at_)mipassoc(_dot_)org>
However I think the model for the spec language is clear:
A validator MUST support {SHA-1, SHA-256}.
A signer SHOULD use {SHA-256}.
We can, of course, add discussion about the trade-offs. This might
lead to the somewhat unusual alternative for signer language,
along the lines of:
A signer MAY use {SHA-1} for its lower overhead, in spite of
potentially reduced security strength. A signer SHOULD use
{SHA-256} for its higher security strength.
Ok, folks. What have I missed?
Nothing in my view. Since it is a rehash of what I posted this morning:
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002305.html
I agree with this. I don't understand why it would be unusual. It follows
Postel's Law:
"Be conservative in what you send, liberal in what you receive."
and IMO, its not really a question of algorithm by the level of strength one
wishes to use.
If one alternative change the above is done, I would probably say:
A signer HAS the option of using {SHA1, SHA-256} depending
on the strength it chooses to sign mail with. The signer
SHOULD use the highest strength when all possible.
Someone should make a note that a Migration clarification and insight
related this topic will be required.
Also, a possible solution:
- Signer/Validator Capability "Handshake" Logic
A validator can define a SSP-like DNS policy that defines the capabilities
of the validator.
Signers can then have the ability (based on advanced implementation) to
pre-examine a target to see what strength it supports. This will only work
for a direct transaction (1 to 1, not 1 to many). But it allows for a
client/server "capability handshake" so to speak.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html