ietf-dkim
[Top] [All Lists]

[ietf-dkim] Delegation and Designation (#1360)

2006-09-28 22:29:22
This is to continue discussion of a topic that came up in today's jabber
chat regarding the need for "designation".  See
http://www.ietf.org/meetings/ietf-logs/dkim/2006-09-28.html from
11:17:47 through 11:30:09.

Let start with some definitions (sorry they're so legalistic; an
"entity" might be a person (user) or domain):

Delegation:  The process of publishing a public key controlled by
another entity, to allow that entity to sign messages for some or all
addresses in your domain.

Designation:  The process of publishing some information that tells a
verifier that signatures from certain external entities ought to be
treated as "first-party" signatures coming from your domain.

Delegation exists in the key management model described in -base.  The
question here is whether we need designation as well.

If I recall correctly, designation arose as a simpler way of doing
delegation.  If example.com wants to use exampletwo.com to send some
mail on its behalf, it merely publishes an assertion (mechanism TBD)
that says that exampletwo.com is a designated signer.  All signatures
from exampletwo.com are considered as valid as those from example.com
for messages with an example.com origination address.

In order to do this by key delegation, example.com would need to obtain
a public key from exampletwo.com and publish it in its own DNS.  This
transfer might need to be secured to make sure that the right public key
gets published.  Then exampletwo.com would need to see when it is
signing messages for example.com and use the right selector and
d=example.com.  When key rotations happen, further coordination between
the domains would be needed.

One use case that was discussed for the g= tag in the key record (which
restricts key validity to address local parts that match a pattern) is
that it allows delegation of keys for only a specific address or
addresses, e.g., sales(_at_)example(_dot_)com(_dot_)  This, in effect, lowers 
the amount
of trust that example.com needs to have for exampletwo.com, which tends
to facilitate the transaction (since they can't produce signatures for
ceo(_at_)example(_dot_)com).  Designation, however, affects the entire domain.

Another issue is that the signatures are different.  In the delegation
case, d=example.com; with designation, it would be d=exampletwo.com. 
While defining anything having to do with how reputation services
operate is outside the DKIM WG charter, it is likely that such services
would use the d= value as a base.  So the difference is significant for
users of DKIM signatures, and simply viewing designation as a simpler
way of doing delegation is erroneous.

So the question is, do we need both delegation and designation?

My opinion, if it isn't already obvious from the above discussion, is
that designation is a flawed way of delegating signing authority.  I
don't like the fact that example.com can hire exampletwo.com to send out
a bunch of bulk advertising, and then when there are objections,
effectively finger-point and say "Exampletwo did it".  If example.com
wants mail sent by exampletwo.com to be treated as if it came from them
(first-party signature), they should be willing to take responsibility
for it themselves.  If they don't want to take that responsibility, they
should accept that exampletwo.com applies a third-party signature.

-Jim

P.S. to John Levine:  exampletwo.com is available for your domain
collection if you want it!
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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