Jim Fenton wrote:
Dave Crocker wrote:
Jim Fenton wrote:
Dave Crocker wrote: 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.
Because there is no interoperability if the two participants apply different
hash algorithms to the same message.
In other words, conformance to core technical details is rather different from
attempting to direct the other side to apply the origination-side's local
enforcement policies for who is authorized to use a key and what they are
authorized to use it form.
My point is that the Overview document seeks to describe s= in the most
limited way it can, while at least saying something meaningful.
Deleting a discussion of s= seems inappropriate, as does having the text
say more, since it's a bit of an oddity and I doubt we (the community)
understand it very well.
I'm puzzled that you want to include text on a mechanism that we (the
community) don't understand well, because we're likely to get it wrong in
that case.
Lack of deep understanding is why the discussion is so brief (and superficial.)
Having *some* discussion is warranted by virtue of the feature being in the
spec.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html