Rehash alert! Rehash alert!
Sorry for that !
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 ?
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 !
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.
I'll admit you found convincing arguments for not signing the decoded
message, since the archive is fairly big (I tried to find the arguments about
the protocol parameter, but retrieving all the compressed files is already such
a pain :-)
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 ?
Stefan