At the risk of being called too simplistic or ignorant, please allow
me to suggest one way to reach a closure:
1) Rename the MIME-PEM ID as "Adding Security to MIME messages" and
move it to an appropriate MIME WG (if one exists) OR form a new WG in
which case I suggest seriously integrating the much anticipated
MIME-PGP with MIME-PEM and call it Secure-MIME.
Again, you seem to be basing your analysis on outdated documents. There are two
Internet Drafts at issue here, not one. The first one is called:
Security Multiparts for MIME:
Multipart/Signed and Multipart/Encrypted
This is practically identical to the title you suggest already. This document
doesn't deal with PEM integration at all -- all it does is specify security
services for MIME. It is the second document, the one called
PEM Security Services and MIME
that specifies how PEM can be combined with MIME's security multiparts. I
expect that there will soon be one called
PGP Security Services and MIME
as well, but it isn't relevant to this working group's present activities.
I also object in the STRONGEST POSSIBLE TERMS to any attempt to move
consideration of this work to another group. This working group has already
approved these documents and we are now in the working group last call period.
It is entirely inappropriate to suggest moving them at this time, after the
authors have labored literally for years within this group to get these
documents to this point. I should also point out that far from being
dictatorial in this, every single one of the listed authors has elected to
accede to the working group's wishes in some way that ran counter to our
personal preferences. (You will find ample evidence to back up this assertion
in the list archives.)
I can only view this suggestion as a last-ditch effort to further delay these
documents on very shaky procedural grounds.
2) Make ARPA funded TIS/PEM Version 6.1 (a reference implementation of
the classic-PEM) available by anonymous ftp without added support.
This is entirely out of order, and, as I said previously, more than a little
pathetic. The availability of a reference implementation of the classic PEM
protocol has nothing to do with MIME/PEM. Indeed, this apparent attempt to hold
a set of protocols hostage to implementation of a related protocol is
completely bogus from a procedural perspective.
3) Continue to enhance the ability to deploy classic-PEM through X.509
work, various key-management solutions, and better user interfaces.
Again, almost all of this is out of order. Working groups are responsible for
defining protocols, not implementing them or directing their implementation.
Moreover, IETF working groups are not supposed to live on forever -- they are
supposed to terminate once the protocols they create are fully specified. If
you want to bring specification suggestions and changes in classic PEM or
MIME/PEM to the working group's attention, by all means do so.
Ned