I am a little confused, perhaps because of your (legitimate)
separation of specification from implementation issues, and
perhaps also by the degree to which the spec is at least
somewhat dependent upon the underlying 1422 mechanisms.
The PEM/MIME specification is in no way dependent on the 1422
mechanisms. It does, however, allow for their use.
What I THINK you are saying, with respect to the PEM/MIME spec,
is that you don't care what is done to or with the certificate
-- that that is the responsibility of the underlying RFC1422
layer. "You", i.e., the upper(?) layer of the PEM/MIME portion
merely pick up the public key from the "1422" code, and somehow
find the private key, and proceed to do your thing. In the case
of bare keys, you skip the "1422" stuff, and proceed to
manipulate the keys directly. Is that approximately correct?
Yes.
Assuming that we upgrade to v3, perhaps in six months or so
after the ISO spec is firmed up, and perhaps after we have had a
chance to consider how best to take advantage of it, will your
_implementation_, and presumably any other PEM/MIME
implementation, be in a position to implement v3?
Yes. Note, however, this is not a PEM/MIME issue but rather an issue
for the layer that handles certificates.
I'm assuming the PEM/MIME won't have any problem wrapping a
certificate (or a bare key and some identity information) in a
security multipart, and then encrypting that in the recipient's
key, but could you walk me through all of this would be
unraveled by the recipient, and either the certificate or the
bare key and identity information neatly stashed away? Would
this happen automatically, or would a lot of manual processing
be required?
Answering your last question first (and the question about recipient
unraveling), it depends on the user agent with which you're working.
With the MH user agent we provide with our PEM implementation, there is
a small amount of direct user interaction on origination and potentially
no interaction for the recipient.
With respect to your first question,
1. create an application/pemkey-data body part as described by the
PEM/MIME specification - you either put certificate or bare public
key in this body part
2. create a multipart/signed body part where what you sign is the
application/pemkey-data body part
3. create a multipart/encrypted body part where what you encrypt is the
multipart/signed body part
The interactions necessary to do this are completely dependent on the
MIME user agent being used.
Jim