Dave Crocker wrote:
Jim Fenton wrote:
Section 4.1 paragraph 3 talks about the service type (s=) constraint
in key records, and goes on to say that it is helpful when delegating
signing authority. s= was included to provide expansion capability
should, at some point, some service other than email decide to use
DKIM. If and when some other service does use DKIM, the ability to
constrain a key to signing email only would help delegation. In the
meanwhile, there isn't any benefit to delegation as a result of s=.
I suggest that the paragraph be deleted.
You suggest having the DKIM Overview make no comment on the s= parameter?
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.
As for "included to provide expansion capability", I don't understand
what this means. The signing spec text says it was included for a
different purpose, but that it *includes* an expansion capability, to
list other services.
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.
So it doesn't have any direct utility at present, but IMO it was not a
mistake to put it in the spec either.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html