On Jun 9, 2006, at 5:15 PM, John Levine wrote:
If the "g=" tag in the public key is present and is anything other
than *, and the domains in the "i=" and "n=" tags in the signature
are not identical, the verifier MUST ignore the key record and
return PERMFAIL (inapplicable key).
This transforms the key's n= (note) into an i= template. Rather than
conditioned upon 'g=', Why not always have the 'n=' represent an 'i='
template? Or rather perhaps this feature could even use an 'i=' tag
in the key.
Can you help me understand why is really needed?
These i= and g= mechanisms are about validating an email-address, and
are not about signing the message. You have already indicated that
for the majority of email that you will be signing on the behalf of
others, email-address validation is not important. I see nothing
wrong with this approach.
Rather than increasing the complexity of these mechanisms intended to
validate the email-address by introducing virtual subdomains over
signing domains, why not simply require the key to be located at the
same level as the email-address domain being validated?
When playing games with local-part tags and virtual subdomains, does
this odd corner case really justify all this? The 'i=' construct
would be greatly simplified by not including the '@' symbol and
labels compared against the 'd=' parameter. There would be no
concerns about what might happen within a higher level '_domainkey"
subdomain. There would be no need to draw up extra contracts or
establish more additional regulations on domain managers and service
providers. The information found within the key and signature would
also be reduced.
With this complex scheme, instead of publishing a key at the domain
of the email-address, these domains must be repeated within the 'i='
parameter (and 'n=') for each message. The alternative would be a
one time act of publishing a key. The one time act reduces the
amount of repeated information exchanged perhaps millions of times over.
This would also mean when an email-address has been validated, there
is no question in the mind of the recipient which domain is
responsible for having asserted the validation. When there are
virtual domains include, the recipient must now guess or check unseen
headers. When a key goes astray, blocking is afforded greater
granularity at the signing domain. Filtering the local-part would
not need to utilize information now hidden within the key. Life gets
so much simpler not allowing this "convenience."
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html