Murray S. Kucherawy wrote:
[as regular participant, not document editor]
Moreover, it's substantially more than the percentage that
appear to be using "x=", but we're not considering removing
that here.
So it seems like we've got this theory that simpler
is better, but we're applying that theory piecemeal.
It may not be your intent, but lets not indirectly instill the idea x=
should be a considered candidate for removal. This DKIM feature has
an easy understanding, feel and grasp for utility. It is easy to
explain to producers and consumers, easy to employ and simply
something people can actually use if so desired.
i= is a much different issue.
For its functionality, I can't speak I had a full understanding for
its use cases other than an intent for user level signings. I also
never understood why it remained over the years when it seemed to be
something yet fine tuned and there was still the long time concerns of
its DNS scalability. Yet, it hung around but seem to become one of
the DKIM features that would not be used much.
From the software angle, when the key record g= tag is no longer part
of the spec, then i= is less software wise required. Can't speak for
OpenDKIM, but in the ALT-N (verifier) API, any i= value defined in the
signature is only applied when a key record g= tag value is defined.
From the testing standpoint, I found a need to modified the API to
add an verifier CheckGranularity=1|0 option because we found false
positives with computational valid signatures but an failed NO
SIGNATURE result due to a failed g=/i= granularity wildcard string
comparison checks. The check option was provided with a noted concern
it might promote a security loophole if disabled.
From a documentation standpoint (F1 online help, etc) in describing
the what, why and when to use reasons for his particular i= option,
was not easy to do especially when it came to the DNS management aspects.
--
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html