[ietf-dkim] On per-user-keying
jon at callas.org
Sat Aug 6 09:28:05 PDT 2005
On 6 Aug 2005, at 12:44 AM, Dave Crocker wrote:
> Dkim needs to state clearly what it IS intended for. If this does not
> include end-user use then dkim does not have an obligation to "prove"
> it. That would be trying to olepce the negative.
Here's my opinion:
DKIM is intended for domain-level authentication, not user-level
DKIM provides a mechanism so that some parts of the domain can be
delegated off. The classic example is to allow "benefits at cisco.com" to
be handed to an outsourced organization so that they can send mail as
"benefits at cisco.com" and have the DKIM signatures work properly. This
is not user-level signing.
It's probably possible to abuse the protocol and kluge this mechanism
into user-level signing. It's not a good idea. I don't even think it
makes sense. Here are a few reasons why:
* There is no semantic benefit to doing so. Let us suppose this message
had a DKIM signature on it. That signature is a statement by
"callas.org" that an authorized agency sent the message. Note that I
said "authorized agency," not user. Users are the typical example of
authorized agencies. But a daily status message from "do-not-reply" is
also an authorized agency that is *not* a user. "root" is perhaps what
one might call a virtual user. It might make sense to make a separate
key for "root at domain" while some set of people in the IT staff would
all be essentially "root." I'm not sure I would do it that way, but I'm
sure it's natural for some set of systems. Other common agencies and
virtual users include "postmaster", "hostmaster", "abuse", "security",
"billing", "*-request", "mailman-owner", etc.
This is another one of the reasons why DKIM is superior to S/MIME or
OpenPGP for this purpose. If you used one of those mechanisms, you'd
have to audit your entire business and network infrastructure and look
for any "virtual user" (or "authorized agency") and give each one a
certificate. The "D" in DKIM stands for "DOMAIN."
* You would have to come up with a mechanism to do key management and
distribution. This means possibly generating the keys and handing them
to the users. It possibly means getting the users to generate the keys
and then hand off the domain administration. In the former case this
means properly identifying and authenticating each user so you make
sure the user gets the right key. In the latter case, it means
authenticating the users, and getting the proper key from each. In both
cases, it involves putting the public portion into the DNS
Please note that this is tantamount to creating a PKI, and one of the
DKIM goals was to not require creating a PKI. However, if you already
had a PKI, it's a simple matter of programming to pull the keys out of
the certificates, no matter what format they're in, X.509, OpenPGP,
both, or other. However, this introduces a new wrinkle into the system
-- revocation. Solving the DKIM/PKI revocation problem is left as an
exercise for the reader. (My advise is don't do that, you'll hurt
* A DKIM signature is ideally applied at something approximating the
edge MTA. (Because if you don't, and some outer MTA does something like
a quoted-printable conversion (either into our out of), then you're
scrod.) It doesn't have to be. For example, from time to time, I toy
with the idea of running an MTA on my laptop. If I did, then it would
be kinda cool to have a user-level DKIM key, and have sendmail sign my
messages and then plop them off onto the network at large. But that's
not the way that the world typically works.
Properly applying a DKIM signature requires that the signing MTA have
all the private keys for the users, or a lot of work to be done. You'd
have to modify the MUA (which is an anti-goal of DKIM), or come up with
a way that the key gets transfered to the signing MTA, or perhaps a
mechanism where the signing MTA sends the message or perhaps
canonicalized hash of the message back to user's machine for signing.
This means that you have to either have per-user MTAs to go with your
per-user keys, have edge MTAs that hold lots of user private keys
(typically all of them), design new protocols for user-level signing
with the user-level keys, or modify the MUAs.
* Some digital signature laws require that a legal digital signature be
made under direct user control. This means that an edge MTA that held
all the private keys for the users could not make legal digital
signatures. This does *not* mean that it is illegal to do this; it
means that such signatures have no legal bearing. If they have no legal
bearing, why are you bothering to do it? After all, a domain-level DKIM
signature says that the message was sent by an authorized user. You
gain no benefit from the user-level key, unless you put the key under
the user's control.
With a little bit more thought, I'm sure I or someone else can come up
with more hair in user-level keying. I think that I have made my point,
however, that it is fraught with peril.
I'm sure there are some places where this would be relatively easy to
set up, but I'm trying to think of it. I happen to own a domain that
has exactly one user, and that user isn't even a person, it's a
process. You'd think that in that case, per-user keying would be easy
--- because there'd only be one key for the whole domain. Even in this
case, though, there's hair. Even that domain has to have some mechanism
to send mail from postmaster, hostmaster, abuse, and so on. In a
one-user domain, setting up per-user keys is more trouble than it's
I think I have adequately demonstrated that DKIM is not intended for
per-user keying, even though it has a feature that on first blush looks
like it could be used for per-user keying. While it does not "prevent"
it, setting it up requires so much hair that the only places that it's
anything resembling easy to set up are precisely the edge cases that
it's designed for. The delegation feature *could* be abused into
per-user keying, but think it unlikely to happen. I think we can let
this discussion die a well-deserved death now.
More information about the ietf-dkim