Ned,
In a two messages recentlt you commented about the 1421
version of PEM not being restricted to protecting an entire message
content. I don't think this is true in the most general sense,
although there is room for confusion here. We did, at one time,
experiment with partial context protection, but found it too complex
in the vanilla (non-MIME) 822 context, so we dropped the facility.
One can forward a 1421-PEM protected message, so there is some aspect
of partial content protection, but certainly not nearly as felxible as
what is being developed for MIME-PEM. Also, one can apply PEM to any
text (or any data encoded into text format) in an offline fashion and
then insert the result into a message, which would, indeed, yield a
content with mixed PEM and non-PEM components. However, the general
model for PEM when integrated with a UA is one in which the entire
content is protected.
Another reason we dropped the partial content protection, as a
major feature, was that we were concerned about the ability of user
agents to accurately represent to a user just what portions of a
message were and were not protected, especially with regard to
authenticated and integrity checked (but not encrypted) data. I think
these concerns are still valid in the MIME-PEM context, and we just
have to hope that user agents do a good enough job to prevent users
from being spoofed. Perhaps this is one of the concerns Peter is
alluding to.
You also commented about the inability of PEM to identify the
format of a secured content. We did include the Content-Domain
construct as a hook for representing other than simple text messages
as the protected content, though this is certainly not as flexible and
general as the MIME facilities. In fact, the intent was to use this
as a simple means of identifying when MIME messages were the protecte
content. Again, though, the result is not nearly as general as that
described in the current set of IDs.
PEM explicitly does not include message header information
because some of that information is changed between source and
destination and thus it would be inapprorpiate to include it, in
general. (You rightly distinguish between headers and envelope info,
which makes sense in MIME but is harder to break out in non-MIME
mail.) PEM does provide for inclusion of header/envelope fields by
the user, but does not treat them specially, and we recommened against
doing this in general. For example, the TO and CC fields may be
transformed on an outgoing message (from local representations to
fullly qualified mailbox names), so including the original form of
this field within a protective, opaque boundary will yield a value at
a recipient that may be of little value and might even cause confusion
and problems, e.g., the value may be totally unsuitable for REPLY
purposes. Still, in MIME, if some of the headers contain (redundant?)
envelope information, the possiblity for confusion exists.
Perhaps, in this vein, Peter is arguing that there is a need
to provide advice about what does and does not make sense in terms of
the very general capabilities offered by the generic encryption and
signature constructs. However, because these constructs are so
general, I agree with your observation that it is impossible to
enumerate allowed and not allowed uses. One can adopt a more
restrictive approach in an effort to protect users from surprizes, or
can adopt a more flexible approach and hope for the best. Each
approach has its pros and cons, as have been argued here before.
Steve