[ietf-dkim] New Issue: Overview service-type and delegation
fenton at cisco.com
Mon Mar 24 22:30:37 PDT 2008
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
> 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.
More information about the ietf-dkim