On July 25, 2005 at 22:06, "James Scott" wrote:
For example, the "d=" tag can be described as:
The identity of the signing agent.
Within the DNS query method, this will be the domain name of the
signing agent, which will be queried for retrieving the public
signing key. The domain provided MUST be the same as or a parent
domain of the i= tag.
I think that the "i=" tag is more correctly described as the signing agent
and that the "d=" tag should be derived from the "i=" value. Perhaps "i="
should be REQUIRED, while "d=" is OPTIONAL (or is REQUIRED for DNS key
retrieval).
Nope. The i= tag identifies the sender/author. Quoting from
the draft:
Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed.
d= represents the signing agent. As of now, DKIM restricts the signing
agent to be in the same domain, or parent domain, of sender/author.
I think this restriction has some usability problems, but that is a
another debate.
... BTW, I see the "q=" tag as more
of a PKI implementation identifier vs a "query method".
A more fundamental question is whether the proposed charter is in conflict
with the "q=" tag. The proposed charter states
"Keys will be stored in the responsible identity's DNS hierarchy."
So why have a "q=" tag at all?
I think it is mistake to artificially constrain things when there is
no cost to making things more flexible. The charter implies that the
initial deliverable will be based on a DNS PKI, but that does not
prohibit developing specs that support alternatives in the future.
Right now, the draft is written with alternatives/extensions in mind,
but I think it could use some "beefing up" in this area.
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".
I assume that any proposal to use a value (other than the default "q=dns")
will be able to specify how to retrieve the key, and what interpretation
should be placed on ancillary tags such as "d=" and "s=". The
interpretations in such cases may be different from that specified in the
draft.
Yep.
Perhaps the charter should be amended to reflect that alternative (to the
default DNS) key retrieval mechanisms may be defined through future working
group process. This would be preferable to removing the "q=" tag from the
specification, as such action would severely restrict the ability to
flexibility develop the specification.
Sounds good to me.
--ewh