Re: [lamps] S/MIME fix

[Alexey Melnikov <[e-mail]>]

On 16/05/2018 18:35, Jim Schaad wrote:

> I will note that unless multipart/mixed has some special text 
> associated with it.  Text/html is defined by RFC 1866 to only hold a 
> single HTML document.  Thus building an HTML document from multiple 
> parts is not according to Hoyle.
>
Yes, but people do this anyway, as separate HTML body parts are 
frequently valid HTML documents. So building from pieces works most(*) 
of the time.

(*) spam and phishing nonwithstanding.
>
>
> Jim
>
> *From:*Spasm <[e-mail]> *On Behalf Of *Alexey Melnikov
> *Sent:* Wednesday, May 16, 2018 7:49 AM
> *To:* Phillip Hallam-Baker <[e-mail]>; SPASM <[e-mail]>
> *Subject:* Re: [lamps] S/MIME fix
>
> Hi Philip,
>
> On 16/05/2018 15:28, Phillip Hallam-Baker wrote:
>
>     Looking at eFail, surely the simplest fix is to require that an
>     HTML message body be presented in a single CMS envelope presented
>     in a single MIME part?
>
>
> I am not sure what you mean here. A CMS envelope can contain 
> multipart/mixed within it, which is a perfectly valid use case (i.e. 
> if one wants to send some encrypted text together with some encrypted 
> attachments).
> If you are talking about preventing the following construct:
>
>
> content-type: multipart/mixed; 
> boundary=.f8231d7f-681b-442c-97cc-e6c5375d059d
>
> This is a multipart message in MIME format.
>
> --.f8231d7f-681b-442c-97cc-e6c5375d059d
> content-type: text/html
> ....some partial HTML...
> --.f8231d7f-681b-442c-97cc-e6c5375d059d
> content-disposition: inline; filename=smime.p7m
> Content-Transfer-Encoding: base64
> content-type: application/pkcs7-mime; name=smime.p7m; smime-type=enveloped-data
> ....encrypted HTML...
> --.f8231d7f-681b-442c-97cc-e6c5375d059d
> content-type: text/html
> ....some partial HTML...
> --.f8231d7f-681b-442c-97cc-e6c5375d059d--
>
>
> i.e. a multipart/mixed that contains a mixture of text/html and 
> application/pkcs7-mime, then I might agree with you. But this is not 
> really an S/MIME feature, it is a generic MIME feature. So maybe this 
> WG should write a document on best S/MIME implementation practices.
>
>
>     This would simplify the code substantially. While it is
>     conceivable someone has worked out a way to make use of this
>     mis-feature, I for one cannot imagine why Outlook, Thunderbird or
>     the like would ever do anything of the sort.
>
>     Separately, we have interest in CAA for S/MIME. Surely we should
>     do ACME for S/MIME as well.
>
>
> Not surprisingly, I agree. See draft-ietf-acme-email-smime-02
>
>     If we are going to do that, surely we should have a discussion of
>     what it would take to make end to end security the default for SMTP.
>
>     I am not necessarily thinking of this as a LAMPS thing because we
>     also need to get CAs, probably CABForum involved and maybe the
>     OpenPGP folk.
>
>
> Best Regards,
> Alexey
>