Subject: [ietf-dkim] dkim-base-01 nits and semi-nits

From: Jim Fenton <[email-masked]>
Date: Fri, 28 Apr 2006 16:47:30 -0700

Here are some things that I noticed on a pass through dkim-base-01. 
Some of these are clearly nits and for others it's less clear, but I
have tried to steer clear of things that I know will be controversial. 
Feel free to comment on any of these if appropriate.  Apologies to any
whose comments I may have duplicated.

Section 1.1 paragraph 1 is now different from the overview in -threats. 
We were trying to keep the top-level description consistent  between the
drafts; was this a conscious change?

Section 1.1 bullet 1 suggest "written to the message header fields" ->
"written as a message header field"

Section 1.1 bullet 7 and bullet 9 seem redundant

Section 1.3 seems like it should say something about DKIM's scalability
characteristics, not just that of email, since the other 1.x sections
are describing DKIM in various ways.

Section 3.1 The INFORMATIVE IMPLEMENTERS' NOTE seems like it would fit
better later in the document such as section 3.6.

Section 3.4 paragraph 5 "Only header fields listed as signed in the
signature header field are included"  should say something about the
inclusion of the signature header-field itself, since it's not listed.

Section 3.4.2 last paragraph "the previous version" -> "a previous version"

Section 3.4.5 second to last paragraph "choose to reject" -> "choose to
ignore signatures"  [this one isn't a nit]

Section 3.6 i= tag INFORMATIVE DISCUSSION:  Does XREF-TBD refer to the
overview document?  Would this create a publication dependency on that
document?

Section 3.7 paragraph 3 "using the header canonicalization" -> "using
the body canonicalization".  "XXX=" -> "bh="

Section 4 paragraph 3 "DKIM-Signature headers" -> "DKIM-Signature header
fields", "if they know that the headers cannot be verified" -> "if they
know that the signatures cannot be verified"

Section 9.2 Date on dkim-threats-02 is April 2006.  Citation on RFC3766
is a little terse (!)

Section A.3 "_dkim" -> "_domainkey" (as others have pointed out)

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

---

From: Eric Allman <[email-masked]>
Date: Fri, 28 Apr 2006 17:18:33 -0700

Jim, thanks for the comments.

> Section 1.1 paragraph 1 is now different from the overview in
> -threats.  We were trying to keep the top-level description
> consistent  between the drafts; was this a conscious change?

I don't remember exactly how this came about.  I'm happy with 
changing it back for consistency, having threats change to be the 
same as base, or agreeing to let them drift.

> Section 1.1 bullet 1 suggest "written to the message header fields"
> -> "written as a message header field"

Done.

> Section 1.1 bullet 7 and bullet 9 seem redundant

I think they are slightly different.  Bullet 7 says that you can get 
results without updating the clients.  Bullet 9 says you don't have 
to update all your MTAs at once.

> Section 1.3 seems like it should say something about DKIM's
> scalability characteristics, not just that of email, since the
> other 1.x sections are describing DKIM in various ways.

Hmm....  It also says that the any-to-any characteristic is 
important, which might not be true for other services.  Any suggested 
wording?

> Section 3.1 The INFORMATIVE IMPLEMENTERS' NOTE seems like it would
> fit better later in the document such as section 3.6.

I couldn't quite get this to flow very well.  It doesn't belong under 
"Textual Representation" or "DNS binding" because the point is 
independent of how the record is represented or delivered.  It just 
doesn't seem to "fit" in the overview.  Perhaps I'm missing something.

> inclusion of the signature header-field itself, since it's not

I added "Note: the signature header field itself is presented at the 
end of the hash, not with the other headers."

> Section 3.4.2 last paragraph "the previous version" -> "a previous

Actually, that entire clause can be deleted at this point.

> Section 3.4.5 second to last paragraph "choose to reject" ->
> "choose to ignore signatures"  [this one isn't a nit]

I'm not sure we have consensus on dropping the "reject" language --- 
I think Mark had some concerns.  I'll add wording about ignoring the 
signature though.

> Section 3.6 i= tag INFORMATIVE DISCUSSION:  Does XREF-TBD refer to
> the overview document?  Would this create a publication dependency
> on that document?

Probably.  I'll just remove that reference; we can add it back in if 
that document appears before base publishes.

> Section 3.7 paragraph 3 "using the header canonicalization" ->
> "using the body canonicalization".  "XXX=" -> "bh="

Already got it.

> Section 4 paragraph 3 "DKIM-Signature headers" -> "DKIM-Signature
> header fields", "if they know that the headers cannot be verified"
> -> "if they know that the signatures cannot be verified"

Damn.  Tricked again.

> Section 9.2 Date on dkim-threats-02 is April 2006.  Citation on
> RFC3766 is a little terse (!)

Thanks on the date.  At some point I managed to get some tool (I 
thought it was the xmlrfc plugin for XMLEditor, but apparently not) 
to look up the references and include all of the detail.  If anyone 
recalls what that is, I would appreciate it.

> Section A.3 "_dkim" -> "_domainkey" (as others have pointed out)

Got it, thanks.

eric

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 Apr 2006 17:34:54 -0700

> same as base, or agreeing to let them drift.

The base draft is what I thought I was agreeing to at the Dallas  
meeting.  The Threat draft is not correct in my view.

-Doug

---

From: Mark Delany <[email-masked]>
Date: Sat, 29 Apr 2006 00:50:15 +0000

> I think Mark had some concerns.  I'll add wording about ignoring the 

My only concern is to ensure we're not prescriptive to a
verifier. Anywhere we say "reject" probably should be changed to
"treat as unsigned" as long as there is no implication one way or the
other as to what a verifier does with that "is verified" or "is not
verified" knowledge.

Similarly, there should be no "accept" language.

In general, verifier actions are out of scope.

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Apr 2006 12:23:59 -0700

> other as to what a verifier does with that "is verified" or "is not

Thank you.  We keep confusing the base signing/validating specification 
with larger policy uses of a signature. 

We really need to keep the base specification a simple, narrow and 
mechanical as possible.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>