[no subject]

2002-10-14 Thread Maya



Hello!

I am using smime-tool for creating SMIME messages. I found and 
option which I can use to extract signer's certificate when verifying the 
message.
How I can extract encryption Certificates used to encrypt the 
message?

I found how to extract issuer_and_serial from PKCS7 structure, 
but I still cannot extract Certificates used to encrypt the 
message.
(PKCS7_RECIP_INFO *ri;) I tried to get the value of 
ri-cert, but unfortunately it didn't work.
Are encryption Certificates included in SMIME message, or just 
information about them is included - like issuer name and serial 
number)?

Maya



PKCS#7 problem

2002-10-14 Thread Jan Mikosiski

Hi
I try to implement simple message support in compatible with pkcs#7
standard.
I use OpenSSL ver 0.9.6g.  I encrypt data with PKCS7_encrypt and decrypt
with PKCS7_decrypt  functions and i've got a little problem.
The length of the data to be encrypted is 2951B . I encrypt this data  and
next decrypt it , but the length of decrypted data is 2962B.  The flags
parameter i n both functions I pass 0 (zero).
I dont know why do I get this length difrence. Does anybody have any
suggestion to resolve my problem ?

Regards
JM


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



[openssl.org #253] [bug] [patch] openssl 0.9.7-beta3 - vxworks compilation

2002-10-14 Thread Richard Levitte via RT


Applied.  Thanks!

[[EMAIL PROTECTED] - Thu Oct 10 00:13:19 2002]:

 Tried the CVS, and in order to make it compile ok and have no
 unresolved symbols, something like this patch is needed:
 
 (adds a missing RAND_poll, and removes RAND_query_egd_bytes, 
  since this is not invoked any more by empty RAND_poll)
 
 diff -u -r openssl/crypto/rand/rand_egd.c
 openssl_test/crypto/rand/rand_egd.c
 --- openssl/crypto/rand/rand_egd.cWed Oct  9 11:22:15 2002
 +++ openssl_test/crypto/rand/rand_egd.c   Wed Oct  9 13:15:55 
2002
 @@ -94,7 +94,7 @@
   *   RAND_egd() is a wrapper for RAND_egd_bytes() with 
numbytes=255.
   */
  
 -#if defined(OPENSSL_SYS_WIN32) || defined(OPENSSL_SYS_VMS) ||
 defined(OPENSSL_SYS_MSDOS)
 +#if defined(OPENSSL_SYS_WIN32) || defined(OPENSSL_SYS_VMS) ||
 defined(OPENSSL_SYS_MSDOS) || defined(OPENSSL_SYS_VXWORKS)
  int RAND_query_egd_bytes(const char *path, unsigned char *buf, 
int bytes)
   {
   return(-1);
 diff -u -r openssl/crypto/rand/rand_unix.c
 openssl_test/crypto/rand/rand_unix.c
 
 --- openssl/crypto/rand/rand_unix.c   Wed Oct  9 11:22:15 2002
 +++ openssl_test/crypto/rand/rand_unix.c  Wed Oct  9 13:32:37 
2002
 @@ -236,3 +236,10 @@
  }
  
  #endif
 +
 +#if defined(OPENSSL_SYS_VXWORKS)
 +int RAND_poll(void)
 +{
 +return 0;
 +}
 +#endif
 
 
 Cheers,
 Zoran Milojevic
 


-- 
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: OpenSSL PKCS#11 ENGINE

2002-10-14 Thread afchine madjlessi

Hi Fred,

  Frederic DONNAT [EMAIL PROTECTED] wrote:
  Hi,
  First of all, thanks for your answer.;)
  A few question about your PKCS#11 ENGINE.
  When you say that the stored private key can be load:
 - do you mean that one can get it from the store? 
 -or do you mean that one can use it through ENGINE method without having real 
 access to the private key? 

Our PKCS#11 engine uses the right way and secure way (that means the second one) , 
using the PKCS#11 api through the ENGINE method to access keys.

 I think the rigth way of using PKCS#11 is the second one (even if PKCS#11
 allows to store, generate, ... private key and get there attribute ...)

