Hello Roumen,

On Sunday, October 22, 2006 at 14:20:49 +0200, Roumen Petrov via RT wrote:

> Proposed patches:
> a.) apps-smime.patch : proper eol for To,From and Subject headers in
> case of -crlfeol command line option.

Very good, thank you. Only the smime.p7s base64 lines remain ending
in LF with -crlfeol.

> b.) crypto-pkcs7-pk7_mime.patch :
> - add header in case of binary procesing

I'm not familiar with the -binary option, but generating a fixed
"Content-Type: application/octet-stream" header would disallow insertion
of user's own custom headers.

> - add empty line (mandatory) if procesing type is not specified (case
> without -text and without -binary)

Unfortunately this seems a bad idea. Without -text nor -binary, we
sign (or encrypt) a MIME entity, and the user must provide us the
mini-header. If we insert an empty line there, it breaks this

Example: I want to sign a Latin-1 text with accented letters.
OpenSSL -text option doesn't support charsets at all, outside of the
default us-ascii. So I must prepare myself the appropriate header
together with the said accented text properly encoded:

| Content-Type: text/plain; charset=iso-8859-1
| Content-Transfer-Encoding: quoted-printable
| Un texte accentu=E9.

I must give those 4 lines to OpenSSL's input, and use no -text
option (nor -binary option, otherwise I'd have to do the CRLF
canonicalization myself). Today, the result is OK "Un texte accentué.".
With your patch, the result is a 7bit Ascii text showing those 4 raw

Bye! Bruno.
/* Bruno Kozlowski */

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org