On Feb 20, 2006, at 1:43 PM, Hallam-Baker, Phillip wrote:
Douglas Otis wrote:
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.
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.
2048 bits represents 256 bytes of binary data easily and reliably
stored using the #37 RR. In addition, the #37 Cert RR also provides
a method to reference other key acquisition options in the event
something is needed that DNS can not provide.
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-09.txt
Value Mnemonic Certificate Type
----- -------- ----------------
0 reserved
1 PKIX X.509 as per PKIX
2 SPKI SPKI certificate
3 PGP OpenPGP packet
4 IPKIX The URL of an X.509 data object
5 ISPKI The URL of an SPKI certificate
6 IPGP The URL of an OpenPGP packet
7 ACPKIX Attribute Certificate
8 IACPKIX The URL of an Attribute Certificate
9-252 available for IANA assignment
253 URI URI private
254 OID OID private
255-65023 available for IANA assignment
65024-65534 experimental
65535 reserved
With a draft describing the data structure, this could be expanded to:
Value Mnemonic Certificate Type
----- -------- ----------------
9 DKIM DKIM Binary Key
10 IDKIM The URL of a DKIM Key Server
My expectation is that you end up in TCP/IP fallback as mandated in
the original DNS spec at 500 bytes.
The minimum MTU of 576 bytes constrains DNS messages to 512 bytes.
If you can move packets of that size the need for binary encoding
vanishes.
If the goal is to handle 2k bit keys, the need for binary encoding is
paramount. Otherwise, something other than DNS is required, like a
key server or perhaps DNSsec. : (
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html