I have been convinced that the requirements to deploy PEM soon are
strong enough to propose a transition strategy to MIME-PEM from
current ready-to-roll implementations of RFC1421. It is my hope that
with a mini-profile of MIME, implementors of current ready-to-deploy
software will consider adopting these small changes to the
implementation to make the transition easier to full MIME/PEM.
The following is an outline for a non-MIME compliant PEM profile which
which requires a minimum of code changes from current RFC1421 PEM
implementations. While it is not technically MIME compliant, the
following is sufficiently close to eliminate most interoperability
problems.
As I identified in the note posted Friday March 26th "Minimal MIME for
MIME/PEM", the requirements for senders of PEMed messages are truly
simple and can be implemented in current implementations quickly. I do
not propose reducing these requirements as any change is likely to
cause future pain.
These requirements again are:
1) Generate a MIME Version: 1.0 Header
2) Generate a Content-Type: Multipart/PEM construct with a unique boundary
marker. (This can for almost all cases be hard coded)
3) Support the Content-Transfer-Encoding: quoted-printable for the
generation of the MIC Clear message type. (A small routine)
The greater burden in supporting MIME/PEM is the minimum receiver
requirements. Minimal MIME requires the understanding of non-ascii
character sets, multipart/mixed, multipart/alternative, and
message/RFC822. While these requirements are not very burdensome,
they are a significant addition to current implementations. For the
purposed of transition, and to allow the rapid conversion of RFC1421
implementations to MIME/PEM compatible form, I proposed the following
sub-set of MIME be implemented for plain ascii text PEM only
receivers.
1) Recognize and parse the Content-Type: Multipart/PEM header as a
MIME-PEM message and extract the boundary delimiter.
2) Recognize the Content-Type: Text/Plain and the character set
US-ASCII as simple text.
3) Recognize the Content-Type: Application/PEM as the PEM Headers from
RFC1421.
4) Recognize the Content-Type: Application/Encrypted as the encrypted
data to be fed in to the crypto routines.
5) Report all other Content-Types to the user as "unknown" and offer
to write them to a file.
If this is a reasonable strategy, I will tighten up the wording and
add it to the MIME/PEM document as an appendix.
Greg Vaudreuil