----- Original Message -----
From: "Dr. Stephen Henson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 06, 2002 8:23 PM
Subject: Re: PKCS7 detached signatures no longer detached in 0.9.6e


> On Thu, Sep 05, 2002, Chris Jarshant wrote:
>
> >
> > > > Which shows the "-nd" flag (and corresponding
> > > > API, PKCS7_set_detached()) has no effect.  Anyone
> > > > know why?  Is this a permanent change?
> > >
> > > The preferred method for using PKCS#7 is the high level API or the
smime
> > > utility, the 'sign' utility is rather old and clunky.
> > >
> > > I'll check to see if this happens with the smime utility.
> > >
> > > Steve.
> >
> > Steve,
> >
> > Thanks a bunch for the tip.  I was just using the "sign" utility
> > to illustrate the ineffectiveness of the PKCS7_set_detached()
> > API in recent versions of the toolkit.
> >
>
> There is a bug but its AFAICS 0.9.7+ only, 0.9.6g seemed to
> work. I'll fix it shortly..
>

Correct, I was mistaken, it was introduced in 0.9.7.
The version I have is beta2.  0.9.6e works, as does
g (which you pointed out).

> > Which High-level APIs were you referring to?  If you are
> > referring to the PKCS7_sign() API, I looked into using it,
> > but the problem is that the data I want to sign is only available
> > from running a series of commands in a row.  the PKCS7_sign()
> > API only takes one BIO.  Perhaps I should investigate writing
> > my own BIO type that can take an array of shell commands,
> > and produces the output from the shell commands when
> > you read from the BIO?  for example:
> >
> > BIO b = new my_bio();
> > b.addCommand("/usr/bin/echo foo");
> > b.addCommand("/usr/bin/echo bar");
> > char *result = b.BIO_read(...);
> >
> > and result would be "foobar".
> >
>
> If the data isn't too large then a memory BIO may do the
> trick: see BIO_s_mem manual page.
>

Well, this is an application for a wide range of customers,
so I want to make sure it can handle even very large
data to be signed, so I do not want to burden the program
with large memory or disk requirements.  Typically the
data size is less than 100mb, but not always.  Of course
I could write out the data to a single file then re-read it,
but that's a) inefficient, and b) problematic when the
data is large.  So is it really difficult to write my own BIO
given that I don't have the compilation environment
that openssl developers do?

> > If I did this, could I then pass it to
> > PKCS7_sign()?  Is it possible for 3rd-party developers such
> > as myself to write my own BIO, without doing so in the
> > openssl environment that openssl API developers have?
> > The other drawback was that I saw a lot of "smime"-looking
> > things going on in PKCS7_sign(), which is of no use to
> > me, and worries me that it might interfere with what my
> > application is doing.  I don't want or need PCKS7-signed
> > objects floating around with smime-looking attributes.
> >
>
> You can get rid of many of the S/MIME related attributes
> by passing the relevant flags to PKCS7_sign (see the
> smime manual page and smime.c source code).
>

I'll check into it.  It just makes me uneasy when my
program, which has nothing to do with s/mime, has
s/mime-looking code in it, even if it is code that is
"turning off" s/mime characteristics...guess that's
what I get for not writing it myself ;-)

> > Currently I am using something like this:
> >
> > PKCS7_content_new(p7, ...);
> > p7bio = PKCS7_dataInit(...);
> > PKCS7_set_detached(p7);
> > while ((data = get_some_data()) != NULL) {
> >     BIO_write(p7bio, data);
> > }
> > PKCS7_dataFinal(p7, p7bio);
> > fp = resulting_signature_file();
> > PEM_write_PKCS7(fp, p7);
> >
> > Is there a better way?
> >
>
> If the data will fit in a memory BIO then PKCS7_sign
> should be OK. If it is too large then currently you
> may have to use the low level API.

No, it won't do I don't think, so I'll stick
with the low-level APIs for the moment.  If you could
"fix" PKCS7_sign() to be able to handle data that
is coming in from one or more BIOs that would be
great, and would allow me to rely on higher-level
APIs (which is always a good idea).

chris


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to