Re: [lamps] S/MIME fix

[Alexey Melnikov <[e-mail]>]

On 16/05/2018 15:48, Alexey Melnikov wrote:

> 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.
Implementations that can validate HTML should check that each body part 
contains valid HTML. So if it detects partial HTML, it should reject 
displaying it or concatenating it into a single HTML object that might 
end up syntactically valid.

> 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.