Re: cvs commit: openssl/ssl s3_lib.c ssl.h ssl_algs.cssl_ciph.cssl_locl.h tls1.h

[Richard Levitte - VMS Whacker]

From: "Florian Oelmaier" <[EMAIL PROTECTED]>
Subject: RE: cvs commit: openssl/ssl s3_lib.c ssl.h ssl_algs.c ssl_ciph.cssl_locl.h 
tls1.h
Date: Thu, 8 Feb 2001 16:43:31 +0100
Message-ID: <[EMAIL PROTECTED]>

flo> I did some test with the OCSP-client code of the newest OpenSSL Developer
flo> Snapshot right now, and found a few issues.
flo> 

flo> 1) OCSP-Client code gives a segmantation fault, if the request was sent with
flo> OCSP-nonce, but the response did not contain an OCSP-nonce. As far as I
flo> understood RFC2560 this may be a possible scenario.

Hmm, first of all, the responder (as I understood RFC 2560) should
always send back the exact same nonce.  However, the client shouldn't
go crashing, it should give back an error code of some kind.

To quote the correct section:

  4.4.1  Nonce

     The nonce cryptographically binds a request and a response to prevent
     replay attacks. The nonce is included as one of the requestExtensions
     in requests, while in responses it would be included as one of the
     responseExtensions. In both the request and the response, the nonce
     will be identified by the object identifier id-pkix-ocsp-nonce, while
     the extnValue is the value of the nonce.

     id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

The only way I can see the request and response being bound together
is to require the responder to place the exact same nonce in the
response.  Therefore, if the client sent a request with a nonce and
the server sends back a response with a different or missing nonce,
the response should be regarded as invalid.

flo> 2) Given an OCSP-Responder, that does not append its own
flo> certificate (in the delegated case): I could not give an
flo> OCSP-Certificate to trust using the command line that helped me
flo> verify the response. You should be aware that there are use cases
flo> that do not append any certificate to the response. I am not
flo> really sure if this is a bug of apps/ocsp.c, libcrypto or my
flo> fault?

Stephen recently added code in crypto/ocsp to allow that kind of
verification, so I'd guess the fault is in apps/ocsp.c.

Is the OCSP server you're testing against public?  In that case, it'd
be nice if you could share the URL and possibly a test cert for us to
play with.

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