Configure patch for BSDI

[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 puts:

LIBS=libcrypto.so* libssl.so*

in the Makefile, and then in the install: target it tries to iterate on LIBS 
and apply ranlib to each library. But, ranlib is only for static libraries...

If to ommit 'shared' flag no shared libraries will be build :( Only with make 
shlib, but in this case library version will be 0.9.4 :() (for o.9.6 distri-
bution).

And, another annoing problem - (if 'shared' specified) - lib* are copied. But,
at least in case of linux-shared a bunch of symlinks are created to get short
names for the libraries. That symlinks are copied as well, but, as cp is used
for installation, resulting files are regular ones insted of symlinks, so, ld-
conf is unable to recreate symlinks :(

And the last question: why not to use autoconf to configure the package? As
it's already knows a lot about shared libraries suppport on different platforms,
platform-specific problems, functions, etc... It'll be really nice and convinient.
Are there any strong objections agains that idea? Or, it just "historical re-
asons" :)?

With best regards,
Timur Bakeyev.


--- Configure.orig  Sun Sep 24 17:27:37 2000
+++ Configure   Sun Jan  7 23:20:23 2001
@@ -304,7 +304,7 @@
 "FreeBSD-elf",  "gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486 
-Wall::(unknown)::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}",
 "FreeBSD",  "gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486 
-Wall::(unknown)::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_out_asm}",
 "bsdi-gcc", "gcc:-O3 -ffast-math -DL_ENDIAN -DPERL5 -m486::(unknown)::RSA_LLONG 
${x86_gcc_des} ${x86_gcc_opts}:${x86_bsdi_asm}",
-"bsdi-elf-gcc", "gcc:-DPERL5 -DL_ENDIAN -fomit-frame-pointer -O3 -m486 
-Wall::(unknown)::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}",
+"bsdi-elf-gcc", "gcc:-DPERL5 -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486 
+-Wall::-D_REENTRANT:-ldl:BN_LLONG ${x86_gcc_des} 
+${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-fPIC",
 "nextstep","cc:-O -Wall::(unknown)::BN_LLONG ${x86_gcc_des} 
${x86_gcc_opts}:::",
 "nextstep3.3", "cc:-O3 -Wall::(unknown)::BN_LLONG ${x86_gcc_des} 
${x86_gcc_opts}:::",
 # NCR MP-RAS UNIX ver 02.03.01


--- Configure.orig  Sun Sep 24 17:27:37 2000
+++ Configure   Sun Jan  7 23:20:23 2001
@@ -304,7 +304,7 @@
 "FreeBSD-elf",  "gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486 
-Wall::(unknown)::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}",
 "FreeBSD",  "gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486 
-Wall::(unknown)::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_out_asm}",
 "bsdi-gcc", "gcc:-O3 -ffast-math -DL_ENDIAN -DPERL5 -m486::(unknown)::RSA_LLONG 
