Let me add some more heresy here...
On 2005-07-31 03:45:00 -0500, Earl Hood wrote:
A key difference with DKIM, and similiar proposals, is the
ability to sign (arbitrary) header fields. S/MIME and OpenPGP
are limited in this regard. For example, from a
spamming/phishing context, header fields like Subject and From
are important.
It's probably as easy to extend either S/MIME or PGP/MIME to make
some statements about the parent message entity's headers as it is
to develop and deploy DKIM.
BTW, here may be some possible reasons S/MIME or OpenPGP are
not useful as a basis for MASS:
* S/MIME, et.al. do not provide arbitrary header signing
capabilities, especially key fields like Subject and From.
See above, that's not by itself a reason to start with an entirely
new protocol, when one could (maybe) tweak an existing one.
(That existing protocol might, in fact, be the multipart/signed
specification in RFC 1847, which is being used by both PGP/MIME and
S/MIME.)
* Signing agents may be MTAs or other entities in the
transmission of message. A process that does not require
full MIME parsing capabilities and minimizes (or avoids)
modification to body data can be desirable. Signing at the
RFC-2822 level will be more efficient than at the MIME level.
This does assume that MIME-awareness is not a critical
requirement in achieving desired goals.
I'm sorry, but this argument doesn't hold water.
Taking an existing MIME body and wrapping that into some kind of
multipart is, essentially, trivial, and can be implemented in a
short Bourne shell script. The complexity and amount of MIME
awareness needed to generate an RFC1847-style multipart/signed is
*exactly* the same as is the one that is needed to create what you
call "RFC 2822-level signatures."
The real complexity during signing comes in when you try to
canonicalize an e-mail's body to a degree where it becomes robust
under likely transport level modifications. This process indeed
requires an ugly degree of MIME awareness, but it is precisely the
same for using multipart/signed as it is for doing "RFC 2822-level
signatures."
(Part of this complexity comes from dealing with 8BITMIME; basically
this means that the signing party may have to go down the entire
MIME tree, and re-encode any 8bit leaves of that tree to either qp
or base64. This is the only way to make sure that the signed
message isn't going to be modified in transit when it hits a gateway
between 8BITMIME world and 7bit SMTP world. A corollary from this,
though, is that some MTAs already include an unhealthy amount of
MIME code.)
* Multiple signing: Although DKIM does not address this well,
mulitple signing may be done to show "chain of custody" as a
message makes its way through the delivery chain. Multiple signing
using S/MIME and OpenPGP, although supported, requires modification
of the message body each time (which implies MIME awareness).
A header-based method does not.
You can always wrap a multipart/signed into another
multipart/signed, with the same complexity as adding another "RFC
2822 level signature."
Or you can try doing multipart signatures with something like
multipart/mixed as the signature protocol [has that ever gone beyond
unsubmitted drafts for Internet-Drafts?], which indeed involves some
amount of MIME parsing in order to extract individual signatures.
That said, there is some MIME-related complexity to parsing and
verifying multipart/signed signatures -- you need to parse a single
level of multipart/mixed (i.e., split things at appropriate
boundaries).
On the other side of the balance, multipart/signed style signatures
also bring benefits over what's currently discussed in DKIM -- to
begin with, there's a well-bounded set of body data that's covered
by the signature. This takes care of (1) the "l" flag related
problems, and (2) the canonicalization related problems.
(If a party wants to add something to a signed message, hey, just
wrap the original messaage in another multipart/mixed and go ahead.)
S 1.1
------
The approach taken by DKIM differs from previous approaches to
message signing (e.g. S/MIME, OpenPGP) in that:
o the message signature is written to the message header fields so
that neither human recipients nor existing MUA software are
confused by signature-related content appearing in the message
body
o there is no dependency on public and private key pairs being
issued by well-known, trusted certificate authorities
o there is no dependency on the deployment of any new Internet
protocols or services for public key distribution or revocation.
-----
The first point does not apply to PEM (RFC 1421).
How? Checking the PEM-related RFCs, PEM does nothing with the message
header fields. For non-PEM aware MUAs, PEM-specific data is visible
to the human. (BTW, what is the percentage of MUAs that support PEM?)
I think a problem with the first point is it implies that MUAs do
not need to be DKIM-aware. I'm not sure this is a safe assumption
if DKIM is to achieve acceptance. Of course, MUA awareness is
not required to define DKIM, but it may be needed if DKIM is to
be widely accepted.
The basic point here seems to be that MIME support in some
widespread software is bad enough so they can't be bothered to do
the right thing about multipart/signed.
The second and third points are sort of misleading since
OpenPGP and S/MIME can work perfectly well with e.g.,
self-signed certificates. And with the same level of effort
required to distribute DKIM keys you could build key
distribution systems for S/MIME and OpenPGP with similar levels
of assurance.
It may be a worthwhile exercise to see what it would take to
define a DNS-based key management system for use in S/MIME or
OpenPGP.
It is rather simple to use DKIM-like "trust establishment" with,
e.g., OpenPGP. There actually are some experimental patches to gnupg
which do precisely this.
That said, one of the benefits of separating MASS work into (1)
DNS-based trust establishment and policy discovery and (2) e-mail
signing would be the reuse of the first one for OpenPGP and S/MIME.
I think the MUA plays a key role here, and I think DKIM
short-changes this. For spamming and phishing to be addressed,
any measures must be visible to the end-users. If an MUA is not
DKIM-aware, what real value does DKIM provide to achieve its
stated goals.
Good point. Critically good point, indeed.
--
Thomas Roessler, W3C <tlr(_at_)w3(_dot_)org>