In RFC1847 the following example is given on page 6:
Content-Type: multipart/signed; protocol="TYPE/STYPE";
micalg="MICALG"; boundary="Signed Boundary"
--Signed Boundary
Content-Type: text/plain; charset="us-ascii"
This is some text to be signed although it could be
any type of data, labeled accordingly, of course.
-- Signed Boundary
Content-Type: TYPE/STYPE
CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
--Signed Boundary--
My question is: is the text present in the "text/plain" bodypart
sent in the clear (i.e., not encrypted to the 2nd signature bodypart) ?
It is sent in the clear, of course. This is a signature service, not an
encryption service. The two are completely separate services. You can combine
them if you like so that the signed information content is encrypted or the
encryped content is signed, but in the first of these cases the content of the
multipart/signed would be multipart/encrypted rather than text/plain and in the
second case the multipart/signed content would be invisible inside of a
multipart/encrypted wrapper.
The different layering orders have different semantics that may or may not be
appropriate in a given application. Personally, I'm quite partial to putting
the multipart/encrypted on the outside since it hides the fact that a signature
is present from casual snooping.
If the above example is the entire message (assuming the standard
From and date (etc) headers are added), then surely the text in the first
body part should be encrypted to the signature information in the rest of the
message.
Nope. You are confusing two separate services, signature and encryption,
here.
If it was not encrypted to the rest of the message, then a simple attack
could void the "authentication" provided by the signature.
I don't know what you mean. If you mean that someone could change the message
in transit and thus render the signature invalid, the answer is that of course
someone could do this. In fact the entire point of having a signature service
is to detect such tampering if and when it occurs.
Encrypting the content doesn't make it any harder to change either -- you can
tamper with encrypted content every bit as easily as you can tamper with
unencrypted content. Its true that you may not be able to make as subtle a
change with encrypted content (casual changes will trash the content completely
in most cases), but its not an important distinction as far as I can see.
A rewrite attack would be to simply rewrite the ENTIRE message removing all
of the signature information and headers such as "multipart/signed".
This is absolutely possible, but so what? The recipient won't see the signature
they are expecting and will know that the message has been tampered with. The
recipient has to know that a signature should have been present in any case --
systems that rely on the presence of a signature to trigger any sort of
authentication processing are open to a variety of attacks. And this is true
even when the resulting material is hidden under an encryption -- see below.
You seem to imply that encrypting the entire message including the signature
will somehow prevent this sort of tampering. You are certainly free to layer
the services in this fashion (i.e. encrypt the signed content) any time you
want, but you should be very wary of the assumption that this will
unconditionally prevent people from removing the signature. It makes it harder,
perhaps even a lot harder, but it may not make it as hard as you might think.
Note that a signature encapsulation consists of some number of bytes in front
of the content plus a few after the content. The difficulty of removing the
requisite number of bytes from the beginning and end of an encrypted enclosure
varies substantially since it doesn't axiomatically involve actually cracking
the encryption. Its definitely made a lot harder when the underlying services
are properly designed and implemented -- use of chaining modes rather than
independent block modes is quite important in this context, for example.
However, plenty of examples do exist of security services that don't do these
things properly, and in modular systems its important that you not make
assumptions in this area.
Ned