2. Suggestion to canonicalize text line breaks prior to encryption
Currently the specification requires the line break canonicalization
for the digital signature service but not for the encryption service.
It was pointed out that MIME should handle the necessary
canonicalization for encryption.
I've not found the strong reason to deny CTE: 8bit. Since it's line
based, the line break cononicalization is easy to apply for CTE: 8bit.
On the day of 8BITMIME, limiting to 7bit is not good idea.
Too true. Just like MIME doesn't force you to use 7bit encodings (you are
responsible for making sure the recipients get a correct message).
Here is how I see canonicalization:
A transport can be 7bit-clean, 8bit-clean or binary-clean.
- Signing should be done on a canonicalized message. That means use of CR/LF
for line ending in text parts. The encoding into 7bit shouldn't be specified
by multipart/signed. Of course, if you don't know that the transport will be
8bit clean or binary-clean, you'd better encode to 7bit. But if you don't,
that *your* (either the user or the writer of the UA) problem: the sig won't
check !
- Encryption hides the text from the MTAs, so that it can be considered as a
binary-clean transport (the encrypted message should of course be base64
encoded
if the mail transport is not binary-clean though). That means that the clear
message should be canonicalized to CR/LF (for text parts) but no other
encoding
is necessary (it won't hurt tho).
So, what I suggest is: multipart/security should enforce CR/LF canonicalization
of text parts before signing and/or encrypting, but nothing more (even though
it should mention that encoding to 7bit is advised for signing and useless for
encrypting)
Stefan
PS: the reason CR/LF is handled differently than 7bit encoding is probably that
the 7bit is only a problem of transport whereas the line ending of text is also
a problem at the UA level (the UA is assumed to be able to deal with binary).