Hi Y'all,
I have a few of comments on the MIME-PEM spec.
First I would like to express sincere gratitude to the authors for
taking on this politically sticky task. This draft provides an
excellent basis for further discussion.
Next, a couple of comments in line with those recently posted by Steve
Kent:
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.
If the bodyparts in the multipart/pem Content were ordered as in
822-PEM (headers then enhanced data), a reader might be able to
process the pem headers and data in a single pass, i.e. not need to
rewind in order to process the data. This is because critical
information needed to process the data appears in the header (MIC
algorithm, encryption algorithm, encryption key, certificates, etc).
Perhaps this benefit outweighs the minor inconvenience to those
primitive non-MIME readers.
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.
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.
I was confused by these descriptions on my first reading of the spec.
also. I assume (please correct me) that this describes a model
whereby the MIME-aware agent and PEM-aware agent are distinct. Given
this assumption, it becomes more clear as to why it might be necessary
to define some local mechanisms for how the two might convey
information between them and eventually to the user. If this
assumption is correct, please make it very explicit.
I, for one, would prefer to believe that a single UA does both the
MIME interpretation and the PEM processing in which case, these
descriptions are confusing and potentially more harmful than good.
Perhaps the spec. can concentrate on the issues from a more general
prespective.
Last, a couple of new comments that came to mind:
The spec. does not address the following concepts. While they may not
be deemed necessary to architect in this version, I think they should
at least be mentioned.
- There is a large grey area concerning the content that can be
privacy-enhanced according to this spec. It seems at first reading
that any MIME bodypart can be enhanced via this mechanism. This leads
to the observation that there can be nested encodings as well as
recursive application of MIME and PEM structure. The only real
mention of the issue that I can find appears on Page 8, Section 8,
Item 2 "For a multipart or message content, it allows the user to
decide whether the structure of the content should receive
privacy-enhancement." Are all combinations legal ? Are some
disrecommeneded ? Does this cover the use of nested signatures ?
- The 822-PEM suite covers a number of message types to convey
information in addition to the MIC and ENCRYPTED types. These
includes certificate-signing requests, CRLs, and CRL-retrieval
requests. How do these get carried in a MIME message ?
- Is there interest in defining a multiple-header, single-message-body
multipart/pem type to convey parallel signatures ?
That's all for now. Look forward to lively discussion in the Buck-eye
state.
Cheers,
Steve Dusse
I don't have a .sig :-(