I confess that I don't understand the advantages of
using something like HTTP to retreive the keys.
Being TCP based, it sounds pretty heavy weight.
I'm open to explanations though.
There will definitely be an HTTP based key-fetching mechanism someday for
use with DKIM. It's beneficial especially for customers like mine who are
SMB organizations without direct access or special knowledge about DNS.
Imagine trying to do per-user keys or even per-domain keys that expire
frequently using DNS as the key server. Now imagine having to do that for a
company that doesn't run it's own DNS and has to ask their ISP every time
they want a change. I'm supporting over 50,000 such companies today. This
is the burden of using DNS as the key server. If you could use HTTP instead
you can create a system based on the simple HTTP GET command which gets the
key record from your HTTP server rather than from your DNS server. I'm
planning to experiment in this area because my MTA also has an HTTP server
already and HTTP GET is very easy to use. For me, it's very easy to
envision - rather than call a function to query DNS for the key, call a
function to HTTP GET it instead. The GET will return the exact same key
record string that the DNS query would return - so, no change there at all.
The benefits are that I can make an HTML interface for key management
allowing my users to easily add/change/delete keys using familiar and
accessible web-based techinques rather than difficult and mostly
inaccessible DNS.
--
Arvel