On 5/11/20 10:30 AM, Dave Crocker wrote: > On 5/11/2020 10:21 AM, Alessandro Vesely wrote: >> The question is, what responsibility is being claimed? > .... >> Tagging keys with aim= would allow senders to choose an appropriate >> selector >> under different circumstances. > > > If signers want to have a standardized means of indicating the > fine-grained semantics behind their signature, they can do that > without modifying DKIM. > > Rather, define and use a header field that specifies DKIM signing > policy. Cover it with the DKIM signature, of course.
If this is expressing semantics for the DKIM signature, it's also likely that there are going to be multiple DKIM signatures on the message with different semantics. There might then be multiple instances of the header field, and it would be difficult to associate each signature with the appropriate semantics header field, except in the specific case where there is only one specific semantics header field and all signatures use either that or the default. There might also be the situation where a domain wants to delegate a key to a third party that can only have a subset of semantics, e.g., "this was sent by our advertising partner" vs. "this comes from our own staff". That's a reason to tag the key; otherwise, it would be preferable to tag the signature itself. This would be an extension, not a modification of DKIM. > > The only interesting part of this task is deciding on a standard set > of policy labels. > > Oh, and then figuring out why and how they are useful to provide... I'm also not clear on what the aim= tag would be asserting, why it would be trustable by a verifier, and how this would be useful to a verifier, and would like to hear more about that. -Jim _______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
