On Mar 24, 2008, at 10:18 PM, 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?
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?
As I understood it, s= is about minimizing a compromise at the
signing end. If a verifier in another context sees content signed by
a key that says s=email, then they know that the private key at d=
has been compromised.
So s= is about a verifier helping to minimize the damaged of an
internal key compromise at d=. Whether this is a reasonable risk or
not to encode in the protocol is a question.
Also, I don't understand what "s= helps delegation" means, that Jim
refers to.
Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html