On 22 Feb 2006, at 1:03 PM, Douglas Otis wrote:
On Feb 22, 2006, at 11:11 AM, Jon Callas wrote:
The only question facing us is whether we jump straight to SHA-256
now, or allow both. Jumping is cryptographically wiser as it gets
us off the weak hash. Allowing both is engineeringly wiser as it
forces us to be agile now. Neither is a bad choice, sadly. If one
were a bad choice, then it would be easy. As things sit, we have a
hard choice, and no matter what we do, people will look back with
the wisdom of hindsight and cluck their tongues sadly about how
stupid we were and how *clearly* it would have been better to do
the other thing.
There is an equally important question related to this question.
Adopting an IANA index of the signature/hash algorithms as found
with RFC2538 rather than expressing this as a textual
representation, suggests one area not well covered. This does not
require hindsight as OpenPGP has already has made an appropriate
choice for a binary resource record and binary representation of
algorithms. Following their example, it is already apparent what
should be done. When considering the servers and clients must be
modified anyway, switching to this resource record type to afford a
binary format puts DKIM in step with the rest of the industry.
Yes, but.
The binary formats we have in OpenPGP have their own set of issues.
It's easy to plop in an new algorithm identifier, but when it comes
to signatures, we also have to play, "Buddy, can you spare an OID?"
Furthermore, we end up needing to have things in text, too, because
people want to have that because the binary objects almost never
wander around naked; they're almost always armored or in clearsigned
form. RFC2538 pretty much has the same issues. There are other
virtues than saving a byte here and there. If you don't believe me,
look at how OpenPGP handles lengths. There is more complexity in
saving bytes there than anyone needs.
Jon
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html