On Feb 21, 2006, at 9:10 AM, Hallam-Baker, Phillip wrote:
Douglas Otis wrote:
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
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
If the goal is to handle 2k bit keys, the need for binary encoding
is paramount.
I do not see the value in having a pointer to a CERT record with a
pointer to a cert over a pointer to the cert.
The suggestion for using #37 RR for offering a URL vector to the
"Next means of obtaining the DKIM information" was to circumvent
future hunting.
If the idea is to replace the existing key format with self signed
X.509v3 certificates it ignores the long (and justified) history of
ASN.1 hatred in the IETF.
A data structure defined by the #37 RR type is not limited to X.509
certificates. There are many experimental values for use, pending a
draft being accepted that defines a suitable DKIM public key binary
structure. The DKIM test server would need to transition from
accepting an experimental type value to the assigned value. To
further reduce DNS payloads, a signature conventions could
differentiate DKIM from that of DomainKeys, where then a label
"_dkim" could also replace the "_domainkeys" label where just #37 RR
would be obtained. The use of a binary key format from the outset
prevents the need for multiple lookups and better ensures use of 2048
bit keys will not become a problem. #37 RR more than doubles the
otherwise limited name space.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html