[ietf-dkim] summarizing my understanding of the errata discussion & a proposal
hsantos at santronics.com
Tue Feb 10 04:55:27 PST 2009
Pasi.Eronen at nokia.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
> 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,
Which is why I don't understand why there exist a conflictive MUST
convey mandate and the receiver "SHOULD take pains" to highlight the
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"
Hector Santos, CTO
More information about the ietf-dkim