[ietf-dkim] No centralized database is needed.

[Douglas Otis]

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