So, you're right, that' the good way!

 So, is your ENGINE able to get insert the a private key into the store and redirect 
 all computation using this private key directly on the store providing full security 
for 
 this private key? (without loading it from the store and retransmitting it to the 
store 
 in the correct function, in a few words as PKCS#11 standard specify it!)

That' the case of our PKCS#11 engine. 
Our engine allows openssl applications and apache-mod_ssl servers i.e to use through a 
PKCS#11 interface the security functions provided by cryptographic card.
RSA keys are inserted using PKCS#11 C_GenerateKeyPair standard function.
To be able to use the openssl commands allowing to generate and handle RSA
keys, the PKCS#11 engine introduces 4 additionnal entries in the RSA method:
rsa_generate_key, i2d_RSAPrivateKey,  d2i_RSAPrivateKey  d2i_RSAPublicKey.
Other RSA methods (rsa_pub_enc, rsa_pub_dec, rsa_priv_enc, rsa_pub_enc,
rsa_sign, rsa, rsa_verify) are available.
Temporary RSA keys are also created through the application (mod_ssl i.e.) by
calling the PKCS#11 engine. 

 Is your ENGINE able to redirect this computation on a smartcard using a PKCS# 11 
 interface for example?
 Regards 
 Fred

This PKCS#11 engine is tested on the Bull Trystway CC2000 PKCS#11 crypto card,
taking advantage of key storage in secure memory and acceleration of RSA and random 
functions on mutiple OS (Linux, W2K, NT). It also provides the ability to use remote 
calls 
through RPC to use a Crypto Box with a PKCS#11 trustway crypto card inside.

Cheers
Afchine

[EMAIL PROTECTED]
Bull - Trustway RD - Networking  Security
http://www.servers.bull.com/trustway




__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: your mail

2002-10-14 Thread Vadim Fedukovich

On Mon, Oct 14, 2002 at 04:14:17PM +0900, Maya wrote:
 Hello!
 
 I am using smime-tool for creating SMIME messages. I found and option which I can 
use to extract signer's certificate when verifying the message.
 How I can extract encryption Certificates used to encrypt the message?

PKCS7 Enveloped data type (used to send encrypted data) was designed
without recipient certificate; PKCS7 Signed data type do have
certificates and it is recommended to send signer' certificate there
as well as the whole certificates chain.
 
 I found how to extract issuer_and_serial from PKCS7 structure, but I still cannot 
extract Certificates used to encrypt the message.

To decrypt, private key is required anyway. Well, recipient certificate
might serve as index for pickup; issuer_and_serial would also do that.

 (PKCS7_RECIP_INFO *ri;) I tried to get the value of ri-cert, but unfortunately it 
didn't work.

ASN.1 parser (0.9.7) would not set ri-cert

 Are encryption Certificates included in SMIME message, or just information about 
them is included - like issuer name and serial number)?

Recipient certificate (public key used to encrypt) is definitely not included.

hope this helps,
Vadim
-- 
Naina library: http://www.unity.net/~vf/naina_r1.tgz
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: makedepend warnings

2002-10-14 Thread Richard Levitte - VMS Whacker

In message [EMAIL PROTECTED] on Wed, 9 Oct 2002 
18:30:14 -0400 , Zoran Milojevic [EMAIL PROTECTED] said:

