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
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave Crocker
Sent: Monday, February 20, 2006 6:52 PM
To: Stephen Farrell
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
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