From: Dr S N Henson <[EMAIL PROTECTED]>

drh> That got bitten by some responders which set thisUpdate and
drh> nextUpdate to exactly the same time. 

I'm not gonna look if that is allowed by the RFC.  The paranoid would
probably reject such a response, since it's basically invalidating
itself immediately (presuming that when you've gone past nextUpdate,
the response you have is not valid any more, and you should go get
another one).

[rant: a well-written RFC should not leave so many things open for
interpretation.  That's why I think RFC 2560 is badly written]

drh> Instead I've gone for checking whether thisUpdate <= nextUpdate
drh> and that they occur within a configurable interval of the current
drh> time.

Hmm, I was under the impression that any verification involving time
basically requires that the computer has actual correct time.
Therefore "within a configurable interval" is a moot point.  But if
you get responses where thisUpdate == nextUpdate, I can understand
this.  Personally, I think such responses should be rejected.

drh> I was going to add an additional parameter that specifies the
drh> maximum age of thisUpdate if nextUpdate is absent.

That's a good idea.

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