[ietf-dkim] Next steps for draft-ietf-dkim-ssp
dhc at dcrocker.net
Wed Jan 7 07:02:51 PST 2009
Stephen Farrell wrote:
> I don't believe this discussion is necessary in order to progress the ADSP
> draft, which, for better or worse, is where the WG's rough consensus ended
Happily, a community learns things about specifications as time progresses.
Sometimes that learning uncovers problems and the problems get resolved. For
example, that's was RFC Errata are for.
In the current case, this is a rather fundamental and persistent confusion in
the community about DKIM's "output".
The Signing specification states:
> 1. Introduction
> DomainKeys Identified Mail (DKIM) defines a mechanism ...
> permitting a signing domain to claim
> responsibility ...
> Message recipients can ... confirm that the
> message was attested to by a party in possession of the private key for the
> signing domain.
> 1.1 Signing Identity
> DKIM separates the question of the identity of the signer of the message from
> the purported author of the message. In particular, a signature includes the
> identity of the signer. Verifiers can use the signing information to decide
> how they want to process the message. The signing identity is included as
> part of the signature header field
This language declares that the result of a DKIM verification is an identifier
that declares some responsibility.
The question, now, is which string represents that identifier?
The fact that there are serious, knowledgeable folk who declare it is the d= tag
and other, equally serious and knowledgeable folk who declare that it is the i=
tag, and that there are substantial numbers of each means that we have a real
and basic problem:
The community does not currently have consensus about
where to find the one value that is DKIM's output!
This is not something that can get resolved by fiat, Steve, such as saying that
a prior decision by the working group resolves the matter. And it is not
something that gets resolved by one or another person pointing to some other
language in the Signing spec and declaring that it provides the one true answer.
If the real world has competing interpretations of the spec, then the spec will
not be used in a consistent matter. And it's difficult to find a more serious
problem with a specification, since it means that the core semantic has
What we are seeing, now, is that work on ADSP is (again) surfacing this basic
Approving ADSP, in the absence of resolving this basic confusion about what
value to use, merely entrenches the confusion further.
It doesn't actually resolve it.
More information about the ietf-dkim