>>>> If a signature has an rsf= tag, verifiers ignore it unless there's a
>>>> matching signature from a domain the rsf= points to. ...
> If you're going to bump the version, you need to use the opportunity to
> solve the more general underlying problem.
>
> I'm not sure I can completely characterize that problem, but it's something
> along the times of there need to be some way to state the intention behind
this
> particular signature. Is this a signature tied to use by third parties?
> Whitelisting? Something else?
That's what the rsf is supposed to mean.
I understand that. The question is what happens when another, similar
proposal comes along. Unless I'm missing something, rsf is quite specific
to this delegation proposal.
I suppose we could factor it out and do a version bump and add a new
"conditional signature" cs= field, which means that a verifier only uses
this signature if the conditions are met. There's a registry of cs field
values, and if there is a cs field whose condition isn't satisfied, or
that the verifier doesn't know about, the verification fails.
That's one of the axes we could proceed along. The other would be
to focus instead on the purpose of the signature, and make the conditions
part of that.
I don't know which is better. There's a serious design decision to make here.
So it'd be something like this:
DKIM-Signature: v=2; ... cs=fwd; ... ft=t,c,foo.example
That is, the condition is that it's also signed by one of the targets in
the forwarding target "ft=" field. ("t" and "c" are the to and cc
headers, on the perhaps overoptimistic theory that there will never be
single letter TLDs.)
You can safely add new cs values without a version bump, since the
verifiers will fail until they've been upgraded to understand them.
Yes, that's the general idea. But I'm not sure this is the right way to do it.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
