On Thursday 08 October 2009 13:32:43 Douglas Otis wrote:
Here is an update of the tpa draft given a different title.
http://www.ietf.org/id/draft-otis-dkim-tpa-label-01.txt
http://www.sonic.net/~dougotis/id/draft-otis-dkim-tpa-label-01.html
Overall Doug I'd like to say "very well done". You've encapsulated the problem
statement quite well and provided a justified author domain framework for TPA.
Thanks also for your DNS size measurements - that makes sense to me.
Things I have questions about are:
4.
"In addition, a newline character (0x0A) is appended to the end of the string
to match a command line generation of SHA1 values". This sounds likes its
adding an implementation nicety when I'm not sure all implementations would
use. Those that don't, could find it inconvenient and a source of errors.
"d=" parameter (does not include the trailing period)." So a d= field could
contain a trailing period? If this is the case it probably should be cleared
up in the dkim-signatures RFC rather than being TPA specific.
So the "signing-domain" comes from the d= field of the third party signer?
and "email-address domain" is from the Author Domain (RFC5617)? (not
explicitly stated). Is so can the same "author domain" terminology be used?
This would also simplify the wording in section 7.
5.1
Isn't this the same as ADSP based on the section 4 definitions? As an author
of example.com I put a TPA-Label of:
From Appendix A:
## "isp.com" TPA-Label ##
_HGSSD3SNMI6635J5743VDJHAJKMPMFIF._adsp._domainkey.example.com. IN TXT
"dkim=all; tpa=isp.com; scope=F;"
So now I'm allowing isp.com to be a third party sender of example.com. The
verification of a TPA will use the author domain, example.com, and the
d=isp.com as the TPA-Label finding this record. This will say that isp.com can
exist in the From address at the same time as example.com (as the author
domain). So this scope is for when multiple From address fields are in an
email and alters the ADSP RFC section 3.
Am I understanding this right?
5.2
small nitpick - only some of resent-* are mailboxes/address-list
http://tools.ietf.org/html/rfc5322#section-3.6.6
Wouldn't resent messages still have valid first party signatures (assuming no
key rollover)?
"rfc5322"
"The purpose of
using resent fields is to have the message appear to the final
recipient as if it were sent directly by the original sender"
If author domain key rollover is a valid consideration maybe only Resent-From
and Resent-Sender should be specified here as they are the only fields to be
associated with a third party signature.
5.*
Suggest add a specific maillist scope - mail lists may be run off a domain
shared with ordinary users. Making it harder for user's to spoof messages by
scoping to a mailiing List-id could be useful. This assumes the domain has
some controls preventing the abliltiy of users to add list-id tags but either
way, TP delegation is based on trust.
suggest text:
{{{
4 - add "L List-ID"
5.X List-ID Header Field
The "L" scope asserts that the list-id [rfc2919 section 3] in the List-ID
header field within a TPA-Label listed domain is authorized to be signed by
the TPA-Label listed domain.
7 "When a TPA-Label TXT resource record within the From header field has a
scope tag of "L", the list identifier (list-id) [rfc2919] is within the TPA-
Label listed domain, use of this command by this domain is authorized by the
Author's Domain."
}}}
5.4
"This scope might be used to better ensure DKIM signatures within messages
from these hosts are validated."
I was guessing that only valid DKIM-signatures with a d= field should be
looked at for the purposes of TPA authentication? Where this is or is not the
intent should maybe be stated (or ruled out of scope). Which every way is
chosen I'd avoid making one scope parameter to do with EHLO/HELO commands have
the additional burden of DKIM signature validation.
5.*
nitpic: TPA-Labeled domain*s* is a list and in the 5.* sections should always
be referred to in a plural sense.
8.
eventually should contain some updates to rfc5451
Appendix A
#### 5322.From authorization for TP domains ####
_adsp._domainkey.example.com. IN TXT
"dkim=all; scope=F:O:M;"
I don't think this form of TP is defined in the document. Could be wrong.
Thanks Doug,
Daniel
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html