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

Reply via email to