Jim Fenton wrote:
Here's alternate text based on d=:
=====
2.7 Author Signature
An "author signature" is a Valid Signature where the domain of the
signing entity ("d=" value) is the same as the domain name in the Author
Address. This comparison is case insensitive.
For example, if a message has a Valid Signature with the DKIM-Signature
field containing "d=example.com" then example.com is asserting that it
takes responsibility for the message. If the message's From field
contains the address "b(_at_)sub(_dot_)example(_dot_)com", that would mean
that the
message does not have a valid Author Signature because the message is
not signed by the same domain.
Informative Note: ADSP is incompatible with DKIM signing by parent
domains described in section 3.8 of [RFC4871] in which a signer uses
"i=" to assert that a parent domain is signing for a subdomain.
=====
Here is what I see are the problems with this alternative:
1. As noted above, the use of d= means that signing by parent domains,
specifically called out in RFC 4871, doesn't result in Author
Signatures. This is arguably less of a problem because "ADSP by parent
domains" (the ability of a domain to assert ADSP for a subdomain) was
eliminated some time ago, so ADSP records would need to each for each
subdomain. However, management of key (selector) records in each
subdomain would still be required, while ADSP records require little or
no management such as key rotation or revocation.
2. It has been noted that a domain might have different reasons for
signing a message. It might, for example, sign a message on behalf of a
mailing list manager operating in that domain. When Author Signature is
based on a d= comparison alone, any signature from the same domain as
the author is assumed to be a signature representing the original
introduction of the message into the mail stream. That may or may not
be an important distinction, but I'm pointing out that information is
lost and I'm not sure we have enough experience to say that we don't
need it.
I think these are addressed with an ADSP "valid signer domains" tag.
The only reason I recall for ditching this "list" idea in SSP was the
concern it can become large.
Well, honestly, if a domain was seriously interesting in controlling
who signs but has needs for additional signers, I seriously doubt most
of these domains will ever need more than X amount (or bytes worth),
whatever that value is. Even then, such a domain what main signer
needs, probably can still create extra records for more domains,
I think the benefits of this idea cover the needs of a much greater
majority of domains in the network who would never have more than a
small X amount of signers.
Plus, we can leave it open future exploration such as allowing for for
URN reference syntax to much larger list. I think this will be so
limited, but who knows.
I think we have one shot at this ADSP thing in this WG to get a RFC to
help compliant greater acceptance of DKIM). But some people already
believe its worthless. Well, sure. It was watered down so much, it
values was reduced drastically. Yet, as we witness, the 3rd party
issue still can not be eliminated. The needs are very apparent. But
now it seems we want to get rid of that too in the name of simplicity
and rubber stamping this document. I propose to give it some value
and reason to exist by reintroducing the signer list idea that
resolves the design people were attempting with i= for 3rd party signers.
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html