Subject: Re: [ietf-dkim] The mystery of third party signatures

From: Franck Martin <[email-masked]>
Date: Wed, 7 Oct 2009 10:02:22 +1200 (FJT)

Just on 3rd party signing and mainly for my own benefit (and hopefully yours) I see a few cases I'll try to describe.

1) I send an email to a mailing list, I first party dkim sign the email

Considering mailman behavior, what does it do with this email?

-It could resend it as is, adding a third party signature, but usually mailman will modify the subject adding [list topic] to the subject and also adding a footer or header, therefore breaking the 1st party signature. So mailman should not modify subject nor add headers/footers in the message

-It could change the from, remove the first party signature, and apply its own signature either as first party or third party, but then we would not know who sent the original email unless we move the original from: to the Sender: header. In this case mailman can change the subject and add headers footers.

2) I have a web app that sends emails with multiple identities. The web app could do a third party signing, but with each identity may require to have a dkim key to be able to do first party signing.

Did I miss some cases?

It seems to me, that in all cases, third party signing cannot exists on its own without valid first party signing?

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Franck Martin <[email-masked]>
Date: Thu, 8 Oct 2009 09:24:09 +1200 (FJT)

----- "Barry Leiba" <[email-masked]> wrote:

> Mike says...
> > All of this is rather academic though: the big guys are signing now
> because they can
> > find some biz justification to do so. Until that biz justification
> percolates down,
> > it doesn't really make much difference what we do. When it does, the
> DNS "problem"
> > will evaporate.
> 
> I think this is really the bottom line.  Deployment difficulties and
> delays always show up with new things.  If the new thing becomes
> popular, the difficulties go away, and we wonder why we ever had
> trouble with them.
> 
> S/MIME has been brought up as an example of the difficulty, and it
> actually helps show how this works: there isn't much trouble with
> S/MIME any more, not directly.  Most mail programs support it now
> (alas, not Gmail), and the level of interoperability is good.  The
> trouble now isn't with S/MIME, but with certificate distribution and
> management.  There's also very little need for most people to use
> S/MIME with most of their email.
> 
Which was exactly my point, the implementation part of s/mime at the user level is so cumbersome that no ones bother. The defection of the NOGs (and other groups) from the IETF removes a certain level of reality check to somehow good protocols.

Similarly, it seems to me, for DKIM to work on mailing list, mailman would need to work in a very specific configuration that no mailing list is currently using.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html