I have read
Network Working Group Steve Crocker
Internet Draft Ned Freed
Marshall Rose
MIME-PEM Interaction
Mon Jan 11 02:20:00 1993.
I believe I understand the global motives, and the specific mechanisms.
And I see how, when MIME-UAs are ubiquitous, all my problems will be resolved:
I have a need: to securely tunnel secured-X.420 IPMs
over Internet mail. I suggest therefore that this need is within the
purview of this WG. I would also like to sign the contents of
my X.500 Directory entry with PEM, rather that with semi-conformant,
unadopted, secured-ODA wrapper, as at present.
Now the MIME-PEM interaction and MIME-X.400 are well-advanced. However they
presume ubiquitous MIME-UAs and ubiquitous MIMEd-X.400/SMTP gateways, and
ubiquitous PEM-capable X.400 user agents.
-------------
I would like to suggest that PEM profile itself to support a simple, new
Content-Type - ASN.1. Just as 822 Content-Type removes the need for
remote UAs to know the other parties local processing capabilities, so
Content-Type: ASN1 would perform the same function, but thereby
removing the character-based limitations of 822-valid PEMmed sources.
What do we do about MIC-CLEAR in the case of Content-Type: ASN.1.
Either define PEM ASN.1 profile such that the combination is
non-conformant to the profile, else require MIC-"CLEAR" of any
Presentation-Data-Value to actually be encoded as per MIC-ONLY
<pemtext> conventions as the "clear" form. The processing required is
unambigous from the headers, and simple.
This is not meant to divert MIME. Just a easy profile addition which
make PEM useful to a wider community now.
-------------
The only detraction I can think of is that it makes PEM compete with
PKCS-#7 - a cryptographic message general syntax standard for data
(nicely expressed (and real easy to implement) in ASN.1).
On the +ve side, a MIC-ONLY would nicely encapulate PKCS#7
secure-object streams for mail transmission, delivery etc should it
permit the ASN.1 content-type.
If the term content-type ASN.1 is not sufficiently clear, as one may
validly argue, then the profile could permit N content-type: ASN1-<obj-id>
where <obj-id> is any the numeric-form of any Object Identifier of any
registered abstract syntax. Though the ASN.1 syntaxes and modules of PKCS
dont seem to have been registered, Im sure they could be, and thus
allow communities of UAs to know if they are capable of processing
that particular PEM-ASN.1 Content, versus any other syntax.