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

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

There was a comment on the PKIX list a while back to the effect that the time
on the average peecee is usually out by anything from minutes to days (I've
never seen one that's that far out, but being off by a few hours seems fairly
common).  Because of this I wouldn't place too much reliance on timestamps
unless the client and server negotiate a common time, which OCSP doesn't do
because there's no provision for allowing the client to indicate what time it
thinks it is.  Given that (statistically speaking) the client will be a Windoze
box with a time which is more or less random, the use of absolute timestamps
doesn't add much, it would have been better to use nonces+relative times ("The
next update is 5 minutes from when you got this response", with an implied "If
this response took more than a minute or so to get to you, be suspicuous").

(Insert standard grumble about the fact that if you want to break a number of
 cert management protocols which carefully sign/MAC/whatever everything, all
 you need is a client running Windows or Unix without NTP or some equivalent,
 or the ability to spoof NTP et al if they are.  My code generally ignores
 timestamps because of all the problems I found with false rejections on
 systems with the time set wrong.  If anyone else has any feedback from the
 real world on this I'd be interested in hearing it).

Peter.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to