On Tue, 31 Oct 2006 06:27:14 -0000, Eliot Lear <[EMAIL PROTECTED]> wrote:
Hi Charles, and welcome. I can't answer many of your questions, but I
can certainly take a whack at a few.
3.5 The DKIM-Signature header field
Can the various tags appear in this header in any order? OTOH, why is
there not an insistence that the b= tag should come last (since it has
to
be easily joined to and separated from the rest)?
I can't speak to anyone's implementation, but general SMTP folding rules
apply, no?
Yes, sensible folding would help. But it would make life easier for
implementors if the b= tag was always last. That is, in any case, where
most implementors are likely to put it simply because that is easiest, and
it is also the easiest place to ignore it when a verifier needs to grab
everything in the header _except_ that bit when constructing its hash.
l= Body length count
INFORMATIVE IMPLEMENTATION WARNING:
I am very suspicious of the propriety of suggesting, in any IETF
standard,
that it is legitimate to remove text from a message being conveyed
(certainly without the consent of the recipient). Surely marking it with
blood-red ink, or warnings in 32pt characters is as far as one should
go?
What if it's executable code inserted by an attacker?
A fair point, but labelling it clearly should surely be enough. One
application of this tag is apparently for boilerplate added by a mailing
list expander, and if that boilerplate is there, it is presumably intended
that people should read it, and the list admin is entitled to be miffed if
the recipients do not even get to see it.
z= Copied header fields
Verifiers MUST NOT use the header field names or copied values
for checking the signature in any way. Copied header field
values are for diagnostic use only.
Why ever not? I can think of examples where a verifier might find it
exceedingly useful to be aware of the original state of some header
which
might have been changed somewhere en route. And what potential
interoperability arises if a verifier makes some use of this
information?
Because z= field does NOT get rendered to the user, but rather the real
header fields will. It makes no sense that the z= field should be
verified and the others are not. Allowing otherwise would provide for a
malicious opportunity.
Yes, but it is the policy module of the verifier, rather than the user,
which might find it useful. Some headers may legitimately get changed en
route. These should probably not be signed, but knowing what such a header
originally looked like might enable the policy module to spot some unusual
situation and work around it. The example I have in mind is the use of
UTF-8 in headers, being worked on by the ietf-EAI WG, where a message with
'internationalized' headers will have a special header
Header-Type: UTF8
If that message has to be downgraded en route, because it meets a legacy
MTA that does not support UTF8, then that header gets changed to
Header-Type: Downgraded
If a verifier can detect the change in that header, it can try to
'upgrade' the message to its original form before checking the signature.
I am not saying that is the only way that UTF8 headers might be made to
work with DKIM, but it is certainly one possible approach that should be
looked at.
3.6.1 Textual Representation
h= Acceptable hash algorithms
... Signers and Verifiers MUST
support the "sha256" hash algorithm. Verifiers MUST also
support
the "sha1" hash algorithm.
Why MUST signers support the "sha256" hash algorithm (clearly, verifiers
MUST)? Surely a signer who, as a matter of policy, always chooses to use
sha-1 is not obliged to implement something he is never going to use?
Again, for interoperability. We picked one. That was the one.
I think you misunderstand my point. AIUI, a signer is allowed to choose
either sha-1 or sha-256. So evidently all verifiers MUST be able to accept
whichever of those turns up.
But if a signer decides "my policy is always to use sha-1" then what is
the point of saying he MUST include code in his implementation which he is
never going to use. RFC 2119 says you can only say "MUST" where there is
the possibility of some interoperability problem or other harm. But in
this case there would be no way for an outsider with no access to the
signers machine to be aware that he had omitted that code. Hence the use
of "MUST" for the signer is meaningless, since violating it produces no
visible effects.
The same argument applies to the places where it says the signer MUST
support dns/ext and rsa. In those cases too, it is only the verifier who
MUST support everything the signer is allowed to send.
I'm sorry, but I've run out of time and must be on a plane shortly.
Have a good trip!
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email:[EMAIL PROTECTED]: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html