"MIME-PEM Interaction" Comments:
Some of this stuff can be taken care of right now... Discussion of some
of the rest of it can start now as well.
0- Nit. In section 3, the document states that PEM "allows
encryption and authentication services to be applied to electronic
mail messages." Based on the defintion of "electronic mail message"
given in this section, PEM is defined to provides security services
for the body of the message, not necessarily the message as a whole.
I agree and I have changed the wording to: "Privacy Enhanced Mail (PEM) [3-6]
allows encryption and authentication services to be applied to the contents of
electronic mail messages."
1- In section 4, the text indicates that base64
Content-Transfer-Encoding is always used for an ENCRYPTED PEM message,
but that other encodings might be used for other PEM message types.
Why?
Because there are a number of encodings that are possible (7bit, 8bit,
quoted-printable, x-?, more in the future) if encryption isn't being done and
discussion of which one is appropriate for a given unencrypted message is a
huge can of worms.
Is this trying to say that a signed (but not encrypted) message
may be transferred without encoding, i.e., MIC-CLEAR?
No. It says that there are a number of different choices are possible. There
will probably be more choices available in the future.
If so, can't
this be said more directly?
I don't think you can say it any more directly without getting into a
discussion that has resulted in hundreds of messages on the ietf-822 list and
is still unresolved in any formal sense.
We're talking about playing with fire here. While it is incontestable that
various regions of the mail-connected Internet perform ad-hoc transformations
on message bodies that corrupt anything short of base64 encoding, coming right
out and saying so leads directly to "does to! does not!" debates that never get
resolved.
If not, what is the intent? If I can
choose other encodings for non-ENCRYPTED messages, then why can't I
choose them for encrypted messages too?
You can choose quoted-printable for ENCRYPTED, but it is guaranteed much less
efficient and is always less safe. What's the point of providing a stupid
and useless choice?
I guess I would have no problem with rewording this to say that any encoding
capable of accomdating pure binary information that's compatible with the
transport being used would be appropriate for encrypted data. It does open the
door to silly uses of quoted-printable, but it also leaves room for future
encodings that might make more sense to use, such as pure binary over a
transport that can accomodate it.
If there is a desire to be
backward compatible with 822-PEM, then I think more specific text is
needed. If the intent is to permit greater flexibility in the choice
of Content-Transfer-Encodings, then why are ENCRYPTED messages
constrained?
Backwards compatibility with 822-PEM was not a major concern, but I suppose
the selection of base64 as the preferred encoding could be seen this way.
Discussion?
2- The boundary parameter defined for the multipart-pem
content type, and used in later examples, differs from the marker used
in 822-PEM, but no motivation is provided for the difference. Since
this introduces an incompatability with the existing PEM
specifications, should not the motivation for this difference be
discussed here?
The overriding motivation is compatibility with MIME, not 822-PEM. I suppose we
could note this as a reason for doing it this way, but since the entire effort
is motivated by the need for MIME compatibility this is nothing more than a
restatement of the primary goal of this entire effort.
3- The order of bodyparts in the pem Content type reverses
that currently employed in PEM and defined in the proposed standard.
The resulting format would seem to require greater modification of
current, compliant PEM implementations. The ID observes that this
transposition is motivated by a desire to make MIC-OLNY messages less
visually confusing to users not employing a PEM-capable UA.
I think that this is something that needs to be discussed. The change is in
keeping with the MIME philosophy that messages should be to the greatest extent
possible compatible with old user agents that don't understand PEM or MIME.
Placing all the PEM material at the end of cleartext message is in keeping with
this. However, it is undeniably a departure from the old 822-PEM way of doing
things and may or may not be a good idea.
A similar issue arises in 822-PEM for MIC-ONLY and MIC-CLEAR
messages, but in that context the PEM WG did not feel that the PEM
headers were substantially worse in the visual clutter they present
than the myraid header lines often present in 822 messages. Thus
the current PEM format follows the traditional communication protocol
paradigm of placing the headers at the beginning of the message.
Hold on -- there's a HUGE difference between the message headers, which most
software, be it MIME-and-or-PEM-capable or not, is capable of handling
sensibly, and stuff embedded inside a message, which most software treats as
straight text. I'm sorry, but this argument does not wash with any but the most
primitive of user agents.
4- Section 5 indicates a requirement for Content-Type headers,
butr makes no mention of the relationship to the existing PEM
Content-Domain header field. I've already seen some potential
confusion here, with folks transporting non-USASCII data in a PEM body
but carrying the Content-Domain as RFC822. The intent of
Content-Domain is to describe the character set and canonicalization
rules that a receiver must apply to a message. At a minimum we need
to reconcile these two fields.
I was never sufficiently comfortable with Content-Domain to get into this.
5- I'm concerned that the defintion of the Content-Privacy
header, although noted as a local matter and thus not required, is a
very strong statement about how to invoke PEM processing in a MIME UA.
Since no other approaches are offered, I fear that the NOTE in the
text is just a token attempt to claim that this is "not a part of the
standard." In the PEM specs we worked hard to define a protocol which
was ammenable to implementation as a stand alone filter or integrated
into a UA, without prejudicing local implementation options. I think
inclusion of a discussion of this header field undermines the intended
implementation independence.
I think any discussion that does not provide at least a diagram of some
approach to the problem undermines development far more. I don't have a problem
with strengthening the wording to whatever extent is necessary, but not having
some indication of how this can be done plus a discussion of the issues
involved would be EXTREMELY dangerous.
This is a SHOW-STOPPER issue for me. I'm fully aware of all the dangers of
using a header line for this purpose. However, the semantics of what's being
specified here are precisely those of a header line, and a failure to make this
inference will lead to one of two results: (1) Developers will not get the
point and will implement things that don't have all the relevant functionality
and (2) People will stumble onto the header line analogy on their own and will
do it incorrectly because the security issues were not obvious to them.
6- In section 5.1, step #2 describes what should be done if
Content-Transfer-Encoding headers are encountered in the course of
parsing, but does not explain why. Is there more context here than
the section is providing? This algorithm is taking place at some
point in the message sumbission processing, but just where in the
processing is not quite clear. Some amount of MIME processing has
been accomplished, otherwise there would not be MIME headers to parse.
But there is not an explicit statement of the context in which this
algorithm is being applied.
First of all, the message input to this a MIME message, with ALL relevant MIME
information available. The output of the process is also a MIME message with
the requested enhancements done. I've added a note explaining this.
Second, the reason for removing the encodings is that you want the integrity
check to match the content of the message and not the encoding. I've added a
note about this as well.
7- I think theat step #3 (do PEM) is a bit under described.
It says privacy enhancement is performed, but subsequent steps address
transformations which are described as part of PEM processing. It
seems to me that more detailed references to RFC 1421 are required, to
make explicit which processing steps from 1421 are performed at this
point and which ones are not performed because of later processing
steps described in this document.
I see what you're getting at but I'll need help on this -- I don't know what
specific references you're after. Let me know and I'll see about adding them.
8- In section 5.1, step #4, the Content-Transfer-Encoding
discussion could be clearer (and "insure" should be "ensure"). In PEM
there is a clear option for the user to select MIC-CLEAR vs. MIC-ONLY.
Here, it is not clear that such an option is intended to be user
accesible, despite the different service provided. The description
here sounds as if MIC-CLEAR functionality might become the default
(based on how one reads the warnings, recommendations, etc.). This
needs to be made less ambiguous.
Huh? I don't get this impression at all from reading this material. It flat-out
says that quoted-printable is strongly recommended in all cases; it is readable
enough and guards against all sorts of corruption problems that are otherwise
likely to occur.
I cannot help that quoted-printable blurs the distinction between mic-clear and
mic-only; it was designed for precisely this purpose. But I don't see anything
ambiguous about the wording here and I am therefore at a loss as to how to
change it.
As for "insure" versus "ensure", well, my Oxford English Dictionary tells me
"insure" is perfectly valid and actually a bit more precise in this context.
9- I think the message delivry processing described in section
6 really needs much more detail, paralleling that which should be in a
revised section 5 and making the appropriate references to RFC 1421.
Just saying "do it in reverse" is not very illuminating. I recall
considerable discussion at the last meeting about when signatures are
checked relative to the processing being performed, the ability to
store messages in a form which preserves signatures (for later
forwarding to a third party for independent verification, etc.). None
of this topics is explicitly addressed by this very, very brief
description of delivery processing.
Again, I'll need help in fleshing out exactly what references to add. This is
all good stuff, but it needs to be tightened up in a way that I'm not competent
to do.
10- Here too, in Section 6, the suggested header
"Content-Annotation" is clearly a local matter and strong objections
to its inclusion in a standard were raised at the last PEM WG meeting.
This issues parallels that raised above in item #5. Little motivation
is provided for this facility in the text. The inclusion of a
date-time value raises other concerns, namely that a user may somehow
be mislead into believing that a locally-applied time marker of this
sort has any security validity (e.g., relative to non-repudiation
services).
I feel less strongly about the Content-Annotation issue than I do about the
Content-Privacy issue. Nevertheless, I think by failing to provide adequate
guidance you're causing more problems than you solve.
If I recall from the last meeting, the argument was made that
this is a good alternative to requiring a user to revalidate a message
signature because of performance considerations. Recent personal
experinece with PEM message processing software using RSAREF (the
publically available crypto software provided by RSA) strongly
suggests that the performance costs associated with signature
validation for moderate size messages are very, very minimal. Thus
this rationale should be reviewed in light of recent experience.
I certainly never claimed that revalidating messages was the central issue
here. The plain fact of the matter is that there is a real need for a
notational means of indicating what sort of privacy enhancement was present and
if there's no discussion of what can be used and what the pitfalls associated
with such are people will make inappropriate choices and will implement things
badly. The issue of whether this can be used to cache decrypted material and
whether or not such caching is a performance win is entirely secondary, in my
opinion. (On my Alpha system here it is of little concern, believe me ;-)
11- Examples are very important to understanding this proposal
and I'm gald to see some included. However, none of these examples
include ENCRYPTED messages, or recursive use of the proposed
structures. It would really help to see less trivial worked examples,
with thorough annotations, to inspire confidence that the proposed
processing algorithms are consistent and comprehensive.
I'll add some just as soon as I have software in place capable of generating
them. I'm very close but not there yet...
12- I'm not sure that the observations belong in a separate
section in a standards track RFC. Some can be moved into the
introduction and others may be appropriate inline, as part of
providing rationale for the design. I observe that the inclusion of
Content-Domain already provides a hook for privacy-enhancing other
than just 822 messages, so the first observation, while true, is not a
unique feature added by the combination of MIME and PEM. Also, with
regard to observation #3, I think there may be a potential danger
lurking here. Separately processed contents that are not tied
together via PEM (e.g., not embedded in an enclosing MIC-ONLY content)
could be the result of some type of mix and match attack. If this is
not the case, then the reason should be explained somewhere.
I'll leave this for the WG to decide.
Ned