I think I have not heard an answer of the following message yet.
Please discuss this topic. And please let me know if I'm wrong.
--Kazu
--- Begin Message ---
I go down to the second question about draft-ietf-pem-mime-07.txt. (I
think it is hard but very much important.)
On page 9 and 10, it is explained that no canonical form conversion is
necessary for encryption and MIME/PEM encryption makes use of local
form as it is.
But think about the communication between a UNIX user and a Mac user.
Their line break is LF and CR respectively. When the UNIX user
encrypts, for example, "CT:text/plain; charset=us-ascii", UNIX local
line break LF is encrypted. If the Mac user receives it and decrypt
it, LF appears and can't treat it as a text. For this reason, it is
necessary for PEM/MIME encryption to convert local form to MIME
canonical form.
But here comes a question. Which CT: should we convert? I think
encryption is one sort of encoding. In this sense, we may be able to
refer to Base64 encoding. In RFC1521, it is clearly mentioned that
Base64 converts only text contnent type since rare LF or CR in a
binary data should not be convert. But PEM/MIME encryption allows to
encrypt "CT: message/*" and "CT: multipart/*" which MIME strongly
prohibit to encode.
If all content-body in "CT: message/*" and "CT: multipart/*" are
already encoded (by Base64 or Quoted-Printable), all lines are
teminated by line break. Thus we can convert all local line break of
"CT: message/*" and "CT: multipart/*" into CRLF. But MIME reserves
"CTE: binary". This means that in the future a content-body in "CT:
multipart" may be encoded with "CTE: binary"(i.e. no encode). That is,
a mulpart can contain binary content as it is. How can we convert
local line breaks to CRLF with such a multipart? How can we determine
which rare CR and LF should not to convert?
Maybe there is a way. But I'm not sure. Any comments?
--Kazu
--- End Message ---