Folks,
Below I have highlighted several points of the proposed
MIME-PEM design which I think merit discussion next week. This list
is intended to provide focus for the group discussion. The group will
decide if any of these issues are critical or if they can be ignored.
Also, I have received requests from a couple of parties to add
other items to our agenda. If the group wishes, we can limit the time
spent on the review of the MIME-PEM ID to make room for other topics.
I do think that the MIME-PEM ID deserves our greatest attention as it
is in ID form, has been available for several week prior to the
meeting, and thus is suitable for a thorough discussion. Any other
topics we discuss will just be introduced at this meeting, since they
lack written background that allows for thoughtful analysis prior to
the meeting and review by those who are unable to attend this meeting.
"MIME-PEM Interaction" Comments:
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.
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? Is this trying to say that a signed (but not encrypted) message
may be transferred without encoding, i.e., MIC-CLEAR? If so, can't
this be said more directly? 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? 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?
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?
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.