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.
I know why it is "always" necessary. But why make it a requirement ?
Because things don't interoperate properly unless it is a requirement.
For that matter, why don't we register and allow MD2, MD4, SHA, Snefru,
RIPE-MD, and HAVAL for hash functions? Why don't we allow not one but
all of the various multi-pass DES variants and IDEA as private key
algorithms? And why don't we allow El-Gamal as an alternative to RSA?
We want things to interoperate. This means restricting ourselves to some subset
of the available solutions, even when that subset doesn't always offer the best
performance, use of available bandwidth, or whatever.
The forwarding argument is actually fairly good.
The main reason for not requiring 7bit is for cases where you encrypt right
after
signing. Of course, it can still break if you extract the signed part and try
to forward it !
Exactly.
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.
But you might not care whether the recipient will be able to forward the
message
or not. If you know that the transport is 8bit clean and you don't care about
what
the recipient might want to do, why should you first encode to 7bit ?
And how do you know the transport is 8bit clean? The route you take today may
be, but all it takes is a single DNS change to change the route to include a
7bit path. You just don't have this much control over the email infrastructure.
There are even cases you can get into where your message can't go forward
(7bit only) and can't go back (different path from the one it came in on that
doesn't support 8bit). Messages may be lost without a trace in such
situations.
This was all covered over and over and over and over again in the early
discussions of the ietf-smtp working group. That group eventually decided that
implementation of 8bit (and by extension binary) messaging services had to be
done in a way that didn't assume any particular sort of enhanced end-to-end
transport. As such, the approach taken required that any valid 8bit (or binary)
message had to be in a form that can be converted to 7bit if need be.
Ned