pem-dev
[Top] [All Lists]

An Alternate Proposal (Was: MIME-PEM questions)

1993-04-23 07:36:00

Ned, 

The changes you have incorporated into the MIME/PEM document make sense
for some ordering of this efforts goals.  Below is a list of the goals
in the order I understand them and an alternate proposal.

The goals are:

1) Integration of PEM into MIME in such a way that a PEM my leverage
off existing MIME processing, i.e., such that PEM encapsulation
requires minimal additional processing.

2) A MIME implementation can read and process a PEM message to the
maximum degree possible.

3) MIME/PEM should work in the broadest possible range of transport
environments and across the greatest range of gateways (8 bit to 7 bit,
MIME to X.400)

4) Ease of implementation from the current PEM technology base

Goal #3, protecting the PEMed message from gateway transformation,
seems to be a problem because:

  1) Nested encoding are not permitted and therefore if the top level
  encoding needs to be changes, gateways must recurse through a message
  and change leaf nodes if the content-transfer-encoding must be
  changed.  Leaf noted may include MIME structuring information inside
  a protected body part.

  2) Gateways (including 8 bit to 7 bit MTA's) do not recognize
  multi-part/PEM as a special case will change the content-headings in
  an integrity checked structured content which will cause the MIC to fail.

  3) MIME does not offer a means of protecting a particular message
  content against gateway conversion (content-conversion-prohibited??)

The current proposal deals well with this problem by making integrity
checked message intentionally not readable by a non-PEM aware gateways
or MIME readers.  But by doing this, it throws out the more important
goal of MIME/PEM <=> MIME interworking!  If I send an Integrity checked
message to you, if you do not have a PEM aware implementation, you
can't read it!!

--------

If we in fact weight the ability for a Non-PEM reader to read integrity
checked mail over the ability to work transparently across deployed
gateways, (I do!!) then the following proposal may make more sense.

Proposal: 

  Require that the data portion of a multi-part PEM always be encoded
  into a 7 bit form.  As a 7 bit object it should not need to be
  transformed by most intermediate gateways.

Advantages:  

  The content-type of an Integrity checked message is available to a
  non-PEM aware MIME reader. (Big win!)

Disadvantages

  Gateways between MIME and X.400 will need to be PEM aware to do the
  right thing.

  There is no prohibition for against a MTA to muck with the encodings
  for any reason (i.e., upconvert to 8 bit) so there is a possibility
  the encoding may be changed even when not necessary.

I doubt any of the current MIME gateways suffer from these
disadvantages yet, and future ones can be designed (profiled?) to be
PEM aware.

Greg V.

<Prev in Thread] Current Thread [Next in Thread>