Subject: [ietf-dkim] New Issue: Development & Deployment guide improperly uses normative language

From: Eliot Lear <[email-masked]>
Date: Fri, 21 Mar 2008 13:58:06 +0100

In numerous places the development and deployment guide makes use of RFC 
2119 language that is vague in its meaning.  For example:

   In particular, great care MUST be taken when
   releasing memory pages to the operating system to ensure that private
   key information is not disclosed to other processes.

This actually tells the implementor very little.  My recommendation 
would be to change to "must".

Similarly:

   As with the signing process, choice of service venues for
   verification and assessment -- such as filtering or presentation to
   the recipient user -- depend on trade-offs for flexibility, control,
   and operational ease.  An added concern is that the linkage between
   verification and assessment entails essential trust: the assessment
   module MUST have a strong basis for believing that the verification
   information is correct.

Without giving an inkling as to what a strong basis is, the MUST should 
be a "must".  In this case, it seems to me that we're also in the 
department of obviousness.

And above that text:

   In particular, verifiers SHOULD NOT automatically assume that an
   email message that does not contain a signature, or that contains a
   signature that does not verify, is forged.  Verifiers should treat a
   signature that fails to verify the same as if no signature were
   present.

Here we have inconsistent use of "SHOULD NOT" and "should".

In Section 3.2.3 we see the following:

   In order for an assessment module to trust the information it
   receives about verification (e.g., Authentication-Results headers),
   it MUST eliminate verification information originating from outside
   the ADMD in which the assessment mechanism operates.

What is "it"?  Pronoun failure.  Also, how is this boundary drawn, and 
are we drawing text from Murrary's draft or should this section merely 
reference that document?

Finally, overall I believe that BCPs should not contain normative 
language relative to how to implement.  That information belongs in a 
standard.

Eliot

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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 21 Mar 2008 15:12:48 +0100

Hi John,

> Channeling Dave here, 2119 language is case independent, i.e., must
> and MUST mean the same thing, and the capitalization just calls it
> out.  In the current -ssp draft I looked for places that used 2119
> words and either capitalized them if they were giving advice on making
> implementations interoperate, or rewrote them to use other words if
> not.
>   

I would be okay with the use of other words.

Eliot

---

From: John Levine <[email-masked]>
Date: 21 Mar 2008 13:56:57 -0000

Lots of existing BCPs include 2119 normative language, so that
argument appears already to have been decided, but I agree they're
overused here.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Mar 2008 08:35:16 -0700

John Levine wrote:
> out.  

John forgot to list my +1, so here it is.

> argument appears already to have been decided, but I agree they're

IMO, cConfusion about the unimportance of case, for reserved normative terms, 
has made it essential to use those terms only for normative purposes, and to use 
other words for non-normative meanings.

Interestingly, the exercise of replacing normative terms for non-normative ones 
often results in clearer and more precise meaning, IMO.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: <[email-masked]>
Date: Fri, 21 Mar 2008 10:08:42 -0400

In particular, great care MUST be taken when
   releasing memory pages to the operating system to ensure that private
   key information is not disclosed to other processes.
Should be changed to
If one does not clearly understand how computers work you MUST NOT try
to create security programs for 3rd party use. 

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

---

From: "J D Falk" <[email-masked]>
Date: Tue, 25 Mar 2008 13:59:19 -0400

> to create security programs for 3rd party use.

+1

---

From: SM <[email-masked]>
Date: Tue, 25 Mar 2008 11:53:05 -0700

>to create security programs for 3rd party use.

Although the proposed text a good recommendation, it's not the type 
of wording for a RFC.

Regards,
-sm