Doug,
Douglas Otis wrote:
Once DKIM considers how to handle cases where the signing-domain and
email-address domains are frequently different, then opportunistic
techniques like those found in SSH look better than some complex array
of DNS records. In the odd case where a domain is being phished, an
assertion carried within the signed message can indicate the required
bindings based upon a class of keys. These captured requirements would
then block all cases where the requisite bindings where not found.
So you want us to define a "deny service to everyone
else from this domain who doesn't have this key" field
which is included in a header, and then also have an
ssh like mode of operation where anyone (who can mess
with the headers) can introduce new keys? No thanks.
Not without it being a lot more worked out and
demonstrated-safe.
It is a wonderfully dangerous idea though but I think
I'd prefer doing it at a lower layer, maybe using
RFC 3514? :-)
SSH works in part because there's a human in the loop
when it matters. Such a situation doesn't arise here.
S.
_______________________________________________
ietf-dkim mailing list
http://dkim.org