No technical justification has been offered for why PEM requires
nested encodings.
Let me make one thing perfectly clear (I love that line), PEM does not
require nested encodings. However, there WILL be users of PEM who will
require nested encodings. There WILL exist security requirements
stating that the structure of the message is as sensitive as the message
itself. As Marshall suggests, what is required is to have user agents
that allow both options and let the market decide.
1) Having followed a particular design path for some years, the
PEM group is unwilling to modify their design to conform to
MIME and rather wants MIME to conform to PEM. The
fundamental problem is that PEM wants to be at the top
structural level of a message, conflicting with MIME.
This is patently false. PEM has no such requirement, needs no such
requirement, and wants no such requirement.
In fact, it would be broken for PEM to be at the top conflicting with
MIME. In the worst case you would require a C-T of say,
"application/pem", where everything else in the body is encrypted and
encoded. This is not in conflict with MIME.
2) The architect of PEM, being on IAB, is politically powerful
and has the clout to push through architectural decisions no
matter what technical objections may exist.
The architectural issue that is outstanding is revising the PEM specs to
operate on arbitrary input streams rather than RFC 822 messages. There
is resistance to revising the PEM specs because it would delay an
already painfully slow process.
Jim