----- Original Message -----
From: "Dave Crocker" <[EMAIL PROTECTED]>
To: "Eliot Lear" <[EMAIL PROTECTED]>
Cc: "Ned Freed" <[EMAIL PROTECTED]>; <[email protected]>
> 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
