Dave Crocker wrote: > > > Jim Fenton wrote: >> Dave Crocker wrote: >> >>> 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.
The same could be said about restrictions on hash and signing algorithms, yet those are essential. > > 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? Are they: I haven't seen a key with s=email yet, although I'll have to admit that I don't look at a lot of selectors. Should they: They should as soon as they start using DKIM for services other than email, especially if they want to delegate keys to parties/agents not authorized to send email on their behalf. But until someone defines use for DKIM in a service other than email, s=email is a tautology, so I don't think it's important to state. > > > 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. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
