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