Jim Fenton wrote:
Dave Crocker wrote:
The signing specification's explanatory text for s= is: "This tag is
intended to constrain the use of keys for other purposes". If there is
something inaccurate in the Overview text, what is it?
It's not strictly inaccurate, since it says "intended to be helpful", which
is true. But I don't want to give the impression to the reader that using
s=email in their keys is going to provide any immediate benefit, because
there aren't any other services using DKIM.
The Overview document's discussion of DKIM's details is actually pretty careful
not to talk about efficacy . Sowhether something is "useful" or has "immediate
benefit" is something the document seeks to avoid saying anything about.
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.
In spite of your ending statement to the contrary, your explanation really does
seem imply that the s= mechanism is useful in its current form. An assertion
that it's necessary to have it now only makes sense if it has benefit now, even
if the benefit is building a utility "infrastructure" for later use.
At best, the benefit of having s= defined now depends on whether people are
setting s=email now. Are they? Should they? How will they know?
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.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html