On August 23, 2005 at 13:53, Jim Fenton wrote:
This goes to what we have been very generically calling first-party and
third-party signatures. The original submission of a message would
normally result in a first-party signature from the supposed author's
domain. A mailing list would apply a third-party signature, which can
be distinguished by the fact that i= does not match the originator's
address.
I think this is a weak inference.
I'm not sure it is safe to infer that a "first-party" signature can
be adequately represented by the i= matching the OA. First, i= does
not have to be complete mailbox specification, so all you have to go
by is the domain portion.
Then, what about service relationships where the author/sending
party is of one domain, but submit all mail through another domain
(due to a service agreement between the two parties)?
In order to satisfy the first-party aspects of the signature,
the mail service domain would have to make sure that the i= and d=
match the OA's domain, and that the OA domain defines the correct
DNS records (which the mail service domain may not have the ability
to do directly) to support signature validation. This makes key
management a problem since the mail domain will own the private key,
but not have the direct ability to publish the public key.
Wrt key management, if the OA domain has the ability specify who is
allowed to perform "first-party" signatures (like through the SSP
record), the mail service domain can handle all the key management
issues without having to coordinate with the OA domain. This can be
a problem if keys are rotated on a frequent basis. SSP records will
be more stable, so OA coordination is not as involved.
BTW, a good reason for the local-part on i= is that it if the original
purported author and the mailing list are in the same domain, it's still
possible for the list to apply a signature and not have it look like a
first-party signature.
Are you saying for a signature to be "first-party" the i= must
of a complete mailbox address value?
--ewh
_______________________________________________
ietf-dkim mailing list
http://dkim.org