DKIM can list headers included within the signature, and
architecturally this is a more extensible approach. Adding a new
header requires modifying the signing process to assure tagged source
associations relate to this header, and to encompass that header
within the signature. A new header is one possibility.
Gleaning additional information from a key selection process should
create a lower impact on the signing/verifying process. For example,
Key/Source association mechanisms may be in place to support the g=
attributes that define the permitted local-parts, which already
exists within the keys used by DKIM. Being able to differentiate
which tag belongs with a signature is also solved when incorporated
at the key selector, rather than when using a new header.
Establishing naming conventions for one of the labels within the key
selector is a possibility beyond using a new header.
The down-side for using the key selector is a requirement to be
frugal for key specific trust. The up-side, from the aspect of
building a database, is the requirement to be frugal where the key
and tag can be evaluated together. Perhaps only transactional and
administrative tags would merit scrutiny, as such assessments are
based upon content demanding additional resources. The goal is to
ignore a fair amount of the message traffic meriting little
recognition. Greater trust is possible when it is selective.
Messages annotation shown the recipient may increase their level of
trust. This trust may be desired when instructing recipients to
click to some location, for example. While an institution may want
to assure their customers who know them by their domain name, this
same domain name may also be used by poorly vetted users as well.
Perhaps only those messages tagged as being administrative might
receive elevated trust annotations, which would proactively prevent
any mischief from those less vetted. Only by way of these tags would
a third-party application be able to discern which messages warrant
elevated trust annotations. (Based upon assurance made by the signing-
domain, and the reputation of that domain for this subset.)
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg