On Mon, 25 Jul 2005, James Scott wrote:
Earl Hood wrote on Monday, 25 July 2005 4:20 p.m.
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).
I'm not sure it should even be required for dns retrieval, "s" tag is
enough and few special cases can be dealt with with using SRV records.
... 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."
The charter is written to allows to "put stamp of approval" (in the words
used by several other people) to DKIM and is opposite to the usual intent
of IETF to actually develop the technology allowing to look for alternatives
(both in terms of not being encumbered by patents and in terms of
technology itself)
There was no agreement from this mail list that storing public keys in
dns is the way to go. In fact if anything arguments had been given that
it is not the best way to create PKI architecture and that using some form
of HTTP retrieval or HTTP key server would be better. DKIM also uses DNS
in the way it was not designed for (to say the least because putting large
public key data in dns for every domain is really not the way to go).
So why have a "q=" tag at all?
The existence of this tag automatically opens up DKIM to alternative key
storage/retrieval mechanisms.
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=".
DKIM specification is not very good at explaining how to deal with new
tags (including ones that maybe defined for its extensions). I think
I pointed it out but Thomas did not understood me.
The interpretations in such cases may be different from that specified
in the draft.
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
I would rather have explicit saying that group will look and define
several alternative, easy to implement methods for retrieval or
verification of signature public key, but that group would not avoid
defining new protocols for that purpose (i.e. limit to using existing
protocols to achieve results - we have enough at IETF to choose from).
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net