|
Re: [ietf-dkim] Introducing myself
2006-11-01 09:14:45
On Tue, 31 Oct 2006 09:26:57 -0000, Jon Callas <jon(_at_)callas(_dot_)org>
wrote:
On 30 Oct 2006, at 1:42 PM, Charles Lindsey wrote:
I'm going to cherry-pick a few things, particularly the ones I think I'm
best suited to answer.
3.2 Tag=Value Lists
INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text"
defined below (as "tag-value") only includes 7-bit characters, an
implementation that wished to anticipate future standards would
be
advised to not preclude the use of UTF8-encoded text in tag=value
lists.
Those future standards are nearer than you think. The currently active
ietf-eai WG is charged with producing an experimental protocol for
writing
headers in UTF-8. ...
No, because we want DKIM to work with 7-bit-clean mail. We want broad,
fast deployment and that means working with old systems.
Sure, but that is no reason for making it _not_ work with new systems. If
it is REQUIRED (rather then merely suggested, as in the present draft)
that UTF8-encoded text in tag=value lists is allowed, all existing mail
will still work, but so will the new. That should make everybody happy,
including the implementors who now have one test less to write.
3.5 The DKIM-Signature header field
h= Signed header fields
Why MUST NOT this list be empty? Suppose you want to sign the body, but
not any headers? Unusual, but perhaps sensible for some application. No
interoperability arises.
Because you have to sign at least one header. Think of DKIM as a
header-signing system. It signs the body, too, but that's a means to an
end.
Fair enough, but that sounds like grounds for SHOULD NOT rather than MUST
NOT, since nothing actually breaks if you violate it.
i= Identity of the user or agent
Must this tag, if a <local-part> is present, be a valid working email
address?
No, it can be anything you want.
OK.
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 ...
The point of body lengths is that many systems add text to the end of a
message. In fact, the list server that is delivering this to you is
doing precisely that.
So I see, and a very sternly worded remark ("NOTE WELL: ...") it is. So
why do you want to even suggest that is would be legitimate for verifiers
(or their policy modules) to chop it out?
q= A colon-separated list of query methods used to retrieve the
public key
Clearly, the use of DNS or some similar global database is the only
sensible PKI that is workable for DKIM. But am I right in saying that
this
tag does not preclude the use of other PKIs for other applications (e.g.
attached certificates, web-of-trust, private agreements between the
communicating parties, etc.)?
A couple of comments on this one.
DKIM is not a PKI. It has no trust model.
I would not say it has no trust model. The DNS is not all that easy to
spoof, but it still gives a reasonably strong assurance you have the
correct key, though clearly other PKIs are much stronger.
Second, PKIs are not distribution mechanisms.
A mattter ot definition, I think. I would regard a PKI as encompassing
either or both of a distribution and a trust mechanism.
Why MUST signers support "dns/ext" (clearly, verifiers MUST)? ...
See my reply to Eliot for this, and the similar wordings for hash and
encryption algorithms. I think you have misunderstood the point of my
concern. If it had said that signers SHOULD use dns/ext, ... rsa, ...
sha-256, etc, (at least when the application is DKIM) then that would have
been OK.
5.3 Normalize the Message to Prevent Transport Conversions
I found this section absolutely astounding.
Message bodies written in Non-ASCII charsets have been commonplace now
for
12 or more years, and they are most readily represented as 8-bit.
8BITMIME
has been around for the same length of time and is now almost
universally
deployed. 8bit using 8BITMIME has become, or is well on the way to
becoming, the preferred CTE for charsets which will not fit into 7bits.
And yet you are now seriously proposing, for a protocol that needs to be
used in the great majority of future email messages if it is to fulfill
its purpose, to return to encodings that can be squashed into 7bits.
That
is one monumental step backwards for the IETF.
You're confusing making sure that 7-bit systems don't break with
encouraging them. We're not encouraging them.
You say "signers SHOULD convert the message to a suitable MIME content
transfer encoding such as quoted-printable or base64". That sounds to me
like a pretty strong discouragement to continue using CTE 8bit.
... But we're being realistic and want DKIM to work with existing
systems.
Then is that case it has to work with CTE 8bit even when it gets changed
to Q-P or Base64 by some non-8BITMIME MTA en route (I doubt there are many
systems left that still do that, but there will be some).
And it is not as if this was a difficult problem to solve. All you have to
do is to decode any Q-P or Base64 encountered during the canonicalization
process and use that in the hash. By definition, changing the CTE does not
alter the "meaning" of the message, so no harm can arise from that. Why
was this not done?
Sorry to have gone on at such length. But some of these issues seem of
importance, so I hope someone will take the trouble to reply.
It's all right. Sorry for being a bit abrupt, but you need to catch up
to what we're doing.
Go look at the web site at www.dkim.org, .......
Yes, I have already looked at all the sources you mention.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 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
|
|