Re: MML multipart tag -- what does it do?

[Simon Josefsson <jas@extundo.com>]

Florian Weimer <fw@deneb.enyo.de> writes:

> Simon Josefsson <jas@extundo.com> writes:
> 
>> This requires users to know how the sign/encrypt mechanism they use
>> are implemented in MIME.  E.g., if you want to sign using PGP/MIME you
>> must write the above, if you want to encrypt with S/MIME you need to
>> write something completely different because S/MIME encryption doesn't
>> use RFC 1847.
> 
> Really?  I assumed it did, and using S/MIME in a RFC 1847 context is
> indeed described in the S/MIME RFCs...

Not for encryption.

The application/pkcs7-mime type may also contain signed data as well,
so you don't need RFC 1847 to use S/MIME fully.  (a/pkcs7-mime basicly
just contains a PKCS#7 blob, which might contain lots of stuff.)

I've no idea why.  I think it would've been trivial to take the same
approach as RFC 2015 did (the first part just being some dummy
"Version: 1" and the second everything that is in the current
application/pkcs7-mime part).  It's interesting to note that searching
the IETF S/MIME mailing list 1996-2001 for multipart/encrypted gives
one match, and it's irrelevant.  Hmm.

Also, the "mime" in "sign=pgpmime" was deliberately chosen, so that
you could support "sign=pgp" (plain PGP) via MML at some point, and
the current approach would work nicely with that.  Then we would be
able to send mail to people with Outlook with crippled PGP plugins
(which seem to be a quite large population).