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:[EMAIL PROTECTED]]
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
