Why is determining the crypto methodology part of this groups efforts? Shouldn't DKIM specs state where in the dns record the signing entity stores what method they are using for crypto. If joe.stonage.com wants to use the original nix crypt command to sign should he not be allowed to do so? Of course the community would note that decision with suspicion, but that is his choice. Thanks,
Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Monday, February 20, 2006 6:52 PM To: Stephen Farrell Cc: [email protected] Subject: Re: [ietf-dkim] Supporting alternate algorithms Stephen Farrell wrote: > > While I wouldn't quibble with anyone's position on whether sha-1 is > still ok, or whether sha-256 is interestingly stronger, (not being > qualified myself), I do think the place from which DKIM ought to > accept guidance is the saag. Is there some reason that the DKIM working group needs to spend much effort discussing the details of the preferred algorithm? I would think that that is primarily a recommendation to be made by the security community. The DKIM WG must to specify a choice of specific algorithms, of course, but the design of DKIM and the specification of its mechanism for labeling its algorithms is fully flexible. The spec document can plug in any algorithm that the IETF security community recommends. That is, 1. DKIM needs to have a mechanism that permits specifying alternative algorithms. And it already does. So that requirement is already satisfied. 2. DKIM needs to specify a requirement for signer and validator support of a core sets of algorithms, where a set may have a single member or multiple. It already does, but clearly one or more of the sets need to be changed. 3. The DKIM working group needs to worry about things like cost of the algorithms, availability of implementations for them, impact on backward compatibility, transition, and so on. But I am failing to see why this group needs to put energy into discussing the relative merits of different algorithm's strength or lifespan. 4. On the matter of backward compatibility and transition, there has been some recommended text. As nearly as I can tell, it did not get pursued or resolved. No doubt, I am missing something fundamental that requires that we focus on the level of detail that occurs every time a thread touches algorithm choice, but I am not seeing what it is. Can someone explain how and why this is where we should be putting our energy? d/ -- Dave Crocker Brandenburg InternetWorking <http://bbiw.net> _______________________________________________ NOTE WELL: This list operates according to http://dkim.org/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://dkim.org/ietf-list-rules.html
