The CERT RR is utterly useless for our purposes unless you are confident
in the ability of DNS to move DNS messages of at least 2Kb reliably. My
expectation is that you end up in TCP/IP fallback as mandated in the
original DNS spec at 500 bytes.
If you can move packets of that size the need for binary encoding
vanishes.
All the other claims and conclusions reached by Doug are hereby rejected
and refuted as if set out here seriatim.
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Douglas Otis
Sent: Monday, February 20, 2006 4:14 PM
To: Tony Hansen
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] small question in
draft-ietf-dkim-base-00.txt on TXTrecord
On Feb 20, 2006, at 12:49 PM, Tony Hansen wrote:
We allow extra options to be specified in a DKIM-Signature
header, but
do not allow extra options to be specified in a DKIM TXT record. (I
don't recall this being discussed before, but just may not remember
it.) Should we? If not, how would we do upwardly-
compatible changes
without requiring multiple DNS entries for both an old and
new entry.
DKIM should specify a binary structure used with the CERT RR.
This RR already offers fields defining the critical hash
algorithm, for example. By just specifying the hash used in
signature header, once a hash algorithm is later discovered
compromised, there is no means to keep bad actors from using
this compromised hash algorithm for spoofing messages. It
would appear the DKIM draft is not ready.
-Doug
_______________________________________________
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