On 03/24/2010 02:02 PM, Murray S. Kucherawy wrote:
whether it's really large enough to get over the ietf energy barrier.
This only requires registration of a new tag in the registries the base
auth-results draft created and not a full revision draft or other overhaul
work to make it work. This isn't imposing any mandatory new syntax either.
It's just creating an optional mechanism that can be used to disambiguate
results.
I don't think this will be as big an undertaking as the base draft was, or
the other issue will be.
Well, the Null RFC takes, what, about 2 years these days?
I just read through the draft and I still don't see the "why" that I'm
curious about.
I understand the problem itself, but the why I'm asking about is more
of "why is
this an actual problem faced by implementations". Ie, is this something
that causing
trouble out in the field? Part of this is my own ignorance about how
people are actually
using auth-res, I admit.
I have seen at least one site that signs with a small key (in terms of bits
used) and one large key, so it's got two different selectors but all the
other signature input parameters are identical. This produces two results.
There's no "header.s" so right now you get two results that could be
different and no way to tell them apart. The verifier could distill that
down to a single result that is the union of the two, but that may not be
palatable in all situations (i.e. maybe the receiver cares, but now it can't
apply its policy).
There's also at least one DKIM implementation that will not even accept a
"dkim=pass" if the signature didn't cover the Subject: header field. And
OpenDKIM has various policy features that allow things like "if 'l=' was in
use and not enough of the received message was covered, then the signature
isn't acceptable regardless of the outcome.
One sender that wants to satisfy multiple DKIM acceptance policies will
eventually need to affix multiple signatures with different properties. At
the moment there's no way to distinguish those results past the verifier.
That's the problem I'm trying to solve. The hints of this are operationally
there, but there's not an actual pain point I'm trying to resolve ... yet.
Again, I'm not disputing the theoretical problem -- after all as you mention I
pointed it out ages ago :) All I'm really asking is whether this is actually
causing heartburn for people using auth-res. Like, is there some automatons
that depend on auth-res that are puking because of the situations you describe
above?
Mike, just a reality check...
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html