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 am not sufficiently expert in how all of the different parts of MIME interact,
and whether it would be better to put the certificates in one part or the other.
I'm happy to leave those details up to you folks. I was just responding the
Stefan's comments, and want to make sure that some of these other points weren't
forgotten.
(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.)
I'm with you, at least up to the point where you start talking about separate
messages. Then I begin to lose you, especially when thinking about the message
archive/retrieval/revalidation problem??
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.
I'm very happy to see that, and think it's a real improvement. I'm sure that you
remember the discussion that Sead Muftic and I had regarding the feasibility of
the
CA providing a signed confirmation that all of the certificates were in order
as of
the time that a message was received or processed through that CA. Including
all of
the certificates and the curretn CRLs would greatly facilitate that.
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.
I completely agree. In particular, that's why I feel the way that I do about the
key selector issue! :-) But as to the optional part issue, I'll pass.
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.
I agree that it is too early to tell which way is "best." "Pushing" certificates
and CRLs may waste bandwidth for those who don't need them, and including
certificates in messages wastes bandwidth for those who already have them. But
the
system was also designed to facilitate a more off-line mode of operation, and
including certificate in messages might help that. bottom-line is that both
modes
probably need to be supported, at least until the dust settles.
Bob
--------------------------------
Robert R. Jueneman
Staff Scientist
Wireless and Secure Systems Laboratory
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820