Subject: Re: [ietf-dkim] binary DKIM key

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 23 Mar 2006 15:23:16 -0800

The real problem is the policy record.

We can probably get the key record transition to happen because it will coincide with rollout of new algorithm. Probably dsa2048 with 64 byte signatures. We can just about do them with bas64 but I would argue that dkim deployment will drive dnssec which will solve the rr introduction problem (not least because we should have our record defined before dnssec deploys.

The priority should be deploy dkim.

 -----Original Message-----
From: 	Michael Thomas [mailto:[email-masked]]
Sent:	Thu Mar 23 13:05:11 2006
To:	Hallam-Baker, Phillip
Cc:	Douglas Otis; IETF-DKIM
Subject:	Re: [ietf-dkim] binary DKIM key

Hallam-Baker, Phillip wrote:
> The problem here is that there is a big difference between what some people
> choose to believe and reality. I do not see how any competent network op is
> going to enter DKIM RRs if they are going to require changing their DNS
> server to BIND (a huge issue for an active directory shop) or using the
> proposed kludge of injecting the new RRs into the server each time it
> restarts via Dynamic DNS. This is simply not production level support for
> new record types.

While I don't dispute the overall jist of your post, it should be noted
that situation with DKIM is better off than MARID because a domain can
always delegate the _domainkey subdomain to something that's a bit more
cooperative. This was, in fact, how we finally managed to get our
enterprise management IT folks to support us -- they're being highly
allergic to anything beyond A records in their database.

		Mike

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html