On Feb 22, 2006, at 9:35 AM, Dave Crocker wrote:
Well, it's not *exactly* it: there's still SHA-1. Two upgrades in
the space of a few years is going to be painful. Maybe inevitable,
but still painful.
DKIM's base spec already has a mechanism that supports alternate
algorithms.
Are there any changes to the mechanism that anyone is suggesting?
There are two serious issues this problem raises with respect to the
current mechanism. A default and MUST accept SHA-1 in the key would
be one, where typically the hash is only expressed within the
message. The use of the TXT RR also precludes an upgrade to the use
of 2048 bit keys. There is a simple and immediate remedy for this
problem. Rather than adopting the TXT record and expecting defaults
are okay, both issues are resolved by adopting the use of RFC2538
RR. This would allow both a binary image of the public key which
saves 90 bytes of DNS payload. At the same time, this RR record also
explicitly specifies the algorithms by indexing into an industry
standardized list rather than attempting to express these textually
where there is insufficient space for doing so. In short, the
currently proposed mechanism for changing algorithms needs to be fix.
For an example of this RR being used to obtain the public keys for
OpenPGP, here are some related links:
http://josefsson.org/cks-dns/
http://sourceforge.net/projects/cks/
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html