This particular draft simply rescues some 10 year old text from a draft of
dnssec that has been otherwise rendered obsolete.
It is not a particularly useful approach as certs tend to be much bigger than
500 bytes or for that matter the ethernet mta. If you back off to tcp you might
as well go to http and get out of the dns straightjacket or do ldap if you want
more selectors.
It is certainly not a replacement for the dns key record. If it was supported
today there would be an argument for using x.509 as if it was simply a big key
package. The asn1 would be less overhead than base64 but you still have to sign
the cert...
This made a lot more sense when first proposed, keys were shorter and there was
less mechanism in pkix. As is the rr is a bit of a pig in a poke, it is enough
extra mechanism to be a pain but not enough to provide extra value
-----Original Message-----
From: Mark Delany [mailto:MarkD+dkim(_at_)yahoo-inc(_dot_)com]
Sent: Mon Nov 28 11:06:28 2005
To: IETF DKIM pre-WG
Subject: Re: [ietf-dkim] RFC relevant to DKIM DNS RR effort
On Mon, Nov 28, 2005 at 10:36:19AM -0800, Dave Crocker allegedly wrote:
Folks,
For those not on the IETF Announcement list, the following is relevant to
the DKIM DNS RR effort:
The IESG has approved the following document:
- 'Storing Certificates in the Domain Name System (DNS) '
<draft-ietf-dnsext-rfc2538bis-09.txt> as a Proposed Standard
Yeah. I've looked at this, along with a good number of other
efforts. The question arises as to whether Selector attributes are the
moral equivalent of certificate attributes.
Consider that an rfc2538 RR consists of four fields: type, tag, alg
and cert. This means that we'd have to embed all of the Selector
attributes into the cert blob and thus we still have to define the
format of that blob such that it can handle the attributes we need.
The second issue this raises is that we aren't taking full advantage
of the type matching capability of DNS. We still need to sub-type
search to ensure that the returned CERT RRset contains a DKIM cert
unless we continue to insist on namespace separation. I'm under the
impression that this type of sub-typing is not viewed favorably.
Mark.
_______________________________________________
ietf-dkim mailing list
http://dkim.org
_______________________________________________
ietf-dkim mailing list
http://dkim.org