----- Original Message -----
From: "Eliot Lear" <[EMAIL PROTECTED]>
To: "Ned Freed" <[EMAIL PROTECTED]>
Sent: Wednesday, February 22, 2006 2:59 AM
Subject: Re: [ietf-dkim] Supporting alternate algorithms
> As my colleague Jim Fenton is fond of saying, I am reticent to impose
> restrictions on verifiers. The issue here is how much they wish to
> trust SHA-1, and there's no need for the IETF to dictate to them on this
> count, and there should be no need for us to update the document when we
> want to pronounce SHA-1 dead. That to me therefore rates a MAY. Just
> as Phil mentioned in another note, we're pretty close to a green field
> here. Had it been otherwise I might consider a SHOULD.
Green Fields ... full of mushrooms.
I think this ought to be part of the Migration Planning. The past research
we done in regards to login/authorization methods, suggest the experts think
SHA1 is good enough for the next X years but that is should it definitely be
part of your planning to switch to sha-256.
In my opinion, lets remove this thorn from the side now for the new
protocol. Make SHA1 and SHA-256 part of the default signing choices and
that both are required for DKIM support. The technical recommendation
"should" be:
You SHOULD use the highest protection you deem necessary for
the transaction.
The signer could choose to use SHA1 for less-valuable transactions and
SHA256 for others. Who knows? He might incorporate "enhanced security" into
his cost/business model.
If a wide spread SHA1 hack does come out, signers will be able to switch to
SHA-256 on a moments notice.
The key is to make sure verifiers are ready for both.
This resolves it IMO.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html
