Hello,
As I mentioned during the Columbus IETF meeting, we are indeed having a hard
time implementing PEM without MIME. In our implementation, we observed that
simply inserting two constant lines in the header:
Subject: PEM
-> Mime-Version: 1.0
-> Content-Type: application/pem
Date: Wed, 11 Aug 93 16:25:48 +0200
From: Pierre Pacchioni
<Pierre(_dot_)Pacchioni(_at_)sophia(_dot_)inria(_dot_)fr>
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIBVzCCAQECBCxo69owDQYJKoZIhvcNAQECBQAwLjELMAkGA1UEBhMCRlIxDjAM
...
allowed us to automatically trigger a "PEM" filter for the incoming mail. This
mechanism is much more convenient than having to explicitly call a processing
program, or having to browse the text of every incoming message.
This is much different from the original PEM/MIME proposal that was presented
in Washington and more or less rebutted in Columbus: the text of the message
is exactly conformant to RFC-142[1234], and there is no special development
requested from a PEM receiver. The requirement to a PEM sender (adding 2
constant lines in the header) is also sort of light weight.
This simple extension is indeed much less ambitious than the original
PEM/MIME, and does not try to achieve protection of multimedia messages -- a
subject which IMHO is not completely debugged. On the other hand, it already
enables a couple of "good things", e.g. to carry a protected text
together with non protected voice segment, or to forward several PEM
protected messages in a transparent fashion. As such, it looks like a nice
first step.
What would be the feeling of this group about a small RFC describing
this convention? I would be happy to write it, but would first like to obtain
some "group consensus". Also, there may be a need to specify a couple details
-- for example, whether we want to allow other alphabets than ASCII.
Christian Huitema