I would strongly suggest that we make SHA-256 the MUST on the signer side for interop and SHA-1 a MAY.
>From a S&M (Should & Must) perspective it is not logical to have a SHOULD on the signer side. If we are requiring all verifiers to support SHA-256 there is no logical necessity for SHA-1 support. In principle I could build a 'zero config' email signer/sender box that hooks into the infrastructure via DNS SRV and acquires its crypto keys through XKMS-ACC or similar. I would not want to support SHA1 on that box if it means an unnecessary configuration parameter. > -----Original Message----- > From: Hector Santos [mailto:[EMAIL PROTECTED] > Sent: Friday, February 24, 2006 3:57 PM > To: Hallam-Baker, Phillip; John R Levine; Eliot Lear > Cc: [email protected] > Subject: Re: [ietf-dkim] agenda item on upgrading hash algorithms? > > > ----- Original Message ----- > From: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> > To: "John R Levine" <[EMAIL PROTECTED]>; "Eliot Lear" <[EMAIL PROTECTED]> > Cc: <[email protected]> > Sent: Friday, February 24, 2006 2:52 PM > Subject: RE: [ietf-dkim] agenda item on upgrading hash algorithms? > > > > The reason people are pushing for SHA-256 now is not > because there is > > a probable imminent break. It is because we know just how long the > > process of switching algorithms takes. > > I agree. > > > I think that the consenus here is to: > > > > 1) Start the SHA-256 transition now, making it a MUST for > verifiers, > > MUST/SHOULD for signers. > > My only take here is that this MUST/SHOULD for signers will > always be tagged with a basic implementation question of > > "well, which one should I use?" > > So I think it should be carefully phrase to say: > > SIGNERS "SHOULD" use the highest form of security first among the > choices currently available {SHA-1, SHA-256}. Although it is out > of the scope of this specification, an SIGNER "MAY" use a > VERIFIER lookup concept to determine the highest form of > security it offers. > > This helps or resolves both issues and addresses the future, > especially the case if indeed when a method is hacked and > DKIM signer wishes to quickly migrate to a new method as > supported by the validators. In my view, it is almost > inevitiable, the signer will need to be a lot smarter than > the documentation calls for. i.e. find out more about the > host system it is about to send a "valuable" mail to. > > -- > Hector Santos, Santronics Software, Inc. > http://www.santronics.com > > > > > > > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
