Re: [ietf-dkim] Core algorithm support/use, draft text v2
2006-02-26 23:52:50
Dave Crocker wrote:
My proposal for language to cover supported text was confounded by
suggesting some alternative language. Discussion since then has
frequently expressed agreement with my text, but even I am not sure
what exact text folks are agreeing with. I also think that Ned's
point about the benefit of citing sender-side support, versus what is
actually sent, is significant.
Based on all that, here is what I think reflects groups consensus.
Those agreeing should say something simple, like "agree". Those
disagreeing, should say something simple, like, "I proposal the
following alternate text...".
Here goes:
A validator MUST support {SHA-1, SHA-256}.
A signer MUST support {SHA-1, SHA-26}. A signer SHOULD use
{SHA-256} for its higher security strength. However a signer MAY use
{SHA-1}, such as for compatibility with an installed base, lower
computational cost, or easier implementation effort.
Consensus?
[Just back from vacation, otherwise I would have chimed in earlier.]
I presume that the syntax {x, y} means "x and y".
I have read the discussion on "implement" vs. "use". A signer could
follow the recommendation and use SHA-256 all the time; in that case why
MUST it implement SHA-1? On the signing side, what's implemented makes
a difference if an algorithm is being negotiated, but there is no
negotiation here.
The word "However" in the next sentence makes it sound like SHA-1 is to
be used as an alternative to SHA-256. This would have to be the case if
the motive is computational cost or implementation effort [is that
really a consideration?]. But compatibility would be maximized by the
inclusion of both signatures.
I propose the following alternate text:
Signers MUST use SHA-256. A signer MAY additionally sign with SHA-1 for
compatibility with an installed base or to provide lower computational
cost for verifiers that wish to use it.
Verifiers MUST be capable of verifying signatures using SHA-256.
Verifiers MAY verify signatures using SHA-1 for compatibility with a
legacy installed base of signers or to provide lower cost verification
when a SHA-1 signature is included.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, (continued)
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Steve Atkins
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Wietse Venema
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Stephen Farrell
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Ned Freed
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Scott Kitterman
- Re: [ietf-dkim] Core algorithm support/use, draft text v2,
Jim Fenton <=
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Dave Crocker
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Eric Rescorla
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Jim Fenton
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Eric Rescorla
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Jim Fenton
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Eric Rescorla
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Jim Fenton
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Mark Delany
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Douglas Otis
RE: [ietf-dkim] Core algorithm support/use, draft text v2, Hallam-Baker, Phillip
|
|
|