iMIP and MIME
Clint Talbert
I'm working on adding iMIP support for lightning, and in order to do
that, there is some integration required in the mime handler. I've
started doing this by extending/modifying the interfaces of the
nsSimpleMimeConverter interface since that was what lightning was
already using. Essentially, it was extended to pull more items from the
mime description such as content type and the content-type method
parameter (if it exists).
In the first edition (non-lightning) of our mime calendar handling, we
extended the provided mime/cthandlers/calendar/mimecal.cpp code to
create meeting requests. I don't see why this couldn't be used for
lightning as well.
I want to land the proper Mime changes for Lightning's iMIP support.
iMIP has several security considerations that will have to be handled by
whichever of the above MIME classes we use (these are detailed in RFC
2447). Before I start debugging through the Mime code again in search
of these answers, I thought I'd ask a few high-level questions regarding
iMIP and Mime:
1. Can either of these classes retrieve the signer of a message? How?
2. What happens if the message's signing is not correct? Is there a test
application that can generate a message like this so I can debug what
happens?
3. The MIME spec (RFC 2447) talks about signing a calendar object
specifically. To my mind, it appears that would be the same as signing a
message itself. Is there some MIME configuration where the parts can
have different signers than the overall message? For example, what
happens if someone forwards a signed message with a calendar object
attached?
4. Is the "METHOD" parameter of the content-type attribute used for any
other MIME type? Is that an iMIP specific attribute?
5. In your minds, should the iMIP calendar stuff be confined to
mimecal.cpp or nsSimpleMimeConverter or some other location?
I've written a very simple iMIP prototype (you can get the code at
www.cmtalbert.com/mozilla/index.html), but before submitting bugs to
bugzilla and attempting to propose patches to those bugs, I want to have
these high-level questions resolved so that I'm not wasting your time
proposing changes that don't fit into the Mime component's scheme.
Thanks for the help,
Clint Talbert
David Bienvenu
> iMIP has several security considerations that will have to be handled by
> whichever of the above MIME classes we use (these are detailed in RFC
> 2447). Before I start debugging through the Mime code again in search
> of these answers, I thought I'd ask a few high-level questions regarding
> iMIP and Mime:
> 1. Can either of these classes retrieve the signer of a message? How?
>
notification that mime emits when parsing a message. But the problem is
that there can only be one of those, and the smime ui currently provides
an smimeHeaderSink to mime (see
http://lxr.mozilla.org/seamonkey/source/mailnews/extensions/smime/resources/content/msgHdrViewSMIMEOverlay.js#177
andhttp://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimemcms.cpp#441
> 2. What happens if the message's signing is not correct? Is there a test
> application that can generate a message like this so I can debug what
> happens?
>
In the UI, I believe it displays a broken signature. You might look at
the s-mime extension (extensions/smime) and see how it decides to put up
the broken signature - I think that's also through smimeHeaderSink. I
don't know of a test app to generate an invalid signature, but it should
be pretty easy to corrupt one :-)
> 3. The MIME spec (RFC 2447) talks about signing a calendar object
> specifically. To my mind, it appears that would be the same as signing a
> message itself. Is there some MIME configuration where the parts can
> have different signers than the overall message? For example, what
> happens if someone forwards a signed message with a calendar object
> attached?
>
Objects can be signed, and presumably with different signers, but how
that works is a question for the smime experts like kaie:
ken...@redhat.com. In fact, Kaie knows much more about all of this than
I do.
> 4. Is the "METHOD" parameter of the content-type attribute used for any
> other MIME type? Is that an iMIP specific attribute?
>
I don't know, but shouldn't you only care if the mime type is a type you
care about? I don't think you can assume that some other current or
future mime type won't use a "method" parameter.
> 5. In your minds, should the iMIP calendar stuff be confined to
> mimecal.cpp or nsSimpleMimeConverter or some other location?
>
If I'm understanding the question, mimecal.cpp sounds like the right
place. nsSimpleMimeConverter is supposed to be generic.
- David
Kai Engert
I usually don't read this group. You might want to crosspost future
questions about S/Mime to mozilla.dev.tech.crypto
David Bienvenu wrote:
> Clint Talbert wrote:
>> 1. Can either of these classes retrieve the signer of a message? How?
>>
> I suspect you need to be an smimeHeaderSink and get the signedStatus
> notification that mime emits when parsing a message. But the problem is
> that there can only be one of those, and the smime ui currently provides
> an smimeHeaderSink to mime (see
> http://lxr.mozilla.org/seamonkey/source/mailnews/extensions/smime/resources/content/msgHdrViewSMIMEOverlay.js#177
> and http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimemcms.cpp#441
Yes. Maybe we could extend our signedStatus function to post an event
whenever a new signature status is available?
As you can at the end of that .js file, we are using a event mechanism
to listen for other mail window events. This file could be a produced of
events, and you and other's could be consumers of these new events. Feel
free to propose a patch to implement that.
>> 2. What happens if the message's signing is not correct? Is there a test
>> application that can generate a message like this so I can debug what
>> happens?
>>
> In the UI, I believe it displays a broken signature. You might look at
> the s-mime extension (extensions/smime) and see how it decides to put up
> the broken signature - I think that's also through smimeHeaderSink.
Yes, it happens in the same JS function signedStatus, where we set
gSignedUINode and gStatusBar to appropriate images.
> I
> don't know of a test app to generate an invalid signature, but it should
> be pretty easy to corrupt one :-)
Right. Just copy a message with a good signature to a local folder, open
that mailbox file in your text editor, change any char in the message
body, look at the message again, and you'll see a broken signature.
>> 3. The MIME spec (RFC 2447) talks about signing a calendar object
>> specifically. To my mind, it appears that would be the same as signing a
>> message itself. Is there some MIME configuration where the parts can
>> have different signers than the overall message? For example, what
>> happens if someone forwards a signed message with a calendar object
>> attached?
Mozilla Mail is already able to deal with nested signed messages.
If A sends a signed message to B, B can forward this message (as an
attachment) to C and add a signature, too.
If C opens the message, a signature from B will be displayed. In the
list of attachments, the attached message will be displayed.
C can double click / right click open the attached message to open and
display it in its own window. That window will show the original message
from A, and will also display the signature from A. You can verify that
by using "view message security info" (or clicking the signature icon),
you'll get a box saying "signed by A".
Kai