Re: OCSP nonce was: RE: cvs commit: openssl/ssl s3_lib.cssl.hssl_algs.cssl_ciph.cssl_locl.h tls1.h

[Richard Levitte - VMS Whacker]

From: "Florian Oelmaier" <[EMAIL PROTECTED]>

flo> No, they don´t. But it is not necessary to abuse the standard that much -
flo> simply think of caching OCSP-Responders, that cache the response of another
flo> OCSP-responder - they cannot send nonce, too.

I think something similar was recently discussed on ietf-pkix.  I
didn't quite following and really need to read up on that.  Keywords:
DPV and DPD...

flo> And signing the answer themselves may spoil the requirements of
flo> OCSP-Responder-Certificate delegation. A solution would be to
flo> double sign the request: the answerer including nonce and the
flo> generator giving the result. But this is not within the scope of
flo> RFC2560.

Actually, the way to solve this is to send the information about
certificates (CRLs, basically) to the "caching OCSP responders" and
let them produce responses themselves, signed with a proper delegated
cert/key.  Of course, that adds some complication in the whole
delegated certificate schema, but it does make the system a bit more
flexible and allows a better functionality visavi nonce.

I'm beginning to see a certain tendency toward getting around the
hassle of nonce handling because it fits a certain caching model
better, and frankly, it begins to look like a bad excuse to get
through with certain optimization because the letter of the RFC is
crappy in this particular subject.  Like bending the truth to your own
purposes.  I know, it's harsh words, but that's how I see it, and
unfortunately, it's oh so common...

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