Just an addition to Michael's response:
--On August 1, 2005 4:37:15 AM +0200 Amir Herzberg
<herzbea(_at_)macs(_dot_)biu(_dot_)ac(_dot_)il> wrote:
Still new to DKIM (from draft-allman-dkim-base-00) so please bear
with me if I'm raising old issues; didn't identify them in the
archives.
Looking at section 6.3 `Get the Public Key`... two
questions/comments:
1. It says Verifier MUST retrieve public key... Always? Why not
include some key identifier and allow the verifier to use a cached
key (based on the identifier)? Of course, if key retrieval is using
DNS, then the DNS caching mechanism will also make this a local
operation. But I think there are several advantage to allowing a
key identifier and a key cache at the verifier. One motivation
follows.
You can use the selector and domain as a key identifier. You'll also
have to save the DNS TTL for flushing, but that's feasible.
2. There is an implied assumption here that we always use public
key signatures. Why rule out the use of shared key authentication,
for improved performance, e.g. in the (common) scenario of
authentication between the border MTA of two large ISPs (with long
term relationship)? Here, it may be desirable to avoid the key
retrieval (via DNS), as the key should be pre-shared anyway,
possibly first sending message with signature until the pre-shared
key is established.
Actually we don't rule it out at all. You could easily extend DKIM
to add another key algorithm. But I agree with Mike: if you have
pre-shared keys there are already other alternatives commonly
available.
eric