Siegel, Ellen:
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org]
On Behalf Of Dave CROCKER
I think there are two sources of confusion for this round of ADSP
discussion.
The first is that the term "Author Signature" encourages one to think that
DKIM
is used to sign with the full author email address, rather than with the
/domain/ of the author's address. We fixed that error in the name of the
document, but forgot to carry it through to the details of the spec.
DKIM is about domains, not email addresses. And that's all ADSP should be.
Using i= encourages this cofusion. Using "Author Signature" rather than
"Author
Domain Signature" also encourages it.
[> ]
I think you may have put your finger on the root of much of the
interpretation differences. It might in fact be a really good idea
to replace the term "Author Signature" with the term "Author Domain
Signature" throughout the ADSP spec to help address this. It seems
like the only real "author signature" would be a PGP type signature
that is truly attached by the author rather than by some part of
the email infrastructure on behalf of the author. Since the
validated signing identity can only be a domain, it's inherently
misleading to use a signature label that implies otherwise. I
think we've all agreed that the information in i= is an assertion
made by the signing domain rather than a validated signing identity
in its own right, so we should make the spec terminology agree
with that clarification. That doesn't denigrate the usefulness of
that assertion data to various consumers, it just clearly
distinguishes it from the identity/identifier of the signing entity
itself.
The specification and semantics of ADSP get simpler, cleaner and properly
scoped, when d= is used. Using i= really does invite a complex of issues
that
should be outside the scope of DKIM and ADSP.
Use d=.
[> ]
+1
I am all for this.
+1
Wietse
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html