ietf-dkim
[Top] [All Lists]

[ietf-dkim] No centralized database is needed.

2005-08-30 15:35:45

On Aug 30, 2005, at 1:01 PM, Frank Ellermann wrote:

I want to kill all pbaker(_at_)verisign where it's 100% clear that
it wasn't you or somebody else @verisign.  Modulo screw ups on
your or my side,  Please tell me where that misses essential
points in the design of DKIM.

One approach could be to create a centralized database (DNS) indexed for specific mailbox-domains that indicate signature requirements with lists of which domains are permitted or must sign the message. There would also need to be an agreement when a specific mailbox- domain should invoke the application of this information.

Another approach could be to collect relationships discovered within signed messages to determine when messages appear to be from a different entity. The signed message may even advise what information should be compared against the mailbox-address and perhaps even the pretty-name. While in most cases the collected relationships (bindings) would be made at the behest of the recipient and require their approval, some relationships could be established automatically.

Those relationships where the mailbox/signing are the same, and where the message advises only the mailbox/signing domain are essential to identify the originator of a message, then capturing this relationship should be safely done automatically. With this information captured (cached), the MTA or MUA would be able to detect when a message violated these expected relationships.

To recognize the originator of a message when there are no assurances being made regarding the mailbox-address, an opaque-identifier that tracks accounts would be added by the signing domain. This opaque- identifier would become part of the captured relationship once approved by the recipient. A provision would be needed to indicate when a key had been delegated and should not be trusted to make recommendations with respect to the scope of a binding. This delegated key should also require the opaque-identifier to equal the key-selector.

In the case of particular domain that recommends only the signing/ mailbox domains be bound, then following initial contact by anyone in that domain, comparing the signing/mailbox domains would indicate when the source of a message appears suspicious. If a subsequent message appeared suspicious coming from a list server, then the recipient could merge the list server domain within the associated relationship. This approach would make it more advantageous for list servers not to damage initial signatures.

Even when somebody(_at_)somedomain which allows any mailbox-domain in the From header but signs the out-going mail, the added opaque- identifier would still permit detecting when someone was attempting to pretend to be that individual. This would not require the administration of centralized database.

-Doug

_______________________________________________
ietf-dkim mailing list
http://dkim.org

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