On Feb 22, 2006, at 2:29 PM, Jon Callas wrote:
On 22 Feb 2006, at 1:03 PM, Douglas Otis wrote:
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?"
OID information would not be needed with DKIM public key
information. Consider the DKIM public key cert isomorphic to that of
OpenPGP.
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;
Being able to store keys and algorithms in binary form spares more
than 100 bytes, which likely represents the difference between DKIM
still working or not after an upgrade in algorithms, even when some
fields are defined as holding text. 500 bit keys should already be
considered as not providing a valid signature. A binary TLV
structure is simple, extensible, and commonly used.
There is more complexity in saving bytes there than anyone needs.
Software for dealing with this RR in binary form is already
available, and binary information is ideal for computers. It would
be a terrible mistake to think DNS payloads will increase size before
needing to utilize larger keys or different algorithms.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html