The content to be signed is the entire MIME entity containing the message
content, that is, from the first character of the MIME header (typically the "C"
in "Content-Type") up to, but not including, the CRLF just before the boundary.
Technically the boundary includes the CRLF that precedes the "--", and so the
CRLF is not included in the signed data. (This can get a bit tricky, since the
end of the header is denoted by two consecutive CRLF sequences, but the second
of these may be the start of the opening boundary.) The CRLF following the
previous boundary (just before the MIME header) is also not included. For
example:
Content-Type: multipart/signed;<CRLF>
protocol="application/pkcs7-signature";<CRLF>
micalg=sha1;<CRLF>
boundary="ABCD"<CRLF>
<CRLF>--ABCD<CRLF>
* Content-Type: text/plain;<CRLF>
* charset="ISO-8859-1"<CRLF>
* <CRLF>
* This is the signed content.
<CRLF>--ABCD<CRLF>
Content-Type: application/pkcs7-signature;<CRLF>
name="smime.p7s"<CRLF>
Content-Transfer-Encoding: base64<CRLF>
<CRLF>
MIIBD5hdkwmf5+er6jy=
<CRLF>--ABCD--<CRLF>
The signature data in this example is of course not valid, as (among other
things) it's too short.
The lines that have an asterisk (*) next to them are included in the signed
data. In this example, the last line of the signed content does not end with a
CRLF sequence; this is part of the boundary. Also, it's usually a good idea to
base64 encode the body text prior to clear signing it, as this preserves it from
distortion by some MTAs and gateways.
For an opaque signature, sign the same data, and wrap the resulting CMS
object in a application/pkcs7-mime MIME entity. In this case you wouldn't need
to transfer encode the body, since the CMS object that contains it will be
transfer encoded anyway.
Software I've written that signs MIME entities this way (and expects them to
be signed this way) interoperates well with Outlook, Netscape Messenger,
Groupwise, and (before its certificate expired) the Entrust autoresponder.
--------------------
Peter Tornberg wrote:
My questions are regarding multipart/signed. I have bumped into a problem
interpreting what the content to be signed is. In the RFC's it states how
to canonicalize, but I can't seem to find any information on what data to
sign (both signing a simple MIME entity, and signing a multipart MIME entity).
Signing a simple MIME entity:
Is all data including the last CRLF signed until reaching the boundary?
Or is the "middle" boundary included?
Signing s MIME multipart/* entity:
Is all data including the last CRLF signed until reaching the "middle"
boundary of the multipart signed message?
Or is the "middle" boundary included?
Or do we only sign data including the "end" boundary for the multipart
being signed?