Minimal MIME Conformance for PEM-ONLY Using MIME/PEM
The use of MIME/PEM for all PEM messages does not add excessive
complexity beyond the requirements imposed by RFC 1421 and offers
significant advantages. Below are a list of the minimal
requirements for conformance with MIME and a discusison of their
impact on a 822-PEM implementation.
MIME Receiver requirements.
MIME specifies a message structuring system, but imposes minimal
requirements on an implementation to actually understand and process
an arbitrary content. It is possible to be mime-complient and
support no content-type beyond simple text. Below are the minimal
requirements a PEM only implementation need implement.
1) Recognise the MIME-Version header
2) Recognise the Content-Transfer-Encoding header and be able to
decode both the Base-64 and the Quoted-Printable encoding.
Impact: A MIME based PEM implementation will have to add support for
quoted printable. Protection from false MIC-failure is gained when
quoted-printable, designed to be as human reader friendly as
possible, is used in place of MIC-CLEAR.
3) Recognise the content-type header. The only content types which
need to be explicitly supported are TEXT and MULTIPART.
Impact: The content type header provides the functionality
explicitly provided in the content-domain header, plus explict
character set specification.
o Text: A conformant implementation must be able to display ASCII
Text to the user. It must also be able to recognise and display
characters 0-127 from the ISO 8859-n character sets. (ISO 8859 is a
strict superset of ASCII)
Impact: Minimal. This requirement just makes explicit assumptions
accepted in RFC1421 as to the character set in use. The 8859
character sets are commonly referred to as 8bit ASCII, and while
nominally prohibited from being sent "raw" by RFC 821, they are in
use in many parts of the Internet.
o Multipart: A conformant implementation must be able to parse a
message structured according to RFC 1341 MIME. RFC 1421 is based on
the RFC 934 multi-part structure with its known weaknesses. (Line
wrap corruption)
Impact: MIME Multipart decoding is minimally more complex than
RFC934. The only semantic addition is the requirement to support
multipart/alternative. (for a full discussion see RFC 1421)
o Message: A conformant implementation will recognise the
message/RFC822 content-type as an encapsulated message and will
display it as such. (This may be a forwarded RFC 822 message)
o Other Content-types: All other content types not otherwise
supported must be supported at least as Application/Octet-stream,
meaning that a user should be presented with the option to have the
content-transfer-encoding reversed and the content written to a
file.
MIME Requirements for Senders
1) Must generate a MIME-Version: header.
2) Must select an appropriate content-transfer-encoding for any data
not able to be sent by available transport (I.e. 7 bit line length
limited for smtp)
Impact: Depending on the character sets supported, it may be
reasonable to hard-code base-64 for encrypted body parts and
Quoted-Printable for MIC-ONLY body parts.
3) Must be able to construct valid multipart boundary markers for
the multipart contruct.
Impact: Minimal. Many unique-within-a-message values are available
to a PEM implementation. A MIC on the message body is highly likely
not to be in the content itself!
Related MIME/PEM Issues
Nesting or enclosing PEMed body parts inside other PEMed bodyparts
adds no more complexity than is currently present with RFC1421
encodings. Nesting privacy-enhanced body parts does not require the
support of nested transfer encodings. Any enclosed privacy enhanced
body parts are canonically binary objects and will be encoded by the
outermost body construct requiring encoding. While support of nested
encodings makes construction of included encrypted messages easier,
the MIME group concluded that the additional complexity required for
a receiving implementation was not worth the cost.
MIME <=> X.400 issues are being addressed. As I understand how the
current proposal would apply to PEM, if a direct MIME bodypart <=>
X.400 body part mapping can be made by the gateway, it will. So, if
an X.400 bodypart for PEM is defined, the PEMed part would be
converted by a gateway into the corresponding X.400 part. If a
suitable mapping was not found by the gateway, it would be tunelled
through X.400 as an MIME bodypart.
Greg Vaudreuil