ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

2006-08-21 11:02:49
Dave Crocker:
Folks,

Paul Hoffman wrote:
 > I see people who supposedly agree with each other about the policy
appear disagree on the required and requested response to the policy.
Some of that is because the tone of the messages is "this is obvious"
(which it is not), and some of it is because there are long-winded
discussions of the usefulness of the messages that don't concretely say
what the recipient should/must do.


For the case of mail that is signed, I am still waiting to hear why it is not
sufficient to have a third-party use a a sub-domain of the preferred (author, 
or
whatever) domain name.

For example, domain example.com stores their dedicated public key
under a dedicated domain something.example.com.

Even when the signing operation itself is outsourced to a third
party, using a dedicated signing key+domain for user(_at_)example(_dot_)com
gives better protection than a scenario where the same shared,
unrelated, key+domain signs mail from thousands of different domains.

With a shared signing key+domain, if one of those thousands of
domains mis-behaves, all the other domains could suffer from the
bad reputation of that shared signing key+domain.

Thus it's better to avoid shared signing key+domain scenarios.

Hence, the signing practices requirement would only exist for
unsigned messages.

Indeed. With a dedicated signing key+domain as discussed above,
the rfc822.from is protected by a first-party signature only. All
other signatures are by definition third-party, and vouch for the
signer, not the rfc822.from.  Signing practices can tell us if mail
without first-party signature is a possible forgery, regardless of
whether or not that mail has a third-party signature.

        Wietse
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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