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 :-)
Stefan, I too would like to be able to send messages without the corresponding
key
(correction, certificate :-) being included in line. It would significantly
reduce
the overall bandwidth required, especially if we consider very short, EDI-like
messages and similar applications. But we have to face the fact that robust,
widely
distributed directories are not yet deployed, and the current pgp approach seems
fraught with danger due to denial of service attacks.
In addition, even in the case of a classic PEM, hierarchical CA model, which
only
purports to accurately identify someone, and does not speak to the issue of
trust
or trustworthiness, there may be some advantage to making use of certificates
distributed with the message as a way of alllowing the user to easily "promote"
a
correspondent to a position of greater trust. It may take a few messages, but
perhaps after reading and exchanging messages for a while I decide that I like
and
trust you, and I can click on a button and give you some more exalted status.
Obviously this could also be done with a local or even global directory
approach,
but it may be more "natural" do do it in line.
Also, especially when the systems are first being widely deployed, some people
may
have easy and rapid access to an online directory and some may not. for
example, if
I am a mobile user, accessing my mail via my laptop, I may periodically dial in
and
dump all the mail that has accumulated to my laptop, then disconnect. The
PEM/MIME
processing would take place on my laptop, not back at my mail server, so I can
still enjoy both privacy and integrity. However, if I have to have access to an
online directory, I am almost forced to use PPP or SLIP and stay connected
while I
actually _read_ my mail. this can be quite costly, and in some environments,
such
as when operating over cellular in a moving vehicle with attndant drop-outs,
quite
impractical.
Finally, there is the issue of archiving the certificates along with the
messages
for long-term storage. Even when that grand day arrives and X.500 is deployed
world-wide, the directory will only represent a single snapshot of the currently
available certificates. As users come and go, their certificates will expire or
be
revoked and pruged from the directory. But those certificates will still be
required to validate previously received messages, and by far the most
convenient
and obvious place to store those certificates is with the messages themselves,
even
at the cost of some redundant storage.
So my conclusion is that even if we chose not to send the certificates with the
messsage as a routine practice, we should architect a place within the message
to
hold those certificates and allow the originating user the option to send them
or
not send them.
(I almost wish that the intended recipient's certificate could indicate his
preference as to whether certificates should be included or not, but that might
be
going too far, especially considering mailing lists.)
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...
I'll leave it to you guys to suggest the best way to include thecertificate
information, as long as it is optional either way.
Bob