Zoran.Milojevic makedepend: warning:  ../../include/openssl/asn1.h includes
Zoran.Milojevic ../../include/openssl/e_os2.h more than once!
Zoran.Milojevic makedepend: warning:  ../../include/openssl/x509.h includes
Zoran.Milojevic ../../include/openssl/evp.h more than once!
Zoran.Milojevic makedepend: warning:  ../include/openssl/asn1.h includes
Zoran.Milojevic ../include/openssl/e_os2.h more than once!
Zoran.Milojevic makedepend: warning:  ../include/openssl/ssl.h includes
Zoran.Milojevic ../include/openssl/bio.h more than once!
Zoran.Milojevic makedepend: warning:  ../include/openssl/ssl.h includes
Zoran.Milojevic ../include/openssl/x509.h more than once!
Zoran.Milojevic makedepend: warning:  ../include/openssl/x509.h includes
Zoran.Milojevic ../include/openssl/evp.h more than once!
Zoran.Milojevic makedepend: warning:  bss_bio.c includes ../../include/openssl/err.h 
more
Zoran.Milojevic than once!
Zoran.Milojevic makedepend: warning:  eng_openssl.c includes 
../../include/openssl/evp.h
Zoran.Milojevic more than once!
Zoran.Milojevic makedepend: warning:  err_prn.c includes 
../../include/openssl/crypto.h more
Zoran.Milojevic than once!
Zoran.Milojevic makedepend: warning:  passwd.c includes ../include/openssl/evp.h more 
than
Zoran.Milojevic once!
Zoran.Milojevic makedepend: warning:  pkcs8.c includes apps.h more than once!

It's not really a danger since all those headers are protected against
multiple inclusion.  However, I've made changes so makedepend won't
whine about it.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: possible bug in BN_dec2bn()

2002-10-14 Thread Richard Levitte - VMS Whacker

In message [EMAIL PROTECTED] on Sat, 12 Oct 2002 11:04:56 
-0700, David Brumley [EMAIL PROTECTED] said:

dbrumley  dbrumley The problem seems to be manifested in BN_dec2bn() because of
dbrumley  dbrumley the BN_mul_words and BN_add_words (e.g. line b).  Since the
dbrumley  dbrumley upper parts of d aren't cleared out, those routines end up
dbrumley  dbrumley adding to whatever junk happened to be left in d from the
dbrumley  dbrumley previous iteration.
dbrumley 
dbrumley  Perhaps there's a bug in those.
dbrumley 
dbrumley  Can you send us a small piece of code that actually shows the problem?
dbrumley  Please send us the result that you get, so we can compare.
dbrumley 
dbrumley The following program with the attached input file gives the
dbrumley problem.  The output doesn't match the input when ran (which
dbrumley it should).

Thanks, I found the bug.  It seems like BN_add_word() (and
BN_mul_word()) advances top without zeroing the next word.  The result
is that the value of that next word gets added to whatever is given as
the next word to add.  The simplest (and fastest, I believe) way to
handle that is to have those functions zero the next word if top
advances.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: possible bug in BN_dec2bn()

2002-10-14 Thread Richard Levitte - VMS Whacker

The final patch is the following (applicable on 0.9.6g and up):

