ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Consensus point on ADSP

2009-03-28 06:41:50
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

<Prev in Thread] Current Thread [Next in Thread>