Re: Periodic certificate validation check

["Greg Carter" <greg@carter-engineering.com>]

Well ideally the CA would be using CRL distribution points and therefore you
would not have all the users under the same CRL.  So there would be multiple
CRLs each expiring at different times.   I can't speak for Verisign but I
would guess that the 10 days is for their free public CAs, I would assume
that their Enterprise offering has a configurable period (much less than 10
days).

Again you would not interrupt the current SA while negotiating the next.
Regardless of CRL/Certificates you would negotiate the next IKE SA at SA
Expiry Time - X, where X is random but constrained to an appropriate value
(I think this is talked about in the RFCs).  This way you wont have both
ends pulling down the connection and both attempting IKE negations at the
same time.

So if you use the above SA negotiation approach, along with a CA that
supports CRL distribution points, the overhead should not be a problem.  The
"potential" overhead would only occur when an SA is negotiated that would be
longer than a CRL validity period (or certificate).  CRLs are generally
valid for at least 4 hours.

I know that the Entrust CA supports CRL distribution points and CRL validity
periods configurable from 4-48 hours.

Greg.
----- Original Message -----
From: "Amey Gokhale" <agokhale@postmaster.co.uk>
To: "Greg Carter" <greg@carter-engineering.com>
Cc: <ipsec@lists.tislabs.com>
Sent: Tuesday, September 24, 2002 8:17 AM
Subject: Re: Periodic certificate validation check


> Keeping IKE SA lifetime just below CRL next update time could cause a lot
of overhead over a VPN gateway as phillip mentioned.
>
> The CRL update time of verisign is 10 days. what if any third party server
has frequent CRL updations? All IKE SA;s will be invalidated accordingly
causing IPSec SAs to break down. That will lead frequent SA negotiations
causing lot of overhead.
> In that case is there any standard approach to be followed?
>
> Regards,
> Amey Gokhale.