Index: crypto/bn/bn_word.c
===
RCS file: /e/openssl/cvs/openssl/crypto/bn/bn_word.c,v
retrieving revision 1.6
diff -u -u -r1.6 bn_word.c
--- crypto/bn/bn_word.c 2000/09/04 15:30:14 1.6
+++ crypto/bn/bn_word.c 2002/10/14 11:32:55
@@ -123,7 +123,10 @@
i=0;
for (;;)
{
-   l=(a-d[i]+(BN_ULONG)w)BN_MASK2;
+   if (i = a-top)
+   l=w;
+   else
+   l=(a-d[i]+(BN_ULONG)w)BN_MASK2;
a-d[i]=l;
if (w  l)
w=1;

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



openssl pkcs8 encryptionbug

2002-10-14 Thread Michael Bell

Hi,

I received some messages that there are problems with the conversion 
from PKCS#8 to old SSLeay format and so I checked it. The result is the 
following:

1. the bug is only present if you convert a PKCS#8-key to the old format
2. set the option -passout (we use env:outpwd)
3. internally the following function is used in apps/pkcs8.c:
   PEM_write_bio_PrivateKey(out, pkey, NULL, NULL, 0, NULL, passout);

I searched the sources and find the following comment in 
crypto/pem/pem_pk8.c

--
As usual if 'enc' is NULL then it uses the unencrypted private key form.
--

'enc' is the third argument!

This looks like a disaster because pkcs8 has no options -des, -des, -aes 
etc. and there is no default. The result is an unencrypted private key 
without any warning. The passphrase is simply ignored.

Do I something wrong or is this a real security bug? If it is a bug then 
  I strongly recommend a bugfix before 0.9.7-release even if it requires 
some new options.

Best regards

Michael
-- 
---
Michael Bell   Email (private): [EMAIL PROTECTED]
Rechenzentrum - Datacenter Email:  [EMAIL PROTECTED]
Humboldt-University of Berlin  Tel.: +49 (0)30-2093 2482
Unter den Linden 6 Fax:  +49 (0)30-2093 2959
10099 Berlin
Germany   http://www.openca.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: possible bug in BN_dec2bn()

2002-10-14 Thread Bodo Moeller

On Mon, Oct 14, 2002 at 12:52:30PM +0200, Richard Levitte - VMS Whacker wrote:

 The problem seems to be manifested in BN_dec2bn() because of
 the BN_mul_words and BN_add_words (e.g. line b).  Since the
 upper parts of d aren't cleared out, those routines end up
 adding to whatever junk happened to be left in d from the
 previous iteration.

 Thanks, I found the bug.  It seems like BN_add_word() (and
 BN_mul_word()) advances top without zeroing the next word.  The result
 is that the value of that next word gets added to whatever is given as
 the next word to add.  The simplest (and fastest, I believe) way to
 handle that is to have those functions zero the next word if top
 advances.

Another theory is that any words in the array between 'top' and 'max'
are supposed to be zero -- there's much code with the sole purpose to
achieve this.  The problem is that this does not *always* happen
(otherwise this would not haven been a bug, and I believe there are
other cases); so maybe we can say that these words are zero for
aesthetical reasons, but technically are 'don't care'.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: openssl pkcs8 encryptionbug

2002-10-14 Thread Dr. Stephen Henson

On Mon, Oct 14, 2002, Michael Bell wrote:

 Hi,
 
 I received some messages that there are problems with the conversion 
 from PKCS#8 to old SSLeay format and so I checked it. The result is the 
 following:
 
 1. the bug is only present if you convert a PKCS#8-key to the old format
 2. set the option -passout (we use env:outpwd)
 3. internally the following function is used in apps/pkcs8.c:
PEM_write_bio_PrivateKey(out, pkey, NULL, NULL, 0, NULL, passout);
 
 I searched the sources and find the following comment in 
 crypto/pem/pem_pk8.c
 
 --
 As usual if 'enc' is NULL then it uses the unencrypted private key form.
 --
 
 'enc' is the third argument!
 
 This looks like a disaster because pkcs8 has no options -des, -des, -aes 
 etc. and there is no default. The result is an unencrypted private key 
 without any warning. The passphrase is simply ignored.
 
 Do I something wrong or is this a real security bug? If it is a bug then 
   I strongly recommend a bugfix before 0.9.7-release even if it requires 
 some new options.
 

If the PKCS#8 key is in PEM format it can be handled directly without any
conversion.

I agree some more options should be added and this behaviour documented.

Steve.
--
Dr. Stephen Henson  [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~steve/
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: PKCS#7 problem

2002-10-14 Thread Dr. Stephen Henson

On Mon, Oct 14, 2002, Jan Mikosiñski wrote:

 Hi
 I try to implement simple message support in compatible with pkcs#7
 standard.
 I use OpenSSL ver 0.9.6g.  I encrypt data with PKCS7_encrypt and decrypt
 with PKCS7_decrypt  functions and i've got a little problem.
 The length of the data to be encrypted is 2951B . I encrypt this data  and
 next decrypt it , but the length of decrypted data is 2962B.  The flags
 parameter i n both functions I pass 0 (zero).
 I dont know why do I get this length difrence. Does anybody have any
 suggestion to resolve my problem ?
 
This function is documented in newer 0.9.7 snapshots. It looks like you 
need the PKCS7_BINARY flag.
--
Dr. Stephen Henson  [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~steve/
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: possible bug in BN_dec2bn()

2002-10-14 Thread Ben Laurie

Bodo Moeller wrote:
 On Mon, Oct 14, 2002 at 12:52:30PM +0200, Richard Levitte - VMS Whacker wrote:
 
 
The problem seems to be manifested in BN_dec2bn() because of
the BN_mul_words and BN_add_words (e.g. line b).  Since the
upper parts of d aren't cleared out, those routines end up
adding to whatever junk happened to be left in d from the
previous iteration.

 
Thanks, I found the bug.  It seems like BN_add_word() (and
BN_mul_word()) advances top without zeroing the next word.  The result
is that the value of that next word gets added to whatever is given as
the next word to add.  The simplest (and fastest, I believe) way to
handle that is to have those functions zero the next word if top
advances.
 
 
 Another theory is that any words in the array between 'top' and 'max'
 are supposed to be zero -- there's much code with the sole purpose to
 achieve this.  The problem is that this does not *always* happen
 (otherwise this would not haven been a bug, and I believe there are
 other cases); so maybe we can say that these words are zero for
 aesthetical reasons, but technically are 'don't care'.

Hmmm ... wouldn't them being non-zero imply information leak?

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



[openssl.org #303] openssl-engine-0.9.6g bug in apps/rand.c

2002-10-14 Thread [EMAIL PROTECTED] via RT


Hello every body.
Thanks a lot for your nice job, meanwhile there a little bug in
'apps/rand.c'

Operating system: ALL
OpenSsl: 0.9.6g engine


The original code, from line 45
   while (!badopt  argv[++i] != NULL)
{
if (strcmp(argv[i], -out) == 0)
{
if ((argv[i+1] != NULL)  (outfile == NULL))
outfile = argv[++i];
else
badopt = 1;
}
if (strcmp(argv[i], -engine) == 0)
{
if ((argv[i+1] != NULL)  (engine == NULL))
engine = argv[++i];
else
badopt = 1;
}
else if (strcmp(argv[i], -rand) == 0)

The code as I think it should be
   while (!badopt  argv[++i] != NULL)
{
if (strcmp(argv[i], -out) == 0)
{
if ((argv[i+1] != NULL)  (outfile == NULL))
outfile = argv[++i];
else
badopt = 1;
}
else if (strcmp(argv[i], -engine) == 0)
{
if ((argv[i+1] != NULL)  (engine == NULL))
engine = argv[++i];
else
badopt = 1;
}
else if (strcmp(argv[i], -rand) == 0)


Without the 'else' condition in line 54, when we give a '-out outfile'
argument, we always get a 'badopt' error and the usage message.

 Thanks for integrating this correction in the next version.
  Jean-Etienne SCHWARTZ

mail: [EMAIL PROTECTED]


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



[openssl.org #303] openssl-engine-0.9.6g bug in apps/rand.c

2002-10-14 Thread Richard Levitte via RT


Thanks for the report.  It has recently been fixed as of another 
ticket, please test one of the snapshots.

I'm changing the status of this ticket to resolved.

[[EMAIL PROTECTED] - Mon Oct 14 21:48:49 2002]:

 Hello every body.
 Thanks a lot for your nice job, meanwhile there a little bug in
 'apps/rand.c'
 
 Operating system: ALL
 OpenSsl: 0.9.6g engine
 
 
 The original code, from line 45
while (!badopt  argv[++i] != NULL)
 {
 if (strcmp(argv[i], -out) == 0)
 {
 if ((argv[i+1] != NULL)  (outfile == 
NULL))
 outfile = argv[++i];
 else
 badopt = 1;
 }
 if (strcmp(argv[i], -engine) == 0)
 {
 if ((argv[i+1] != NULL)  (engine == 
NULL))
 engine = argv[++i];
 else
 badopt = 1;
 }
 else if (strcmp(argv[i], -rand) == 0)
 
 The code as I think it should be
while (!badopt  argv[++i] != NULL)
 {
 if (strcmp(argv[i], -out) == 0)
 {
 if ((argv[i+1] != NULL)  (outfile == 
NULL))
 outfile = argv[++i];
 else
 badopt = 1;
 }
 else if (strcmp(argv[i], -engine) == 0)
 {
 if ((argv[i+1] != NULL)  (engine == 
NULL))
 engine = argv[++i];
 else
 badopt = 1;
 }
 else if (strcmp(argv[i], -rand) == 0)
 
 
 Without the 'else' condition in line 54, when we give a '-out 
outfile'
 argument, we always get a 'badopt' error and the usage message.
 
  Thanks for integrating this correction in the next version.
   Jean-Etienne SCHWARTZ
 
 mail: [EMAIL PROTECTED]
 
 


-- 
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



X509_CRL_verify

2002-10-14 Thread Alon Philosoph



Hi,

I am using apache_1.3.24 with 
mod_ssl-2.8.8-1.3.24 and openssl-engine- 0.9.6g.

When I configure apache to work 
in SSL with client authentication and a crl that consist of 50,000 revoked certs 
I get very poor number 
of transactions per second.
when I looked at the code I 
have noticed that the function X509_CRL_verify takes a big amount of time to 
complete.

My question is 
:

Why do we need to check the crl 
signature for every client?

The client certificate was 
already checked to be valid and the crl validity was checked by the server 
administrator.
so what is the purpose of this 
function?

Thanks
Alon


Re: openssl pkcs8 encryptionbug

2002-10-14 Thread Michael Bell

Dr. Stephen Henson wrote:
 
 If the PKCS#8 key is in PEM format it can be handled directly without any
 conversion.

This is perhaps correct for the OpenSSL-commandlinetools (I don't know 
it) but I think mod_ssl is a problem and perhaps other applications 
which only use the old OpenSSL-format.

Michael
-- 
---
Michael Bell   Email (private): [EMAIL PROTECTED]
Rechenzentrum - Datacenter Email:  [EMAIL PROTECTED]
Humboldt-University of Berlin  Tel.: +49 (0)30-2093 2482
Unter den Linden 6 Fax:  +49 (0)30-2093 2959
10099 Berlin
Germany   http://www.openca.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: X509_CRL_verify

2002-10-14 Thread Richard Levitte - VMS Whacker

In message 45FCD7CD775DD411B4C100508B691BBB04B61F5D@WARE-MAIL on Tue, 15 Oct 2002 
07:53:14 +0200, Alon Philosoph [EMAIL PROTECTED] said:

AlonP I am using apache_1.3.24 with mod_ssl-2.8.8-1.3.24 and openssl-engine-
AlonP 0.9.6g.
AlonP  
AlonP When I configure apache to work in SSL with client
AlonP authentication and a crl that consist of 50,000 revoked certs I
AlonP get very poor number of transactions per second.
AlonP when I looked at the code I have noticed that the function
AlonP X509_CRL_verify takes a big amount of time to complete.

But it's not X509_CLR_verify that you're complaining about, it's
check_crl and the way things are handled in X509_verify_cert, right?

AlonP Why do we need to check the crl signature for every client?
AlonP  
AlonP The client certificate was already checked to be valid and the
AlonP crl validity was checked by the server administrator.

Where was the client certificate already checked, and compared to
where?

That the CRL validity was already checked by the admin is irrelevant.
The programs that use the CRL have the responsability to check that
things are consistent, so verifying the signature at all is a good
thing.

Perhaps we should ponder marking the certs and CRLs OpenSSL has in
memory with some bit saying they have already been verified.  The only
trouble I can see with that is that it would be extremely easy for a
malicious hack to tweak those bits, and therefore circumvent all
security, so such a change would need som hard thinking.

AlonP so what is the purpose of this function?

The purpose of X509_CRL_verify is to verify the signature of a given
CRL, no more, no less.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]