----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
1. Key Server:
1a. Do you agree that storing public keys in the DNS is
the way to go? or
1b Would using some form of HTTP retrieval or HTTP key
server be better?
If the question is one over another, I choose DNS (1a) simply because of
basic mail operation requirements.
Full blown Email Servers require a DNS server
as part of the setup already They don't need a
HTTP server for basic mail server operations.
If a HTTP server was the requirement, then no doubt, new issues related to
3rd party offerings will emerge.
2. Working group project management
2a. Should the working group focus on the current, DNS-based
mechanism now, and pursue additional mechanisms later? or
2b. Should the working group include development of a
non-DNS-based mechanism as part of its initial delivery?
2a is my practical answer, but I prefer 2b. I think you can satisfy this
today. I don't see why this can be part of the initial DKIM specification as
long as the input and output specfication is well defined by DKIM.
Thinking as a systems engineer, it should viewed as a black box callout
concept, possibly even an OPES callout concept if we are interested in
working together with other IETF WG converging technologies.
What this means is that the fundamental modeling could be specified as:
DKIM_POLICY = DKIM_CALLOUT(selector, domain)
Where
- DKIM_CALLOUT() function is defined by the signature "q=" tag,
- selector is the signature "s=" tag,
- domain is the signature "d=" tag, and
- DKIM_POLICY is a structure of policy tags and values,
Regardless of the CALLOUT methods, the input is the same and the output is
the same.
From a DKIM specification standpoint, in my view, all that needs to be
stated DKIM_CALLOUT() is by default a DNS query callout required by all
implementations, but this allows for future extended DKIM callout methods as
defined by the "q=" tag.
Possible wording:
"The DKIM_CALLOUT() method is by default a DNS query. All
implementations must support q=dns. DKIM signers who
defined an extended DKIM_CALLOUT() q= tag, must also
expose the same policy via DNS to handle situations where
the DKIM verifying server does not support the specified
DKIM policy query method specified in the q= tag."
I don't see why this can be part of the initial DKIM specification today
where it can be stated that extended methods would be documented in
separate EDKIM (Extended DKIM) query protocols.
What is common in the query protocols is the input parameters and output
result.
This allows Phillip to created a EDKIM query protocol using a tag such as:
q=xkms
Phillip's servers would expose the basic DKIM policy in DNS as well per
specification.
Downlink DKIM verifying servers who support xkms will follow Phillip's spec
for this DKIM callout method. Non-compliant q=xkms servers will fall back
to q=dns for the DKIM policy callout.
If we have this outlined, then in the future we would have the mechanism in
place to probably explore SOAP, XML or some UDP or TCP based DKIM callout
server.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com