ietf-dkim
[Top] [All Lists]

[ietf-dkim] On per-user-keying

2005-08-06 09:32:46
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(_dot_)com" to be handed to an outsourced organization so that they can send mail as "benefits(_at_)cisco(_dot_)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

_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim

<Prev in Thread] Current Thread [Next in Thread>