3. Section 2.8 Signing Domain Identifier (SDID)
Original Text: (None. Additional text.)
Corrected Text: A single, opaque value that is the mandatory
payload output of DKIM and which refers to the identity claiming
responsibility for the introduction of a message into the mail stream.
'---
Although the i= (UAID) value can be opaque in respect to the actual
identity being referenced, the signing domain d= (SDID) is not
opaque. A domain that returns valid keys should not be considered
opaque.
[> ]
I think what is intended by "opaque" in this context is that it should be
opaque to the Identity Assessor, i.e. it should be treated as an opaque
identifier and no knowledge about DNS domain structure should be applied. For
example, if the SDID was subdomain.example.com, the Identity Assessor should
not make any use of the fact that example.com is the parent domain of the SDID,
it should just treat the whole domain name as an (opaque) identifier string.
Obviously it's not opaque to the verifier in that it's necessary to look up the
keys... but the opaque label is attached to the output of the verifier, not its
input.
Ellen
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html