[ietf-dkim] The URL to my paper describing the DKIM policyoptions

[Douglas Otis]

On Jul 25, 2006, at 5:33 PM, Hallam-Baker, Phillip wrote:

>> The intent was to point to a general label where policy references  
>> are found.  Philip suggested this should point to an HTTP server.   
>> HTTP is needed to support the size of an all encompassing policy  
>> response.
>
> No I did not make that suggestion.
>
> What I did say is that we should not look to put more that the bare  
> essentials into the DNS system, that is the data that a client is  
> going to use to make a choice between services and to configure the  
> security context to connect to a service. If there is a need to go  
> beyond that we can link out to HTTP but that is not necessary for DKIM

My apologies.  I see that you have suggested resource records located  
at the underscore label will use protocol specific policy RR types to  
avoid collision.  Currently, this process requires an attempt to  
directly obtain desired policy RR types at the underscore label.  If  
that fails, a transaction then obtains the prefix-wildcard RR  
record.  The content of the prefix-wildcard RR then locates the  
desired policy RR type for one more transaction.

Of course, a script or complaint DNS server generates the added  
wildcard records, but this may create issues related to revealing  
nodes within a domain.  Assuming this disclosure is not a problem,  
automating this prefix-wildcard RR record would ideally always return  
the desired policy RR on the first transaction "as if"  
_policy.<subdomain.domain> contained the policy RRset.  Specialized  
handling for the prefix-wildcard RR in this case would conflict with  
PTR definitions, however.  As this scheme expects new and protocol  
specific RR types, defining an RR to support the prefix-wildcard  
seems appropriate as well.

Perhaps it could be defined as:

_policy.<domain> PWCARD	<list-of-RR-types> <location-of-RR-types> ;no  
need for the ** label as this would be keyed off of the PWCARD type.

The list of policy RR types might help handle policy RRset overflow  
conditions.  The list allows individual queries of the most  
appropriate policy type without iterative queries to discover what is  
available.  This assumes policy structures may evolve, and that more  
than one policy for a protocol might be published.  If this approach  
does become popular, it may not be possible to obtain the entire RRset.

-Doug