I wrote
1) What is the reason to encapsulate clear-text PEM body parts in an
entity of type message/pem-clear, instead of including the body part
unencapsulated (e.g. as text/plain, but potentially any MIME type)?
The latter would provide better interoperation with MIME-capable UAs
that are not PEM-capable (MIME does not mandate any particular
treatment for unrecognized subtypes of message).
Several people responded to this, although nobody responded to the 2nd
and 3rd questions. Opinions, anyone?
Carl Ellison <cme(_at_)ellisun(_dot_)sw(_dot_)stratus(_dot_)com> responded
pem-clear is useful in case you have a mail agent someplace who
changes text (converts tabs to blanks, strips trailing blanks, ...).
This way you know what to sign and what not to.
Protection agains this should be done by using a MIME content-transfer-
encoding which was designed for this purpose.
Derek Atkins <warlord(_at_)MIT(_dot_)EDU> responded
If you DON'T do this, then how do you distinguish between signed
clear-text and non-signed clear-text? If all you use is text/plain,
then you have no way to distinguish the two (other than by context).
And I think context parsing isn't part of MIME (but I'm not sure about
this).
You are wrong. The mere fact that text/plain (or any other content type)
is included in multipart/pem indicate that it is signed. Otherwise, what
is the purpose of the application/pem data?
Raymond Lau <raylau(_at_)MIT(_dot_)EDU> reacted
I think my real question is why both message/pem-clear and
application/encrypted are needed whereas a single C-T may suffice.
A new content type is needed for encryption, otherwise existing MIME
software will interpret the encrypted body as if it was unencrypted.
But I think you are right that no new content type is needed for
unencrypted messages.
David Herron <david(_at_)twg(_dot_)com> wrote
Is tagging anything more than the MD5 stuff? If so you could have
Content-Type: text/plain
Content-MD5: whatever
...plain text in clear...
That is, put the tagging (digital signature and such) in the mini-header
describing the particular bodypart.
There is an I-D out that describes exactly this, but I suppose PEM offers
more then just this (message integrety is not quite the same as privacy
enhancement, which I assume includes sender verification). Still, I
agree that enhancement (not encryption) could also be done via header
fields. Why wasn't this route chosen? To work with MIME the headers
should be named Content-Something.
Can you have a tag'd but other wise NON-TEXT thing (IMAGE/GIF for
instance)?
Content-MD5 is allowed for all content-types except multipart and
message/rfc822.
Most (all) MIME UAs will have some defaulting rules. For subtypes they
don't recognize the behaviour will default in ways dependant on the type.
So message/pem-clear will default to message/rfc822 (right?), and the
UA should give the user access to any body parts enclosed within. Thus
the tagging will be ignored, but at least the user will still have access
inwards.
WRONG. MIME does not specify default behaviour like you suggest for
subtypes of message. Such defaulting is only specified for subtypes of
text and multipart (which is why multipart/pem can be used without
breaking non-PEM-aware MIME readers).
A good MIME UA should *always* give the user access to *any* body part,
but that does not mean that this should relied upon, especially if there
is a better way.
--
Luc Rooijakkers Internet:
lwj(_at_)cs(_dot_)kun(_dot_)nl
Faculty of Mathematics and Computer Science UUCP: uunet!cs.kun.nl!lwj
University of Nijmegen, the Netherlands tel. +3180652271