I have yet to work out if this is a good idea or not. However there is already a precedent in NSEC3 records.
One thing that we would have to take care to ensure is that there were no undesirable interactions between the two. Another consideration here that might motivate the change is to prevent zone walking. If the zone is DNSSEC signed and the standard NXT record is used an attacker can read out the list of policy records. Use of NSEC3 avoids this problem. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Douglas Otis > Sent: Wednesday, September 06, 2006 2:00 PM > To: Michael Thomas > Cc: IETF-DKIM > Subject: Re: [ietf-dkim] user level ssp > > > On Sep 6, 2006, at 10:14 AM, Michael Thomas wrote: > > > > > All of this talk about additional requirements for user level ssp > > ignores the basic question: should there be any > requirements for user > > level SSP at all? If so, what are the use cases? I'm not terribly > > convinced that even that has consensus -- this is the first that I > > even recall the subject being raised. > > When a large financial institution wishes to have a specific > email- address receive added assurances via annotations, then > having a means to include these addresses within policy > satisfies this desire > without specific arrangements made separately with each verifier. > The current strategies for financial institutions require an > assertion that _all_ messages be signed. Not all messages > from a large domain warrant receiving annotations of added > assurances however. Having a means to convey which > email-address warrants this annotation can be accomplished via policy. > > Rather than a direct translation into a DNS label, a base32 > encoding of a SHA-1 hash ensures long local-parts, UTF-8, and > subaddress symbols can be handled by this scheme. (SHA-256 > could be used, but there does not seem to be a need for this extreme.) > > -Doug > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
