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
up.
Stephen,
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.
and
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
ambiguous interpretation.
What we are seeing, now, is that work on ADSP is (again) surfacing this basic
confusion.
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.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html