Subject: [ietf-dkim] draft-ietf-dkim-base-10 submitted

From: Eric Allman <[email-masked]>
Date: Fri, 16 Feb 2007 13:55:28 -0800

The DKIM base draft has been updated and submitted.  The changes are 
minimal, comprising response to IESG review and some XML updates 
intended to smooth the rfc-editor review.

Copies can be retrieved at:

  http://www.neophilic.com/~eric/DKIM/draft-ietf-dkim-base-10.txt
  http://www.neophilic.com/~eric/DKIM/draft-ietf-dkim-base-10.html

For once I pre-created the diffs:

http://www.neophilic.com/~eric/DKIM/draft-ietf-dkim-base-10-from-09.diff.html

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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 Feb 2007 09:46:45 -0500

> intended to smooth the rfc-editor review.

And the -base-10 draft is now on its way to the RFC editor queue,[1] 
having passed IESG review.  Many thanks to everyone who worked to get 
this done.  And now we just wait for the RFC editor process, and the RFC 
number for the Proposed Standard.

--
Barry Leiba, DKIM working group chair  ([email-masked])

[1] Here's the datatracker link:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14210&rfc_flag=0
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Feb 2007 15:01:01 +0000

> number for the Proposed Standard.

And get active on SSP again. (Or should I cancel the Prague meeting
slot? So far we've little to discuss it seems.)

S.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 21 Feb 2007 10:29:17 -0800

On Feb 21, 2007, at 7:01 AM, Stephen Farrell wrote:

>
>
> Barry Leiba wrote:
>>> The DKIM base draft has been updated and submitted.  The changes  
>>> are minimal, comprising response to IESG review and some XML  
>>> updates intended to smooth the rfc-editor review.
>> And the -base-10 draft is now on its way to the RFC editor queue, 
>> [1] having passed IESG review.  Many thanks to everyone who worked  
>> to get this done.  And now we just wait for the RFC editor  
>> process, and the RFC number for the Proposed Standard.
>

Devote some time resolving how DKIM verifiers should configure  
"unlikely" or "unacceptable" domains.  Is there a recommended format  
for the list?  Perhaps this list could be called the Minimal Domain  
Depth (MDD) or something.  Should this list preclude known second and  
third level domains, or just TLDs?  Should this list be handled by  
IANA?  If so, there should be a corresponding draft.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 21 Feb 2007 13:38:15 -0500

> IANA?  If so, there should be a corresponding draft.
Is this in the DKIM-base or -ssp requirements drafts?  What paragraph please?

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Wed, 21 Feb 2007 11:06:11 -0800

> Is this in the DKIM-base or -ssp requirements drafts?  What  

Consistent interchange or compatibility can not be established for  
DKIM without "unacceptable domains" or "unlikely domains" being  
commonly defined.  This is a rather fundamental requirement  
introduced  two places within the base-10 draft, 6.1.1.  Validate the  
Signature Header Field, and 8.13.  Inappropriate Signing by Parent  
Domains.

-Doug

---

From: <[email-masked]>
Date: Wed, 21 Feb 2007 14:17:56 -0500

Doug,
Are you suggesting a methodology should be applied to a form of
blacklist that DKIM would/should reject?
Thanks,

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Douglas Otis
Sent: Wednesday, February 21, 2007 1:29 PM
To: Stephen Farrell
Cc: Barry Leiba; IETF DKIM WG
Subject: [ietf-dkim] Configuring "unacceptable" domains

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 21 Feb 2007 11:36:04 -0800

> blacklist that DKIM would/should reject?

The accepted DKIM base draft included text where "unacceptable" or  
"unlikely" parent domains are to be excluded as part of a verifier's  
configuration.  I assume this is to exclude domains used by  
registries.  If "co.uk" is "unacceptable", then other domains also  
"unacceptable" as signing parents should be listed.  This list should  
be documented to permit reliable interchange.  Such a list could  
prove useful for qualifying valid domains as well, as presumably all  
valid top, second, and third level domains would be defined by such a  
list.

My preference would have been to define a method where originating  
domain explicitly authorizes the signing domain when they differ,  
which can be accomplished while also providing policy related  
information.  The DOSP was such an effort.

-Doug