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).
Rehash alert! Rehash alert!
We've been over this many times, in tedious detail, on both this list and
several others, as well as during at least two working group meetings that I
attended (and possibly others I did not). I really don't want to go through all
this again, so let me try to put a stop to this by answering only the immediate
question at hand.
The reason 7bit is mandated for signed objects is that it is the only thing
that works over all existing transports. Sure there are some transports that
support 8bit and even binary MIME, but when you send a message you don't know
for sure what transports it is going to use. And even if you did you don't know
where some recipient is going to forward the message, and support of forwarding
was a requirement going into this work.
The reason that changing the encoding isn't allowed should be obvious -- in the
present scheme of things it causes the signature to change as well.
I realize this brings up all sorts of other questions, such as why not define a
signature methodology that is invariant under different encodings. If you want
to travel down this road, please do so by reading the list archives and the
Working Group minutes -- they should tell you why we didn't opt for this
approach.
Here is how I see canonicalization:
A transport can be 7bit-clean, 8bit-clean or binary-clean.
Or it can be an unpredictable combination of the three different services, and
when sending there is no way to tell what's available. This is reality, like it
or not.
- 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 !
Uh huh. This is exactly our reasoning. And since you *never* *ever* know that
the transport a message is going to take now or in the future is always going
to be 8bit or binary-clean, you always have to encode.
- 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).
Exactly right.
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)
All the specification needs to do is state that the material inside of a
security object must be a valid MIME object and must be canonicalized according
to MIME rules. MIME takes care of the rest of it for you.
Ned