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. Would it not be wiser to make support for arbitrary
octets (except those essential for parsing such as ";", CR, LF, etc) a
MUST accept right from the start?
No, because we want DKIM to work with 7-bit-clean mail. We want
broad, fast deployment and that means working with old systems.
3.3.3 Other algorithms
Presumably there is nothing to prevent allowing PGP as the signing
algorithm in the future, if someone makes out a good case for it.
As Eliot has noted, PGP isn't a signing algorithm. PGP is a signing
protocol. Actually, to be even more correct, OpenPGP is a signing
protocol. PGP is software.
Nonetheless, DKIM is specifically designed to be orthogonal to
OpenPGP, S/MIME, or anything else. If you want to sign the content of
a message, they're appropriate for it.
3.5 The DKIM-Signature header field
Although your charter forbids you from discussing non-repudiation,
authorization, and other matters not strictly relevant for DKIM, it
is to
be envisaged that other applications will arise from time to time
requiring signatures over headers, and it would be unfortunate if each
such application had to invent Yet-Another-Signing-Protocol when a
simple
adaptation of what you have written would have sufficed. There are
already
too many only-slightly-different-wheels in existence for us to be
inventing any more. Surely, a facility for signing headers should be
described as a tool which can then be used for various applications in
future, of which DKIM would be just the first? So why was this
approach
not taken?
In fact, you almost made it. The only features which might make it
hard
for future applications that I can see are the appearance of "DKIM" in
your newly invented "DKIM-Signature" header (it rather needs an
'application' tag in the signature to indicate why the signature was
made), and the insistence that the d= and s= tags, which together
identify
the owner of the key, should be syntactically of the form of domain-
names
(which might be totally inappropriate for those other applications,
though
it should clearly be required when the application is DKIM).
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)?
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.
At the risk of using a postal metaphor (since email is surprisingly
different beast from postal mail), DKIM is an integrity protocol for
the envelope, not for the letter. Mechanically, it has to sign the
body, but that's again, not the goal.
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. It's really a note from the signing
domain to itself. Here's a scenario. You ring me up and tell me that
one of my users is misbehaving in email. You show me the email. I use
the i= to know whose knuckles to rap. But I may do so in a way that's
completely opaque to you.
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?
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.
If the signing server (callas.org) sends it to the mailing list
(mipassoc.org) which then sends it to you, how do you know what the
mailing list added? That is the length.
The length is the opposite of what you think it is. It is an explicit
declaration by the responsible domain of what it is responsible for.
If a spammer adds stuff at the end, it should be removed. It is
saying that text that the author did not put there is not the
author's text and thus may be removed. (I'm playing fast and loose a
bit here, because it's not the author it's the author's exit mail
server.)
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. It is a key-centric system.
There's nothing wrong with embodying those keys in certificates or
even gaffer tape, but that's not part of DKIM. However, yes, you are
right, it doesn't preclude using anything else.
Second, PKIs are not distribution mechanisms. DNS is a distribution
mechanism. Other possible mechanisms include LDAP, HTTP, FTP, Finger,
Gopher, etc.
Why MUST signers support "dns/ext" (clearly, verifiers MUST)? Surely a
signer who, as a matter of policy, always chooses to use some other
query
method, is not obliged to implement something he is never going to
use.
Then they're not doing DKIM. If you're doing DKIM, you MUST do DNS.
Conceivably, you might implement other mechanisms, too, but DNS is
the one distribution mechanism everyone has to do.
t= Signature Timestamp
... The format is the number of seconds
since 00:00:00 on January 1, 1970 in the UTC time zone. ...
Strictly speaking not true, since the usual UNIX algorithm for
calculating
this quantity takes no account of leap seconds. I presume this is
all laid
down in POSIX somewhere.
And expecting this to work up to AD 200,000 seems an overkill (though
beyond 2038 would be helpful).
This is a definition. It has nothing to do with unix.
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?
It's for interoperability.
Here's what's going on there. SHA-1 is broken. It isn't so broken
that we're going to demand that no one use it, but it's broken. We
*want* you to use SHA-256. However, we are making a concession to
people who have some need or desire to use SHA-1 and making sure it
will all still work.
k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers
and
verifiers MUST support the "rsa" key type.
Why MUST signers support the "rsa" key type (clearly, verifiers MUST)?
Surely a signer who, as a matter of policy, always chooses to use some
other key type is not obliged to implement something he is never
going to
use?
For interoperability. You have to have a key type that *everyone*
implements. Note that in this standard like many others, mandatory-to-
implement does not mean mandatory-to-use. It's perfectly fine for a
user to decide that they're only ever going to use ECDSA, and never
RSA. But the software that they use has to implement RSA because
other people are.
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. But we're being
realistic and want DKIM to work with existing systems.
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, which will have a lot of
things in it to help you get up to speed. Look at the DKIM WG charter
at <http://www.ietf.org/html.charters/dkim-charter.html> which has
pointers to the WG documents.
You especially should look at the DKIM threats RFC, RFC 4686. Also
after that, look at the DKIM Service Overview. Those should help you
understand a lot of the mechanism that's in DKIM-base.
Jon
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html