The document as it stands is fine, give or take a few wordsmithing
niggles. We'll probably want to add other key lookup schemes in a
future version of the spec, but not now.
I took a look at XKMS and I agree with Phill (alert the media!) that
if you're going to retrieve keys using a TCP session, you might as
well use XKISS LOCATE. But it is way premature to specify an XKMS
binding in DKIM now, in the complete absence of code for a DKIM
binding and experience with it.
The problem is that XMKS says a whole lot about the format and
semantics of the request and response sent to and from the web server,
but it doesn't say anything I can see about what URL to use. To do an
XKISS LOCATE, you send an http request to some URL which contains a
SOAP object in which the interesting field is KeyName, and it sends
back a SOAP object in which the interesting fields are KeyValue and
perhaps some others. In the response, I think the RSAKeyValue
subfields defined for KeyValue fields have the info we need, but I
sure would like to try it out before writing it into a spec.
I can think of a variety of ways to concoct the URL and KeyName, none
of which are obviously better than others. For example:
a) The URL is http://domainkey.<signing-domain>/ and the KeyName is the
selector
b) The URL is http://domainkey.<signing-domain>/<selector> and the
KeyName is the i= identity, or maybe the a= algorithm
c) The URL is found in a per-signing domain DNS record, like with IIM,
with the selector appended to the URL or maybe sent as the KeyName
d) The URL is found in a per-selector DNS record, same as dns
key lookup uses
As far as I can tell, any of those could work, but I can see good and
bad points about each (e.g., a and b introduce reserved names for web
servers, c and d require an extra DNS lookup, d further bloats the dns
method's record) and it seems extremely risky to try to standardize
one until we have the running code and experience. So don't.
R's,
John