${x86_gcc_des} ${x86_gcc_opts}:${x86_bsdi_asm}",
-"bsdi-elf-gcc", "gcc:-DPERL5 -DL_ENDIAN -fomit-frame-pointer -O3 -m486 
-Wall::(unknown)::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}",
+"bsdi-elf-gcc", "gcc:-DPERL5 -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486 
+-Wall::-D_REENTRANT:-ldl:BN_LLONG ${x86_gcc_des} 
+${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-fPIC",
 "nextstep","cc:-O -Wall::(unknown)::BN_LLONG ${x86_gcc_des} 
${x86_gcc_opts}:::",
 "nextstep3.3", "cc:-O3 -Wall::(unknown)::BN_LLONG ${x86_gcc_des} 
${x86_gcc_opts}:::",
 # NCR MP-RAS UNIX ver 02.03.01

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

[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 could as well configure my client software
drh> > with a key.pem that contains exactly this:
drh> > 
drh> >  -BEGIN PUBLIC KEY-
drh> >  ...
drh> > 
drh> >  -END PUBLIC KEY-
drh> > 
drh> > ... and it should be happy with that.  That's what RFC2560 really
drh> > implies.  One would just do it via certificates because it's more
drh> > comfortable that way...
drh> > 
drh> 
drh> There are also problems with just using public keys. You need some way
drh> to determine which public key signed the OCSP response. If the response
drh> doesn't include the signer's certificate and it is identified by the
drh> subject name (which is true in all the examples I've seen so far) then
drh> you can't do that with just the public key.

Of course not.  On the other hand, the OCSP servers I've seen being
set up with this mechanism always used byKey, never byName (IIRC).

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \  SWEDEN   \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

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

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

[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 detecting overflow.

http://www.openbsd.org/cgi-bin/man.cgi?query=strlcpy
http://www.openbsd.org/cgi-bin/man.cgi?query=strlcat

-d

-- 
| ``We've all heard that a million monkeys banging on | Damien Miller -
| a million typewriters will eventually reproduce the | <[EMAIL PROTECTED]>
| works of Shakespeare. Now, thanks to the Internet, / 
| we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org


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

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

[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".
> 
> Ah, that's what I wanted to know, thanks.
> 
> Oh wait, might that be what OCSP_NOVERIFY is for?
> 

That would still accept certificates in the reponse itself and would
thus consider any certificate as valid. Not a welcome prospect.

OCSP_NOVERIFY|OCSP_NOINTERN would only use and trust the supplied
certificates but you couldn't then accept other OCSP responder
certificates which passed the normal verify tests.

So whats needed is an option which means "if the signer's certificate is
any of these trust it, otherwise carry on as normal".

> drh> This is also needed to handle broken reponder certificates.
> 
> ?
> 

Alas some responder certificates break the rules. Some look like
delegated repsonders but don't have the right extensions or aren't
signed by the right CA. If experience is anything to go by it will be
necessary to provide a mechanism which can work around broken responder
certificates (by trusting them as a special case) rather than wait until
the reponder provider fixes their certificates.

> drh> I was talking about being able to automatically handle a trusted
> drh> reponder chain. You could have a situation where a root OCSP responder
> drh> CA has a long lifetime and the OCSP responder certificate has shorter
> drh> lifetime a year or less. With this scenario you can trust the OCSP
> drh> responder root and not have to reinstall the OCSP responder certificate
> drh> every time it expires. This doesn't happen for just any root CA in the
> drh> trusted store: it needs to have an explicit trust setting added to it.
> 
> That's an extension to RFC2560, isn't it?  I can't really find
> anything in there that views a Trusted Responder in that way.
> 

Well I'd argue that it doesn't say what criteria you have to apply to
trust a given public key and there's nothing that specifically prohibits
it. Also in RFC2560:

>- A CA may specify that an OCSP client can trust a responder for the
>lifetime of the responder's certificate. The CA does so by including
>the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical
>extension. The value of the extension should be NULL. CAs issuing
>such a certificate should realized that a compromise of the
>responder's key, is as serious as the compromise of a CA key used to
>sign CRLs, at least for the validity period of this certificate. CA's
>may choose to issue this type of certificate with a very short
>lifetime and renew it frequently.

If a responder certificate does have a very short lifetime and it isn't
delegated then it isn't practical to trust each as a special case.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

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

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

[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> >   specially marked certificate issued directly by the CA, indicating
> drh> >   that the responder may issue OCSP responses for that CA
> drh> >
> drh> > I'm talking about the "Trusted Responder", and what I want to be able
> drh> > to do is tell OpenSSL in my client is that one specific certificate
> drh> > given by me shalle be used to verify the signature.  This has nothing
> drh> > to do with chain verification, it's just about the verification of the
> drh> > response signature, since I've already told it what public key I
> drh> > trust.
> drh> >
> drh>
> 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".
> 
> :-) Actually, for the "Trusted Responder" case, one shouldn't even
> need to handle an OCSP signing certificate.  Read that line again, all
> it says is "pubkey".  It says absolutely nothing about certificates in
> that particular case.  I could as well configure my client software
> with a key.pem that contains exactly this:
> 
>  -BEGIN PUBLIC KEY-
>  ...
> 
>  -END PUBLIC KEY-
> 
> ... and it should be happy with that.  That's what RFC2560 really
> implies.  One would just do it via certificates because it's more
> comfortable that way...
> 

There are also problems with just using public keys. You need some way
to determine which public key signed the OCSP response. If the response
doesn't include the signer's certificate and it is identified by the
subject name (which is true in all the examples I've seen so far) then
you can't do that with just the public key.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.


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

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

[Richard Levitte - VMS Whacker]

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> >   specially marked certificate issued directly by the CA, indicating
drh> >   that the responder may issue OCSP responses for that CA
drh> > 
drh> > I'm talking about the "Trusted Responder", and what I want to be able
drh> > to do is tell OpenSSL in my client is that one specific certificate
drh> > given by me shalle be used to verify the signature.  This has nothing
drh> > to do with chain verification, it's just about the verification of the
drh> > response signature, since I've already told it what public key I
drh> > trust.
drh> > 
drh> 
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".

:-) Actually, for the "Trusted Responder" case, one shouldn't even
need to handle an OCSP signing certificate.  Read that line again, all
it says is "pubkey".  It says absolutely nothing about certificates in
that particular case.  I could as well configure my client software
with a key.pem that contains exactly this:

 -BEGIN PUBLIC KEY-
 ...

 -END PUBLIC KEY-

... and it should be happy with that.  That's what RFC2560 really
implies.  One would just do it via certificates because it's more
comfortable that way...

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \  SWEDEN   \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

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

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

[Oscar Jacobsson]

[EMAIL PROTECTED] wrote:
> 
> I think Oscar's a bit confused.

Quite possibly. :-)

>  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.)

I think it just boils down to different trust model concepts.

I read "a Trusted Responder whose public key is trusted by the
requester" as one that had been [cross-]certified into my Public Key
Infrastructure. The resulting certificate would then warrant
verification, as validation information could then be carried in-band.

I guess I'm simply more comfortable trusting certificates than public
keys.

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

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

[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.

Oh wait, might that be what OCSP_NOVERIFY is for?

drh> This is also needed to handle broken reponder certificates.

?

drh> I was talking about being able to automatically handle a trusted
drh> reponder chain. You could have a situation where a root OCSP responder
drh> CA has a long lifetime and the OCSP responder certificate has shorter
drh> lifetime a year or less. With this scenario you can trust the OCSP
drh> responder root and not have to reinstall the OCSP responder certificate
drh> every time it expires. This doesn't happen for just any root CA in the
drh> trusted store: it needs to have an explicit trust setting added to it.

That's an extension to RFC2560, isn't it?  I can't really find
anything in there that views a Trusted Responder in that way.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \  SWEDEN   \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

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

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

[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 the
> drh> "global responders" which give info about multiple CAs and have a
> drh> separate certificate chain.
> 
> Are we talking about the same thing?  In RFC2560 section 2.2, the
> following possible signers are listed:
> 

Partly :-)

>All definitive response messages SHALL be digitally signed. The key
>used to sign the response MUST belong to one of the following:
> 
>-- the CA who issued the certificate in question
>-- a Trusted Responder whose public key is trusted by the requester
>-- a CA Designated Responder (Authorized Responder) who holds a
>   specially marked certificate issued directly by the CA, indicating
>   that the responder may issue OCSP responses for that CA
> 
> I'm talking about the "Trusted Responder", and what I want to be able
> to do is tell OpenSSL in my client is that one specific certificate
> given by me shalle be used to verify the signature.  This has nothing
> to do with chain verification, it's just about the verification of the
> response signature, since I've already told it what public key I
> trust.
> 

Well that's something next on the list. You can pass in a list of "extra
certificates" in the verify function and some flags. One flag will be
"automatically trust these and don't try to verify them".

This is also needed to handle broken reponder certificates.

The ideal situation would be to be able to add trust settings to a
single end user (err end responder...) certificate in the trusted store
and have that work automatically. Unfortunately that would need a
complete rewrite of the verify code :-(

> 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.
> 
> What you seem to talk about is the "CA Designated Responder"
> certificate, which is a completely different story.
> 

Err no designated reponders are automatically handled and need no
special configuration.

I was talking about being able to automatically handle a trusted
reponder chain. You could have a situation where a root OCSP responder
CA has a long lifetime and the OCSP responder certificate has shorter
lifetime a year or less. With this scenario you can trust the OCSP
responder root and not have to reinstall the OCSP responder certificate
every time it expires. This doesn't happen for just any root CA in the
trusted store: it needs to have an explicit trust setting added to it.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

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

use kmem_alloc instead of malloc?

[tleyer]

Hi, 

I'm trying to substitute the use of malloc for 
OPENSSL_malloc and kmem_free for OPENSSL_free.

Unfortunately I'm not sure if I'm doing this the right way:

crypto/mem.c:

static void *(*malloc_locked_func)(size_t)  = kmem_alloc;
static void (*free_locked_func)(void *) = kmem_free;
static void *(*malloc_func)(size_t) = kmem_alloc;
/* realloc is defined beyond */
static void (*free_func)(void *)= kmem_free;

void kmem_realloc (void *blah, size_t size){
void *new_mem = kmem_alloc(size,  KM_NOSLEEP);
  memcpy (new_mem, blah, sizeof(blah));
  kmem_free(blah, size);
}

with these modifications I can compile the stuff, but 
when I start it (in a kernel module (bios extracted)) 
it crashes my box.

Any suggestions?

Thanks 

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

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

[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, IIRC, Valicert intended to set up a global responder (and
therefore will sign with an Authorized Responder certificate).  I've
no idea how far they've come today...

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \  SWEDEN   \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.

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

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

[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 my experiences,
Richard's use model is the most common method of OCSP deployments.
Stephen's comments about adding the CA to the trust list are a bit
worrisome.
/r$
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: cvs commit: openssl/apps apps.h

[Richard Levitte - VMS Whacker]

From: Lutz Jaenicke <[EMAIL PROTECTED]>

Lutz.Jaenicke> Is there any particular reason to not just call
Lutz.Jaenicke> SSL_library_init()? I vaguely remember a discussion
Lutz.Jaenicke> about shared library compatibility and
Lutz.Jaenicke> macros... SSL_library_init() is the symbol referenced
Lutz.Jaenicke> in the library.

As long as macros remain macros and functions remain functions, the
problem is NIL.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \  SWEDEN   \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.

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

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

[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
oscar.jacobsson> > any certificate that CA has produced.
oscar.jacobsson> 
oscar.jacobsson> Precisely, and that's why we have the key usage
oscar.jacobsson> extensions. You wouldn't necessarily want to trust
oscar.jacobsson> this certificate to sign anything but OCSP responses.

Hmm?  If I have specified for my little client that the certificate
foo.pem is trusted to verify OCSP response signatures against, why
should my client try to tell me otherwise.  I think you're mixing
things up, assuming you're talking about OCSPSigning, which is for "CA
Designated Responder" (also called "Authorized Responder").

oscar.jacobsson> > What you seem to talk about is the "CA Designated Responder"
oscar.jacobsson> > certificate, which is a completely different story.
oscar.jacobsson> 
oscar.jacobsson> I don't think so. The CA designated responder, IIRC,
oscar.jacobsson> is one where the responder gets his public key signed
oscar.jacobsson> by the CA in question (thus "designated") in order to
oscar.jacobsson> prove that he is trusted to respond to these queries.

Your memory seems to work perfectly on this particular item :-).

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \  SWEDEN   \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.

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

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

[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 wouldn't
necessarily want to trust this certificate to sign anything but OCSP
responses.

> What you seem to talk about is the "CA Designated Responder"
> certificate, which is a completely different story.

I don't think so. The CA designated responder, IIRC, is one where the
responder gets his public key signed by the CA in question (thus
"designated") in order to prove that he is trusted to respond to these
queries.

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

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

[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 about multiple CAs and have a
drh> separate certificate chain.

Are we talking about the same thing?  In RFC2560 section 2.2, the
following possible signers are listed:

   All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the requester
   -- a CA Designated Responder (Authorized Responder) who holds a
  specially marked certificate issued directly by the CA, indicating
  that the responder may issue OCSP responses for that CA

I'm talking about the "Trusted Responder", and what I want to be able
to do is tell OpenSSL in my client is that one specific certificate
given by me shalle be used to verify the signature.  This has nothing
to do with chain verification, it's just about the verification of the
response signature, since I've already told it what public key I
trust.

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.

What you seem to talk about is the "CA Designated Responder"
certificate, which is a completely different story.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \  SWEDEN   \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

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

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

[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 signer certificate
> steve>   + or the issuer of the OCSP signer certificate. In the latter case the
> steve>   + OCSP signer certificate must contain the OCSP signing extended key
> steve>   + usage. This check is performed by attempting to match the OCSP
> steve>   + signer or the OCSP signer CA to the issuerNameHash and issuerKeyHash
> steve>   + in the OCSP_CERTID structures of the response.
> steve>   + [Steve Henson]
> steve>   +
> 
> I don't recall, and don't have good access to the source right now:
> does verification also work with VA certs, that is, completely
> separate signer certificates that you configure on the client end as
> well as the server end?
> 

Yes, you need to add the CA to the trusted store and change the trust
setting of the root CA to support OCSPSigning then it will verify for
any issuer CA in the OCSP request. This is intended to support the
"global responders" which give info about multiple CAs and have a
separate certificate chain.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

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

Re: Peer certificate in SSL_SESSION structure.

[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
> > > in the resumed connections (in case it needs it), but from the ssl
> > > protocol point of view client certificate is not used any where
> > > other than establishing the new session..
> > 
> > No, it is not used in the handshake again (that's why it must be kept inside
> > the stored session).
> 
> IIRC the client certificate is _not_ stored in the session (at least, it
> used not to be - Apache-SSL has to work around this in its own caching).

At least in actual versions it is stored. I don't know whether this
feature is missing in older versions, but Postfix/TLS uses this feature
(disk based session caching) since September 1999.
Just checked the CVS archive, i2d_SSL_SESSION handles the peer since
1.1 (the initial OpenSSL check in dated Dec 21, 1998).

There was/is a bug with respect to the verify_result:
In older versions, the certificate was stored but is verified again, when
reused. Due to the default setting, verify_result became X509_V_OK in any
case for reused sessions...
* For the server side this bug was fixed in 0.9.5.
* For the client side this bug is still present in 0.9.6 but has been
  fixed in CVS and will hence be fixed in 0.9.7 (or 0.9.6a if/when released).

Best regards,
Lutz
-- 
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus   http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus  Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Peer certificate in SSL_SESSION structure.

[Ben Laurie]

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
> > in the resumed connections (in case it needs it), but from the ssl
> > protocol point of view client certificate is not used any where
> > other than establishing the new session..
> 
> No, it is not used in the handshake again (that's why it must be kept inside
> the stored session).

IIRC the client certificate is _not_ stored in the session (at least, it
used not to be - Apache-SSL has to work around this in its own caching).

Cheers,

Ben.

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

"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]

Re: Peer certificate in SSL_SESSION structure.

[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 client certificate is not used any where
> other than establishing the new session..

No, it is not used in the handshake again (that's why it must be kept inside
the stored session).

Best regards,
Lutz
-- 
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus   http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus  Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]