[ietf-dkim] On per-user-keying

[Jon Callas]

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 
authentication.

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 
appropriately.

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 
yourself.)

* 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 
worth.

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.

	Jon