On July 29, 2005 at 17:21, Dave Crocker wrote:
The existence of this tag automatically opens up DKIM to alternative key
storage/retrieval mechanisms.
Yep, and the draft implies this, but in a restrictive matter; mainly
due to the wording chosen. The wording is limited to "retrieving
the public key".
...
what changes to the language of the specification are suggested?
I made a suggestion here,
<http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=ietf-mailsig&i=200507250419.j6P4JWt28260%40gator.earlhood.com>
on the type of wording that can be used. I only provided possible
rewording for the d= tag, but was waiting to see if such rewording
is acceptable before spending time on rewording other parts of the
DKIM draft.
In sum, since alternate PKI methods may exist in the future, the core
DKIM specification should be worded to clearly indicate parts that
are associated with the "DNS query method".
It should be possible, and subsequently considered, that the
DNS query method should be described in a separate section vs
intermingling it throughout. Such separation clearly shows which
parts of the core DKIM spec are part of the DNS PKI method. It
also serves as a template for future specifications that define
alternative PKI methods.
For example, the d= and i= tags can be described as follows:
d=
The identity of the signing agent.
i=
Identity of the user or agent (e.g., a mailing list manager)
on behalf of which this message is signed
That's it. Then in the DNS PKI section, the structure of i= and d=
tag values are further defined along with how they are interpreted.
Now, it could be determined that d= should always equal the domain
of the signing agent, regardless of the PKI method. However, text
like:
This is the domain that will be queried for the public key.
Should be in the DNS PKI section since it refers to key retrieval,
and anything related to key retrieval and management is defined by
the PKI method in use.
If any of what I said sounds reasonable to you, I can devote time in
providing more detailed suggested rewording and restructuring of the
DKIM document.
--ewh