On Mar 25, 2008, at 9:00 AM, Jim Fenton wrote:
Dave Crocker wrote:
Jim Fenton wrote:
Dave Crocker wrote:
You further seem to indicate that s= is not currently useful but
would be
if it listed other services. (I well might be misunderstanding
this
part
of your text.) In any event, either the capability has currently
utility,
or it was a mistake to put it in the spec. Which are you saying?
The current utility is that, while extensions can be added any time,
constraints need to be added up front. So if another service
besides
email
wanted to use DKIM and its key infrastructure, it wouldn't be
possible to
cause new keys created for that service to not also be used for
email
unless
we define it now so that "legacy DKIM implementations" in the future
will
honor the constraint.
Actually, this all touches on the question of trying to recruit
signature verifiers into the task of enforcing a signer's internal
policies. That's what restrictions on authorization to signing are.
The same could be said about restrictions on hash and signing
algorithms, yet those are essential.
But the failure mode is quite different. If the verifier ignores or
mis-interprets instructions on hash and signing algorithms, the
verify process fails-closed. If the verifier ignores s= instructions,
the verify process fails-open.
As a principle, I would have thought that a fail-closed outcome would
be something we prefer if the verifier does the wrong thing.
Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html