Re: Peer certificate in SSL_SESSION structure.

2001-01-23 Thread Lutz Jaenicke
On Mon, Jan 22, 2001 at 04:41:41PM -0800, Nagaraj Bagepalli wrote: Thanks for your response. If I understand this correctly, certificate is stored in the session table so that application can retrieve it in the resumed connections (in case it needs it), but from the ssl protocol point of view

Re: Peer certificate in SSL_SESSION structure.

2001-01-23 Thread Lutz Jaenicke
On Tue, Jan 23, 2001 at 10:51:27AM +, Ben Laurie wrote: Lutz Jaenicke wrote: On Mon, Jan 22, 2001 at 04:41:41PM -0800, Nagaraj Bagepalli wrote: Thanks for your response. If I understand this correctly, certificate is stored in the session table so that application can retrieve it

Re: cvs commit: openssl/crypto/ocsp ocsp.h ocsp_err.c ocsp_vfy.c

2001-01-23 Thread Dr S N Henson
Richard Levitte - VMS Whacker wrote: From: [EMAIL PROTECTED] steve + *) Add additional OCSP certificate checks. These are those specified steve + in RFC2560. This consists of two separate checks: the CA of the steve + certificate being checked must either be the OCSP

Re: cvs commit: openssl/crypto/ocsp ocsp.h ocsp_err.c ocsp_vfy.c

2001-01-23 Thread Richard Levitte - VMS Whacker
From: Dr S N Henson [EMAIL PROTECTED] drh Yes, you need to add the CA to the trusted store and change the trust drh setting of the root CA to support OCSPSigning then it will verify for drh any issuer CA in the OCSP request. This is intended to support the drh "global responders" which give info

Re: cvs commit: openssl/crypto/ocsp ocsp.h ocsp_err.c ocsp_vfy.c

2001-01-23 Thread Oscar Jacobsson
Richard Levitte - VMS Whacker wrote: I definitely do *not* want to have to tell OpenSSL that I trust the CA of my "Trusted Responder" certificate, because that might imply that I trust any certificate that CA has produced. Precisely, and that's why we have the key usage extensions. You

Re: cvs commit: openssl/crypto/ocsp ocsp.h ocsp_err.c ocsp_vfy.c

2001-01-23 Thread Richard Levitte - VMS Whacker
From: Oscar Jacobsson [EMAIL PROTECTED] oscar.jacobsson Richard Levitte - VMS Whacker wrote: oscar.jacobsson I definitely do *not* want to have to tell OpenSSL oscar.jacobsson that I trust the CA of my "Trusted Responder" oscar.jacobsson certificate, because that might imply that I trust

Re: cvs commit: openssl/crypto/ocsp ocsp.h ocsp_err.c ocsp_vfy.c

2001-01-23 Thread rsalz
I think Oscar's a bit confused. Richard wants to say This is the cert of the OCSP responder I trust and that *is all* he wants to say. He does not want/need to verify the chain of certs from the responder. (It could be self-signed, it could be he has out of band information, etc.) In

Re: cvs commit: openssl/crypto/ocsp ocsp.h ocsp_err.c ocsp_vfy.c

2001-01-23 Thread Richard Levitte - VMS Whacker
From: [EMAIL PROTECTED] rsalz In my experiences, Richard's use model is the most common rsalz method of OCSP deployments. Uhmmm, it is definitely so for many intra-things (intranets and similar stuff). CA's probably use the CA certificate to sign, or their own Authorized Responder. Also,

Re: cvs commit: openssl/crypto/ocsp ocsp.h ocsp_err.c ocsp_vfy.c

2001-01-23 Thread Dr S N Henson
Richard Levitte - VMS Whacker wrote: From: Dr S N Henson [EMAIL PROTECTED] drh Yes, you need to add the CA to the trusted store and change the trust drh setting of the root CA to support OCSPSigning then it will verify for drh any issuer CA in the OCSP request. This is intended to support

Re: cvs commit: openssl/crypto/ocsp ocsp.h ocsp_err.c ocsp_vfy.c

2001-01-23 Thread Richard Levitte - VMS Whacker
From: Dr S N Henson [EMAIL PROTECTED] drh Well that's something next on the list. You can pass in a list of "extra drh certificates" in the verify function and some flags. One flag will be drh "automatically trust these and don't try to verify them". Ah, that's what I wanted to know, thanks.

Re: cvs commit: openssl/crypto/ocsp ocsp.h ocsp_err.c ocsp_vfy.c

2001-01-23 Thread Dr S N Henson
Richard Levitte - VMS Whacker wrote: From: Dr S N Henson [EMAIL PROTECTED] drh -- the CA who issued the certificate in question drh -- a Trusted Responder whose public key is trusted by the requester drh -- a CA Designated Responder (Authorized Responder) who holds a drh

Re: cvs commit: openssl/crypto/ocsp ocsp.h ocsp_err.c ocsp_vfy.c

2001-01-23 Thread Dr S N Henson
Richard Levitte - VMS Whacker wrote: From: Dr S N Henson [EMAIL PROTECTED] drh Well that's something next on the list. You can pass in a list of "extra drh certificates" in the verify function and some flags. One flag will be drh "automatically trust these and don't try to verify them".

Re: [STATUS] OpenSSL (Sun 21-Jan-2001)

2001-01-23 Thread Damien Miller
On Sun, 21 Jan 2001, OpenSSL Project wrote: o Whenever strncpy is used, make sure the resulting string is NULL-terminated or an error is reported You should look at copying OpenBSD's strlcpy and strlcat routines, which provide a much safer way of copying nul-terminated strings and

Re: cvs commit: openssl/crypto/ocsp ocsp.h ocsp_err.c ocsp_vfy.c

2001-01-23 Thread Richard Levitte - VMS Whacker
From: Dr S N Henson [EMAIL PROTECTED] drh :-) Actually, for the "Trusted Responder" case, one shouldn't even drh need to handle an OCSP signing certificate. Read that line again, all drh it says is "pubkey". It says absolutely nothing about certificates in drh that particular case. I

Configure patch for BSDI

2001-01-23 Thread Timur I. Bakeyev
Hi, hackers! I've tried to compile OpenSSL under BSDI 4.1, which is bsdi-elf, with shared libraries, but Configure doesn't know how to do that on that platform. So, below is a patch that contains proper settings. One bad thing with Configure, that if to specify shared in the command line, it