> From: [email protected] On Behalf Of Dirk-Willem van Gulik
> Sent: Wednesday, 06 March, 2013 06:01
-dev added as a possible minor bug/enhancement, see end
> A simple
>
> echo foo | openssl smime -encrypt/sign | openssl smime
> -decrypt/verify
>
> works dandy. But was surprized to find that the verify breaks
> when '-binary' is used.
>
> Canonical example [snipped]
>
> Would like to understand why,
smime -sign defaults to -outform SMIME and no-nodetach, which
produces a multipart/signed aka "clear-signed" message.
Officially, the content of any SMIME message must be a MIME
entity with headers, and especially so for multipart/signed
since in that case it may need to be parsed by plain MIME
logic before getting to SMIME processing. OpenSSL doesn't
enforce this, although it does have option -text to add
minimal headers for text/plain, or check and remove such.
Also officially, as the man page says somewhat imprecisely,
SMIME content must be canonicalized, again especially so
for multipart/signed. "echo foo" on Unix does NL not CRLF,
and only CRLF is canonical for text in (S)MIME.
These requirements do not apply to PKCS7, which 'smime'
also supports with -out/inform PEM/DER. Even for SMIME,
non-text types can have different canonicalization rules,
which -binary apparently tries to handle, imperfectly.
But for multipart/signed, many "binary" types will need
transfer-encoding anyway, which OpenSSL doesn't handle.
Either SMIME or PKCS7 -sign -nodetach embeds the content
as-is with -binary and text-canonicalized without, and signs
the embedded version. -verify recognized embedded automatically
(does not need -nodetach), verifies the embedded version,
and outputs that even if -binary since we can't tell from
the message if/where sender canonicalization changed it.
SMIME -sign "detached" "attaches" content similarly as-is
with -binary and text-canonicalized without, and signs that.
SMIME -verify recognizes "detached", but (in multi_split)
always canonicalizes both parts before using them. For content
that was sent noncanonical (with -sign -binary or equivalent)
this changes the signed content, and verify fails.
Content that was canonical as sent (originally canonical
or canonicalized by sender) does verify and similarly
is output without determining if sender changed it.
PKCS7 -sign detached doesn't send the content at all;
you must do so, and provide it using -content on -verify,
and that content must be the canonicalized version if
-sign didn't specify -binary (which is rather fragile).
Also, looking at multi_split, I see confusing state that
may work poorly or wrong if (re)used for other multipart
types (specifically, with ~256 or more or 0 parts).
Per above I don't see any point in canonicalizing here:
content should have been canonicalized by the sender,
and if not then doing it here doesn't help (the message
has presumably already endured email) and may hurt;
signature pretty much has to be base64 and forcing
that base64 to CRLF (if not already) is useless.
I would suggest something more like:
BIO *bpart = NULL; *ret = sk_BIO_new_null();
while( (len=BIO_gets(bio,linebuf,max)) > 0 ){
state = mime_bound_check(linebuf,,,);
if( state==2 ) return 1; // end boundary
if( state==1 ){ // other boundary
bpart = BIO_new(BIO_s_mem());
BIO_set_mem_eof_return(bpart,0);
sk_BIO_push(*ret,bpart); // when "opened"
eol = 0;
}
else if(bpart){
#if canonicalize?
if(eol) BIO_write(bpart,"\r\n",);
eol = strip_eol(linebuf,&len/*decreased as needed*/);
if(len) BIO_write(bpart,linebuf,len);
#else
if(eol==2)BIO_write(,"\r\n",); else if(eol==1)BIO_write(,"\n",);
/*else nop*/
// or mildly tricky if(eol)BIO_write(,"\r\n"+2-eol, 2-eol));
eol = if linebuf ends with \r\n then 2
else if linebuf ends with only \n then 1 else 0;
// this could be a modified strip_eol() or just inline
if(len -= eol) BIO_write(,linebuf,len);
#endif
}
// else prologue data, discard
}
return 0; // EOF without proper end boundary
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
