Hi Dave,
I think you're making a reasonable point below about 4871.
Dave CROCKER wrote:
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.
Right. So if there's a significant concern (and I'm not sure how many
people share the concern) then I'd expect a thread on here aimed at
generating another erratum for 4871. My guess is that folks who are
ok with the status quo are likely to be silent, so I'd expect those
who are concerned to push that a bit.
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.
I don't think that noting that a spec (4871) that's been through
all our processes says "foo" is resolving anything by fiat, but
whatever.
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.
Could be. However, I don't think we need to halt all progress on ADSP.
We can and should clarify ADSP (e.g. as requested by Pasi) and then if
it turns out that a new erratum on 4871 is agreed, we may or may not
need to revisit something in ADSP.
Given where we're at in the process for ADSP, I would have thought that
those who feel that i=/d= needs clarifying in 4871 would try resolve
that as a matter of (relative) urgency. Otherwise ADSP is likely to
be in Pasi's queue for a long time.
Stephen.
d/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html