Subject: multipart/signed interoperability

From: Peter Tornberg <[email-masked]>
Date: Mon, 09 Apr 2001 10:15:40 +0200

Hi,

I'm new to this list so bear with me if these questions have already been 
asked (and answered).

I'm looking to implement a semi-capable S/MIME client that only takes care 
of signing and not encrypting.

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?

Is there anywhere where the rules for what data to sign is stated clearly?

Still I don't seem to be the only one with this problem. I've run three 
different clients; Outlook Express 5.0, Netscape Messanger 4.72 and Openssl 
0.9.5a. Even these clients seem to have problems interpreting what data 
should be signed. OE and NM seem to agree on how to do things. Openssl can 
verify almost all messages from OE and NM but not all. OE has problems 
verifying messages from openssl.

I find openssl 0.9.5 on the RSA's list of interoperable S/MIME 
implementations??? I don't find any recent Microsoft or Netscape products 
on this list.

On the RSA site it points to the Entrust autoresponder for testing. This 
site does not seem to be up and running. Is there any other way to test 
that one follows the specification(s)?

Thanks!

/Peter

---

From: [email-masked]
Date: Mon, 9 Apr 2001 10:08:11 -0400

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:

---

From: "Pawling, John" <[email-masked]>
Date: Mon, 9 Apr 2001 11:57:02 -0400

Peter,

Please see RFC 2634, Section 1.2, for answers to some of your questions.

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================