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: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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