Subject: Re: Scale (and the SRV record)

From: Andreas Berger <[email-masked]>
Date: Mon, 02 Nov 1998 15:53:37 +0100

[email-masked] wrote:
> 
> >If someone spoofed DNS the worst that would happen is that I would
> >recieve a certificate I didn't trust (and would ignore) or no >certificate
> at all.
> 
> Well, if you're only fetching certificates, probably.
> 
> But if you're fetching CRL's, then no.  Suppose a cert is compromised,
> and CRLn is issued before the "next update" time purely because of
> that compromise.  The adversary could spoof DNS and just send out
> the valid, but outdated CRL(n-1) and potentially have quite a
> window of opportunity.
That is if you assume that a CA is allowed to have several CRLs valid at
a given point in time.

Andreas
--
Fifty-three percent of Fortune 1000 executives think the
Arch Deluxe is something that helps to run a computer.
-- Jericho Communications

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 02 Nov 1998 10:58:59 -0500

>> the valid, but outdated CRL(n-1) and potentially have quite a

From what I've been reading here and elsewhere, it appears that many people
wish to require that relying parties always use the most up-to-date CRL when
performing a validation. I think this is a bad idea.

In general, a CRL provides the revocation status of a large number of
certificates
and is designed to be cached. If a relying party must check with a repository
for the freshest available revocation information each time it performs a
validation,
then a scheme, such as OCSP, which only provides the revocation status of
the certificate to be validated makes more sense.

If CRLs are to be used, then the CA must allow for validations to be performed
based on "old" revocation information. If the CA wishes to insure that
validations
are never performed using revocation information that is more than 4 hours old
then it should issue CRLs AT LEAST once every 4 hours with each CRL having
a nextUpdate field set to 4 hours after the time of issuance. The CA must then
accept that some relying parties will base validations on CRLs that may
have been
replaced by fresher CRLs, even when the new CRLs were issued as a result of
a compromise.

>That is if you assume that a CA is allowed to have several CRLs valid at

I most definitely want to allow a CA to have several CRLs valid at the same
time, but not for security reasons. I have been doing some work recently on
modeling the distribution of revocation information. The goal of the work
is to
determine, for any given situation, the best way to distribute revocation
information in order to minimize the peak load on the repository.

Suppose that a CA wishes to insure that relying parties always validate based
on revocation information that is at most 4 hours old. One option would be to
issue one CRL every 4 hours. However, if instead the CA issues one CRL every
hour, but still makes each CRL valid for 4 hours, the peak request rate to
the repository from relying parties will be lower. In general, the more
often new
CRLs are issued the lower the peak request rate. But, this reduction only
happens
if relying parties cache and continue to use the CRLs they download until the
time specified in nextUpdate is reached, not if they download a new CRL each
time a new one is issued.

David Cooper