Choosing, for example, between a design for a large miltary messaging
system, based, on open technology, where technical material supporting
one technical bid spec. has such a documentation format, and another
does not, would be a big factor in eliminating technical bids, I would
judge. Who wants to buy a design which refuses to make claim of what it
does, and what it does not, and what it is designed and built to not do?!
This level of description goes far beyond what these specifications can
or should be doing. These are general facilities for applying security
services to MIME messages. The properties of the result are far more
dependent on the specific service being applied than on the encapsulation
methodology used.
I disagree. First of all, there is nothing that says that RFC1421 always
protects the entire content. Second, MIME-PEM can be used to protect not
only
the entire content but also the outermost message headers, making it a
superior
service in this regard. Third, the price you pay for using RFC1421 is the
loss
of content labelling. In many cases this is too high a price to pay.
Such a superiority argument is not particularly valid when when cannot
judge its rationale against the objective it purports to support.
I quite honestly have no idea what you are talking about here.
However I recognise its subjective emotional appeal.
I'm sorry, but I see this as a purely technical matter. It is a fact that both
encapsulation schemes can be used to secure the entire message content or only
a part of it. It is therefore incorrect to see RFC1421 supposed inability to
secure anything but the entire message as an advantage. This supposed inability
and hence the enhanced security it purports to provide do not in fact exist.
It is also a fact that RFC1421 services are not defined in a way that allows
for protection of parts of the message header, whereas MIME-PEM can be used
this way.
It is also a fact that RFC1421 is not defined in a fashion that allows the
secured content's format to be identified.
These are not subjective issues.
A communications
security design which require protection of such addressing information
can easily be attacked on the difficulty which such designs make of
operating such protected systems in a massive, open technnology
communities involving many nations (as with NATO), international comms
treaties, GATT tarrifing, n generations of technology, ... but, then,
thats not what we are doing here at the IETF, is it?!
Nobody has said a single word about securing addressing information until now.
This information is part of the message envelope, not the header, and none of
these scheme provide any means to secure the message envelope. (I realize
that addressing information may appear in the message header, but there is
little point in securing this material when the stuff that matters is
elsewhere.)
The purpose of securing headers is not to secure addressing information, which
in fact is an exercise in futility, but instead to secure all the other
information headers can contain.
I thought this was all pretty obvious and hence not worth dwelling on.
we need to
concentrate on design enhancement for the privacy of Internet messages,
for the community of research and educational Internet users.
I don't know where this comment comes from or why it is at all relevant, but I
disagree with it. While the needs of research and educational users are very
important, the needs of commercial users are also important and cannot be
ignored.
For the argument to stand as it stands now, it implies that the design
objective of the existing PEM is not being satisfied by the protocol
known as RFC 1421. And this implication itself, if true, would certainly be
very significant. We should know find out from you what makes the original
assertion true, Ned, remembering the scope of our activity.
I'm sorry, but all this is hopelessly out of scope. Recall that we were
discussing whether or not the RFC1421 provides a superior service because of
its supposed inability to secure anything other than an entire message. That's
all we were discussing. I merely pointed out that this supposed inability does
not in fact exist, making RFC1421 and MIME-PEM peers on this point, and that at
least two other directly related factors could be seen as making MIME-PEM the
superior choice in this extremely limited context.
A general discussion of general utility of MIME-PEM and the inadequacies of
RFC1421 is a much broader topic, involving a multitude of other issues we
haven't even touched on here.
Ned