ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Resigner Support of RFC 5617 (ADSP)

2009-10-11 18:51:36
First, I was probably and still am, the biggest promoter for 3rd party 
considerations, even wrote the DSAP proposal. So I was not too happy 
with ADSP with its exclusion of 3rd party considerations.

Second, I think the Hector/Levine interpretations are the same as it 
was always expected.  Unlike SSP, ADSP was 100% never about 3rd party 
signatures.

But its never going to be a surprise to me that others, such as 
yourself, will desire 3rd party considerations.  That was the problem 
with ADSP - its ignorance of this very high potential and worst, its 
lack of support by its author which doesn't help the process.

So what happen?

DKIM become a hop to hop resigning concept. ADSP POLICY in inherently 
conflictive with this.

A mailing list is just one form of a resigner.  You don't have to a 
mailing list server to be a DKIM resigning clearing house.

So again, as strong supporter of policy, how do authorize the resigner.

With all the work done over the last few years, I think simplest 
solution to add two new policies:

   DKIM=NEVER
   DKIM=ALWAYS

DKIM=NEVER is designed for the migration market who wish to add DKIM 
signing support to their domains but during the migration or 
development period, they want a policy that says this DOMAIN never 
signs its mail.

DKIM=ALWAYS says my mail is always signed by someone.

I always felt the benefits are not in proving the positive assertion 
by proving the negative assertion or deviation from the assertion.

In other words, a VALID 1st or 3rd party signature proves nothing. 
Reputation or Domain Certification helper technology of some sort is 
still required.

But for failures, there is a strong assertion that it is not what the 
domain expected.

o Current Policies:

DKIM=DISCARD

    When no 1st party signture is found - REJECT

DKIM=ALL

    When no 1st party signature is found - No Semantics.

o Extended Policies:

DKIM=ALWAYS

    When no signature is found - REJECT

DKIM=NEVER

    When a signature is found - REJECT, not expected must be spoof.

Hope this clarifies my position.

--

Michael Deutschmann wrote:

On Sun, 11 Oct 2009, Michael Thomas wrote:
On 10/11/2009 02:41 AM, Michael Deutschmann wrote:
If this is indeed the official semantics of the protocol, then I would
petition to add a "dkim=except-mlist" policy.  Which means "I sign
everything that leaves my bailiwick, but may post to signature-breaking
MLs."
No need. That is exactly what the semantics of "all" is.
That appears to be a contentious issue.

While I don't think the Hector/Levine interpretation is very useful, I
think it would be a sound strategic move to yield to them regarding
dkim=all, and instead create our own dkim=except-mlist space where our
semantics are in place with *no ambiguity*.

---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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