Florian Oelmaier wrote:
>
> > drh> Actually one public responder I've tried (which shall remain
> > nameless)
> > drh> throws out a thisUpdate field for one certificate >6months old and no
> > drh> nextUpdate field at all.
> >
> > Thus breaking the following, I assume (from section 2.4 in RFC 2560):
> >
> > If nextUpdate is not set, the responder is indicating that newer
> > revocation information is available all the time.
>
> We do the same, as we directly connect to the CA-database, but we set
> thisUpdate to the actual time as this seems to make more sense. It would be
> fine to have an option within OpenSSL that says: "Trust only responses with
> a thisUpdate not more than x minutes old". As the RFC for states for the
> field thisUpdate: "The time at which the status being indicated is known to
> be correct". Most security policies will include some requirements for
> OCSP-Clients regarding this point.
>
> I am not sure if it is the correct idea to put it into the library - thats
> up to you.
>
I've got some expiry checking functions that I haven't checked in yet. I
started with the simplistic version which checks if the current time is
between thisUpdate and nextUpdate. That got bitten by some responders
which set thisUpdate and nextUpdate to exactly the same time.
Instead I've gone for checking whether thisUpdate <= nextUpdate and that
they occur within a configurable interval of the current time.
I was going to add an additional parameter that specifies the maximum
age of thisUpdate if nextUpdate is absent.
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]
