|
Posted by Brian Komar on August 7, 2006, 11:17 pm
Please log in for more thread options says...
> Paul,
> First let me say thankyou for taking the time to respond to my
> question.
>
> I think it would help if I added a little clarification. The term
> over-issued is something that I saw mentioned in some Entrust
> documentation a while back and I thought it was a "pretty neat way" of
> summing up issuing base CRLs before existing CRLs expire.
>
> The most important thing I omitted was to explain why we over-issue in
> our environment... I fully understand that over-issuing won't affect
> the freshness of the CRL which is cached by a DC. However,
> over-issuing is favourable in our environment as, for example, with a
> 7-day CRL which is over-issued daily we always have a scenario whereby
> if the CA "went bang" we'd have a total of six days to recover the CA
> before SC logon fell apart (we monitor the presence of a CRL with six
> days outstanding balance in AD (in this environment we don't publish to
> HTTP) and raise alert if that condition is not met). If we didn't
> over-issue and the CA went bang just before it's scheduled publication
> of a base CRL I guess we'd have problems. If there is a better way of
> avoiding big problems caused by a CA crash just prior to "scheduled"
> publication of a base CRL I'd be extremely interested to learn.
>
>
> The D-CRL issue I raised is more difficult to explain... though it
> would have been more helpful if I'd described the DC as retrieving a
> CRL (even if from itself) rather than receiving it, agreed.
> The problem I wanted to describe is the fact that over-issuing of the
> base CRL would "purge the D-CRL", and we could easily end up with a
> situation whereby a "SC cert" was revoked on day 1, purged from the
> D-CRL on day 2, then the user turns up on day 3 with his laptop at
> another location and logs on against a DC which never retrieved and
> cached the D-CRL upon which the bad cert was listed (perhaps the DC was
> down on day 1, or some other exists why it didn't cache the D-CRL).
>
> What I'm hoping for is for clarification about whether the D-CRL
> (published hourly) scenario as described is indeed a possibility or
> whether I have a complete misunderstanding of the workings of base
> CRLs, D-CRLs, cacheing, etc. I don't want to set the expectation that
> revocation status has "one hour freshness" whereas in actual fact there
> are situations which would fall outside of this.
>
> Regards, Dave
>
>
The big problem with your scenario is a misunderstanding on how a delta CRL is built. A delta
CRL contains all certificate revoked since the last publication of a *base* CRL. Your
continued publishing of base CRLs causes your problem, as each base CRL publication will wipe
out the contents of the delta CRL.
As Paul stated, this method just does not make sense when you combine base and delta CRLs. It
only makes sense in a case where you are not implementing delta CRLs.
I would look at methods of resigning an expired CRL if a CA fails and setting up a standard
base and delta CRL publication schedule. "Certutil -sign" is your friend.
Brian
| 
XML Sitemap