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.)
Bob,
Let me emphasize some aspects of the MIME-PEM design that address your point.
The multipart construct in MIME makes it possible to send any combination
of body parts for any purpose. In particular, one can send a MIME-PEM
message in one part of a multipart/mixed and include keys, certificates,
etc. in another part. No special addition to the security-specific design
is needed. If the multipart/security type is extended to permit the
inclusion of certificates, it will create an additional mechanism for doing
something that is already provided. This is not necessarily terrible, but
we should keep clearly in mind that this adds *no* additional functionality
over what is already included and merely reduces a couple of lines of
encapsulation.
(I can well imagine someone falling into the trap of thinking that
certificates which are included in a multipart/security are somehow more
closely associated with the message than certificates which are transmitted
in a separate body part or which are transmitted in an entirely separate
message. This is indeed a trap, I hope no one falls in.)
Another consequence of the current design is that it is possible to
transmit both certificates and CRLs in the same message that carries a
signed and/or encrypted body part. This is in contrast to the 1421
specification which required CRLs to be transmitted in completely separate
messages. It was therefore impossible in 1421 to transmit a message and
all of the supporting authentication information. In MIME-PEM, it is
completely stragithforward to transmit a signed and/or encrypted message
and all of the supporting certificates and CRLS. It's not *required*, of
course, but it is permitted.
Returning to the issue of whether to add an optional part to
multipart/security, my feeling is that it's unnecessary. There's an old
adage, quoted to me by Dave Walden in the early days of protocol design,
that is something to the effect that a system is not done when you've added
everything you can think of; it's only finished when you've taken out
everything that doesn't need to be there.
Finally, with respect to whether certificates should be "pushed" or
"pulled", we wrestled with that during the initial experiences with PEM.
My conclusion so far is that there should be servers available to provide
certificates, and that these servers should be run by whomever is operating
MIME-PEM, i.e. on every mail system, and it should respond to email and
perhaps other forms of query.
Steve
--------------------
Steve Crocker
CyberCash, Inc. Work: +1 703 620 1222
2086 Hunters Crest Way Fax: +1 703 391 2651
Vienna, VA 22181
crocker(_at_)cybercash(_dot_)com