Might I suggest that we move the Security Multiparts document onto the
standards track now, and then focus on the PEM and MIME document? I feel
that most people's objection to MIME-PEM seem to be the PEM and MIME
stuff, and not the multipart stuff.
Even if we do as Bob suggests and rewind the clock to some MIME-ized
version of 1421's mechanisms, we will still need to use the multipart
mechanisms to acheive it. They are the best part of this whole proposal
and I have not seen any substantial objections to them in recent weeks.
The only suggestion that I have for the multipart stuff is that of
distributing key data. i.e. putting the key data in as an optional third
body part. I don't think this will cause too much grief with some text
along the following lines:
Multipart/signed consists of two or more body parts. The
first is the body part being signed. The second and following
parts contain either signature information for the first body
part or contain key identification information. These two kinds
of body parts are distinguished by the "protocol" parameter:
if a Content-Type appears in that parameter then the body part
contains signature information; otherwise key information.
It is recommended that signature parts come before key parts.
Multipart/encrypted consists of two or more body parts.
The first contains information on the encryption algorithms
and keys used to encrypt the second body part which must
be application/octet-stream. The third and following
body parts contain key identification information as for
multipart/signed.
However, I won't kick up a stink if this isn't included. Push them through
as is and I'll still be happy.
Cheers,
Rhys.
--
Rhys Weatherley, Queensland University of Technology, Brisbane, Australia.
E-mail: rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au "net.maturity is knowing
when NOT to followup"