What's your feeling about using the MIME multipart mechanism to transmit
both a MIEM-PEM message and key data instead of extending the security
multipart? In symbolic terms, taking a bit of license with terminology,
the comparison between what exists and what you're proposing is something
like:
mp_mix(mp_sec(app_enc(M),app_keys(K)),app_keydata(KK)) vs
This is how I'd always envisioned doing it, although I might have used
multipart/parallel instead of multpart/mixed.
mp_sec(app_enc(M),app_keys(K),app_keydata(KK))
I really have no objection to this approach either. It has the virtue that it
simplifies the MIME handling somewhat, as well as somewhat simplifying the
appearance of such messages on a non-MIME viewer (we're talking about 2
additional lines of trash at the top of the message, but its amazing what
users can get bent out of shape over).
I'm willing to go along with this change if the editors (Jim and Sandy) feel
it can be implemented in reasonable time...
I'm rather against such a construction. I'm more in favor of messages sent
without the corresponding key (relying on some kind of local key database.
This is probably due to my pgp backgorund :-)
Also I (again) feel like the "next" parts could be used for additional
signature parts, and even though I can see how to move the key-data out of
the security part, I fail to see how to move additional signatures out of it
(without forcing nested sigs). Of course it might be possible to mix sigs
and key data parts...
Stefan