Pasi(_dot_)Eronen(_at_)nokia(_dot_)com wrote:
Douglas Otis wrote:
Statements that imply the i= value is always OPAQUE prevents its
utilization for highlighting purposes with respect to identity
assurances, even when there is an exact match and this value could
be said to not be opaque. This also seems to conflict with the
defined use of the i= value as representing on whose behalf the
signature was added. There should be an exception spelled out for
exact matches.
Such as:
Hence, DKIM delivers to receive-side Identity Assessors responsible
Identifiers that are individual, where unless the AUID exactly
matches a signed header's email-address, is to be considered an
opaque value. Being opaque means the AUID sub-structures, and
particular semantics, are not publicly defined and, therefore,
cannot be assumed by an Identity Assessor.
Note that the text in rfc4871-errata currently says that the
local-part of UAID may or may not be in the same namespace as email
address local-parts.
You seem to assume that they're in the same namespace -- because if
they're not, comparing them does not make sense (exact match
or anything else).
(US passport numbers are 9 digits. US Social Security Numbers are
also 9 digits. But since they're not in the same namespace, an
exact match between passport 123456789 and SSN 123456789 does
not provide useful information -- the numbers could refer to
the same person (in theory, although unlikely) or to different
persons.)
So, even exact match with some email header is useless to the
recipient (unless it somehow knows that the Signer is using same
namespaces for these two fields).
Best regards,
Pasi
Which is why I don't understand why there exist a conflictive MUST
convey mandate and the receiver "SHOULD take pains" to highlight the
mismatch.
Once the signature has been verified, that information MUST be
conveyed to the Identity Assessor (such as an explicit allow/
whitelist and reputation system) and/or to the end user. If the
SDID is not the same as the address in the From: header field, the
mail system SHOULD take pains to ensure that the actual SDID is
clear to the reader.
What value is gain to highlight?
2822.From != SDID
What sort of pains are we talking about and is there any assurance to
alleviate the pains? how does the receiver ensure what the actual SDID
is? What if it can't?
Basically what I am saying is that even though the signer is providing
a opaque value, it is transparent to the verifier (like it was never
there in the first place).
The only useful concept is to make sure the domain parts are satisfied
as required by RFC4871. Beyond that, the verifier really can't do
anyone more with it. Maybe someone can explain how this helps the user.
I'm proposing the "MUST convey" be changed to "SHOULD|MAY convey"
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html