Greg,
I may misunderstand what you were suggestion re MIME and PEM.
I would expect that PEM messages could be carried in MIME in their
current, encoded format by defining a suitable body part. This would
be inefficient from an encoding perspective, but feasible.
PEM already does incorporate conventions which make it message
system sensitive, e.g., the initial canonicalization performed on
plaintext before calculating the MIC. We chose the SMTP
canonicalization becuase the primary target was RFC 822 mail. If MIME
existed when we began this effort, we might have adopted a more
general approach, both for what we accept as input and what we produce
as an encoded representation for transmission, and future versions of
PEM might adopt such an approach.
However, at this point I agree with John in that I suspect it
would entail a significant effort to redefine the PEM transmission
format to accommodate MIME as an alternate mail transmission encoding
option (much less as an alternate input form). We cannot discard the
existing encoding since not everyone will have MIME-capable mail
programs, so I think we would have to add a "raw" output option for
use with MIME. All of this would take time to sort out, implement,
test, and document.
I think it reasonable to assume that a successor version of
PEM, could incorporate these added capabilities, but as PEM WG chair,
I am very reluctant to consider such extensions for this version.
Steve