ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft-levine-dkim-adsp-00

2008-05-24 14:29:50

On May 24, 2008, at 12:09 PM, Dave Crocker wrote:

Dave Crocker wrote:
apologies.  it pointed to the wrong document.  it's now fixed.

Folks,

I've added both inline and side-by-side versions of the rfcdiff  
output to the web page.

Dave,

Could you offer the same for:
  http://www.ietf.org/internet-drafts/draft-otis-dkim-adsp-02.txt

The HTML version is at:
  http://www.sonic.net/~dougotis/id/draft-otis-dkim-adsp-02.html

The diff between ssp-03 and this draft is at:
http://www.sonic.net/~dougotis/dkim/rfcdiff-ssp03-otis-adsp-02.html

This is similar to John's draft, but this draft limits ADSP to SMTP,  
and makes use of _normal_ RFC2821 validity checks.  No mission creep.

This draft also avoids restrictions on the DKIM identity parameters,  
since the _only_ relevant issue is whether a message should be signed  
by an Author Key Domain, and not whether the message affirms an  
Author's identity.  Non-essential identity requirements unnecessarily  
coerces author identity affirmation, erodes user privacy, and may  
break ADSP compliance.  Identity affirmation _must_ remain optional  
with or without ADSP.  Again, no mission creep.

Identity affirmation is evident whenever a DKIM signature's identity  
parameter can encompass an enclosed email-address.  Identity  
affirmation is fully independent of whether a message containing an  
Author Domain should have been signed by an Author Key Domain.   
Identity parameter restrictions by ADSP take DKIM beyond where the WG  
charter permitted, and may even require multiple signatures whenever  
an identity other than the Author is affirmed.  The signing domain  
should be free to decide on whose behalf the message is being signed  
without violating ADSP compliance.

Simply by making a requirement that a message containing an Author  
Domain be signed by an Author Key Domain, the Author Key Domain is  
able to curb fraudulent messages without also indicating the message  
is being signed on behalf of the Author.  Author identification is to  
be found with S/MIME or OpenPGP.  ADSP and DKIM should only ensure the  
Author Domain better controls SMTP acceptance of messages containing  
the Author Domain.  For whom the Key Domain signs on behalf of is  
their business.  ADSP should only be able to stipulate that a message  
containing an Author Domain should be signed by an Author Key Domain.

A definition of Author Key Domain is in this draft. For example, this  
also avoids references to "Alleged Author", as identity affirmation is  
_not_ the goal.

---

The relevance of this issue is important is better understood by  
reviewing a possible extension to ADSP.  While making this change,  
there also remains and error on the webpage 
http://www.dkim.org/ietf-dkim.htm#documents 
  that was mentioned when last seeing you in person.

Could you please correct the reference at:

http://www.dkim.org/ietf-dkim.htm#documents
,---
|Early SSP Proposals (replaced by draft-ietf-dkim-ssp)
|
|# DKIM Third-Party Authorization for Sender Signer Practices (TPA- 
SSP), draft-otis-dkim-tpa-ssp-00
'---

The draft-otis-dkim-tpa-ssp-00 never replaced nor was replaced by the  
ssp draft.  The draft's name has been updated and can be placed under:

Extensions to ADSP:
# DKIM Third-Party Authorization for Author Domain Signing Practices,  
draft-otis-dkim-tpa-adsp-00

  http://www.ietf.org/internet-drafts/draft-otis-dkim-tpa-adsp-00.txt

The HTML version is at:
  http://www.sonic.net/~dougotis/id/draft-otis-dkim-tpa-adsp-00.html


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