Re: [lamps] smile.p7m as attachments in MUA

Hi again working group and thank you for the previous advice!

We are graduate students who are working on a research project to implement S/MIME+DANE functionality in Outlook clients, and we want the produced emails to be cross-compatible with other S/MIME capable MUAs.We followed the group’s previous advice to review the RFC, and we seem to be running into a limitation in Outlook that is hampering us from following that guidance.  We know Outlook has native support for S/MIME but integrating DANE through the Add-on framework (Outlook.js) seems to make following the RFCs a non-starter.  We are hoping this is user-error on our side, but we’ve exhausted all the options we can think of.  Any guidance to help us be able to follow the RFCs more faithfully would be greatly appreciated.

 The details of our approach are below:

Critically, while implementing our add-on in the Outlook.js framework we are not able to change MIME headers beyond the highest-level nudging of adding attachments of certain media types or toggling modes between plain text vs html. This means our add-on has no real way to set Content-type headers to "multipart/signed" or "application/pkcs7-mime" and the like.

Our current approach is to instead attach the whole S/MIME message as an (.eml) attachment. The content of the attachment is the full MIME of the actual signed or encrypted email. The message that this .eml is attached to remain an unsecure, but readable, fallback for signed messages.

Our current idea is that this .eml file should be in practice exactly like the attachment "smime.p7m" presented by certain MUAs, in that users may click/download to render the message plus security details in local SMIME-aware software.  Without being able to adjust the headers, it does not seem like we can successfully trigger MUAs’ native S/MIME functionality.  In MUAs like Mail.app, the messages with p7m are blocked from loading and users get security warnings, so we need to do something else.

Does this pass the sanity check? We would love to be made aware of any guidance that exists for doing S/MIME with these (not too unusual) constraints.

We are hopeful to make our add-in as compatible as possible, as it's a neat marriage of DANE and email security.

Thanks!

________________________________
From: Pavan Kumar Dinesh <pdinesh@gmu.edu>
Sent: Wednesday, June 29, 2022 1:53:31 PM
To: Russ Housley <housley@vigilsec.com>
Cc: LAMPS <spasm@ietf.org>; Tawhidul Islam <tislam20@gmu.edu>; Eric Osterweil <eoster@gmu.edu>
Subject: Re: [lamps] smile.p7m as attachments in MUA

Thank you, Russ, for the quick response. Sorry about the delay in getting back to you. We went through the Section 3.2.1 of RFC 8551 and we've gotten more insight and will report back on some of the blockers we're having in a while on the same thread.

Thanks again.

________________________________
From: Russ Housley <housley@vigilsec.com>
Sent: Saturday, June 18, 2022 11:37 AM
To: Pavan Kumar Dinesh <pdinesh@gmu.edu>
Cc: LAMPS <spasm@ietf.org>; Tawhidul Islam <tislam20@gmu.edu>; Eric Osterweil <eoster@gmu.edu>
Subject: Re: [lamps] smile.p7m as attachments in MUA

Please see Section 3.2.1 of RFC 8551.

Russ

On Jun 18, 2022, at 10:41 AM, Pavan Kumar Dinesh <pdinesh@gmu.edu<mailto:pdinesh@gmu.edu>> wrote:

TLDR: Is "smime.p7m" a file that is attached to emails, or a reserved name used by recipient MUAs that represents the source MIME of the email?

Hello,

We are students working on an MUA extension that sends SMIME emails as attachments.
A file containing the "multipart/signed" or "application/pkcs7-mime" MIME structures is attached to the email being sent.

>From our understanding, this should be similar to how MUAs sometimes show SMIME messages as an attachment called "smime.p7m". RFC 8551 describes .p7m as the extension for "application/pkcs7-mime", and examples include Content-Disposition: attachment (Section 3.3).

However, when calling the attachment "smime.p7m" (Or really anything with the ".p7m" extension) , certain MUA (Apple Mail) has odd behavior on the recipient side, renaming the attachment to "Mail Attachment.eml" and showing security warnings for user before message displayed. This occurs no matter the content of the attached file. This makes us suspect sending emails with *.p7m named attachments is not widely compatible (perhaps a conflict with reserved file names for the MUA).

Any words of wisdom on what "smime.p7m" actually is when mail clients show it as an attachment? Is that something we can send as an attachment at all?

Thank you!
_______________________________________________
Spasm mailing list
Spasm@ietf.org<mailto:Spasm@ietf.org>
https://www.ietf.org/mailman/listinfo/spasm