On Aug 31, 2006, at 5:09 PM, Douglas Otis wrote:
Interesting. A new RR type must be used. Are the issues related
to a new RR type resolved?
Rather than dropping characters in the local-part section, this
might impose a security problem when a character repertoire in the
local-part is unknown. DNS permits case-folding. Even without
case folding, the DNS code space represents about 25% of the
possible code points. It would be safer using base32 encoding.
This encoding could provide a means to concatenate up to a maximal
domain name size and still provide about 100 byte answers. With
base32, 63 bytes can encode 315 bits which represent 39 bytes and 3
bits. This would represent a 62% increase in the label size
needed. The padding for the base32 could not be "=" as defined in
rfc3548, but instead could be "8" for padding. Use of "_user"
reduces available name space by 6 bytes. The draft did not
indicate whether truncation removed the left-most or right-most
portion of the local-part. Consider the answer carefully. How is
truncation assured to occur at the same limit uniformly among the
verifiers?
On second thought. To always ensure a consistent query size, pass
the local-part address through an sha-1 hash and then encode this
into base32. This will produce a consistent 32 byte label size that
also does not expose the underlying local-part address. The risk of
collision is fairly small.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
