Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:
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.
An IETF specification needs to contain a core of requirements that guarantee
interoperability between participants who have no prior arrangement. That means
that all both sides must support a core of capabilities that match, including
algorithms such as crypto, if that's part of the service.
If that core of specified required algorithm support is not in the spec, then I
can choose to sign with whatever algorithms I like and you can choose to support
whatever algorithms you like, and there might not be an overlap between the two
sets.
So a good IETF protocol defines a basic, guaranteed level of automatic
interoperability, and then often has mechanisms that permit supporting optional
enhancements.
Hence, the DKIM group needs to specify a basic set of algorithms for doing the
signing calculations. So, for example, we really do need to specify SHA-256, or
whatever will be acceptable to the security community's experts.
My own point is that this venue is not the place to have a discussion about
relative security merits of the chosen algorithm. Rather, that is the job of
the security algorithm experts.
Our job is to:
1. Specify a mechanism for specifying which algorithms are used for a particular
signature.
2. Specify the core set of algorithms that everyone must support
3. Specify any additional details needed to support legacy senders and/or future
transitions.
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html