On Wed, 11 Nov 92 9:51:47 PST, henry strickland --
strick(_at_)osc(_dot_)com <osc!strick(_at_)amd(_dot_)com> said:
henry> You write:
henry> # Gateways may perform a variety of transformations on plain text
henry> # messages, such as character code translation, whitespace
henry> # removal/padding, etc. When a message passes through a gateway, the
henry> # gateway can perform any necessary transformations on the encrypted
henry> # representation of a message, but not on the the underlying plain text
henry> # message.
henry> I had thought that PEM messages are encoded in the same base64
henry> character set that MIME base64 bodies are encoded in, making them
henry> invulnerable to the transformations you describe.
Yes, they are invulnerable and that gives rise to a different sort of
problem:
When a mail message goes through a gateway between different types of
environments. For example, if an encrypted mail message goes from a
UNIX environment to an IBM mainframe environment the gateway will
change all of the characters in the base64 body from ASCII to EBCDIC
and pad out each line so that it fits into the fixed length 80
character records that the mail programs in that environment want to
see. Unfortunately, when the message is decrypted, it is still in
ASCII with ends of lined being indicated by CRLF rather than record
boundries. In that form it is unreadable in that environment. The
only way that I see to get around this difficulty is for the gateway
to add information to the mail header that tells the mail reader what
transformations it would have done to the message if it could have
done so. If that information were added as parameters something like
a
Content-Type: message/pem
line, then it would be possible for a mail reader program to do what
the gateway would have done (convert the message from ASCII to EBCDIC
and pad each line out to 80 characters) after the message has been
decrypted.