From: "Florian Oelmaier" <[EMAIL PROTECTED]> Subject: RE: cvs commit: openssl/ssl s3_lib.c ssl.h ssl_algs.cssl_ciph.cssl_locl.h tls1.h Date: Thu, 8 Feb 2001 18:00:04 +0100 Message-ID: <[EMAIL PROTECTED]> flo> > > Hmm, first of all, the responder (as I understood RFC 2560) should flo> > > always send back the exact same nonce. However, the client shouldn't flo> > > go crashing, it should give back an error code of some kind. flo> > > flo> > flo> > Yes I agree. I'll look into it. flo> flo> I read the RFC very carefully. There is no sentence like "if the client flo> sends a nonce-extension, the server SHALL reply to it". In fact point 4.4 flo> states: Unfortunately, RFC 2560 is extremely badly written for an RFC (IMHO), and there are many places where you have to sense the intention more than read the wordings very carefully. Now, tell me, if you look intelligently at it, how do you bind the request and the response to avoid replay attacks without requiring the exact same nonce to be returned? I ask you to think intelligently, not just to read the exact wording here. I had a discussion with other people last summer about the need to do double hashing in some places, simply because the RFC left that open for interpretation, or so it seemed. The best way to find out what is really intended, get in touch with the authors or with the ietf-pkix list. In any case, be polite, you'll be talking to some very knowledged people. flo> So any OCSP-responder not answering to OCSP-nonce is completly conforming flo> with RFC2560. Therefore, openssl should give a warning, not an error. Well, in that case, the whole nonce thing is completely useless, because if it's optional, you won't avoid replay attacks. flo> PS: The responder will go public this week. I´ll announce the flo> IP-address here. Cool. -- 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]
Re: cvs commit: openssl/ssl s3_lib.c ssl.hssl_algs.cssl_ciph.cssl_locl.h tls1.h
Richard Levitte - VMS Whacker Thu, 08 Feb 2001 09:18:29 -0800
