On Feb 5, 2009, at 3:36 AM, Charles Lindsey wrote:
First, I stuck to terminology that was in RFC 4871 intentionally,
with an eye toward keeping the errata simple.
Yes, but we are currently discussing Dave's errata, which carefully
distinguishes between the Verifier, which does the purely machanical
checking of the signature for validity, and the Assessor which
decides what action to take on the result.
This new function called the Identity Assessor for DKIM would
presumably be focused on identities. For DKIM, it might determine
which portion of an email-address gets highlighted.
When the i= field _exactly_ matches with an email-address contained
within a signed header field, this entire email-address could be
safely highlighted.
The statement within Section 9 of the Errata prevents being able to
provide this feature.
,---
Hence, DKIM delivers to receive-side Identity Assessors responsible
Identifiers that are individual, opaque values. Their sub-structures
and particular semantics are not publicly defined and, therefore,
cannot be assumed by an Identity Assessor.
'---
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.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html