Subject: RE: CRL size

From: sankar ramamoorthi <[email-masked]>
Date: Wed, 13 Jan 1999 18:38:00 -0800 (PST)

Actually I am looking at this problem purely from the
thin client's (in my a case a network appliance) point
of view.

I agree that the problem of multiple CA domains and
high revocation rate needs to be solved, but I am pushing this problem
to an external server, which I believe is the right place to address
these issues.
The external server may be running some complex protocols to ensure
the CRLs from multiple CAs are
refreshed periodically.

My company sells a network appliance which may be plugged into a
customer environment which may
have its own needs as for as checking the frequency of
revocation info etc.

My need is for the network appliance is to use certificates for
authentication purposes and be able to use CRLs to ensure the
certificates are not
revoked, but not worry about the growing size of the
CRL or revocation rate etc.

-- sankar --

---Alan Lloyd <[email-masked]> wrote:
>
> Sankar - there are many system and operational assumptions based or
your
> request/requirements. 
> ie if the system has a small number of locally contained users, the CA
> DB and the CRLs can live in a single DB and then its just over to
> estimating the reasons and frequency of revocation and putting in the
> CRL fragment algorithm processing in the client and the CA that
matches
> your needs.
> 
> If your system needs to scale and deal with multi CA domains with high
> revocation rates across many DBs or interconnected directory systems,
> the similar estimation must be taken in line with the total CA/CRL
> directory information model and validation processes. And standards
> should be applied.
> 
> I don think you can just guess this situation unless the system and
the
> trusted transactions betwen the users and CAs in the system is
> proprietary and self contained.
> Otherwise it is a User/Revocation rate assessment and how the
resultant
> CRLs are managed, placed and tested.
> 
> Some firm system details may help.
> 
> Hope this helps.
> 
> regards alan
> 
> > -----Original Message-----
> > From:	sankar ramamoorthi [SMTP:[email-masked]]
> > Sent:	Thursday, 14 January 1999 8:17
> > To:	[email-masked]
> > Subject:	CRL size
> > 
> > Question on CRL size.
> > 
> > 
> > I have a thin client which needs to verify a certificate validity.
The
> > plan is for the thin client
> > to communicate with a backend database server to get
> > the CRL associated with the cert. serial number. The
> > database is used only as a repository for CRLs.
> > The thin client only trusts the CA, so it can not
> > ask the backend to verify the certificate and hence
> > needs to get the associated CRL unit. There is also
> > no plan to implment OCSP in the thin client. 
> > 
> > The question is - what can I assume about the size
> > of the CRL unit? What is the minimum size of CRL unit
> > that is signed by the CA? I need to know the size to ensure it
> > ismanagable by the thin client and yet
> > can be fully trusted by it. 
> > 
> > Ideally I would like the CRLs to be distributed in
> > managable quantas and each quanta is a signed by the
> > CA. The backend database acts as repository for these
> > signed CRL quantas, and the thin client is able to
> > validate the cert by querying for the associated
> > CRL quanta.
> > 
> > Thanks for any input,
> > 
> > -- sankar --
> > 
> > 
> > PS: I admit I have not fully gone through all the
> > PKIX drafts. I had briefly scanned through them, but was getting
lost.
> > 
> > 
> > 
> > 
> > 
> > 
> > _________________________________________________________
> > DO YOU YAHOO!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: "Venky Nakhate" <[email-masked]>
Date: Wed, 13 Jan 1999 19:37:49 -0800

Hi Sankar,

Please check out http://www.valicert.com. we have a ocsp/crt toolkit which
I think  could meet your needs for doing revocation checking via our
ocsp/crt
servers .

If you need more information let me know. we also have a global VA
service which does CRL aggregation. I think this is what you are looking
for.

Thanks,

Venky

---

From: Stephen Kent <[email-masked]>
Date: Thu, 14 Jan 1999 10:29:48 -0500

Sankar,

>CRL or revocation rate etc.

As a consumer of a CRL, you have no control over the size or the frequency
of issue.  These are managed by each CA, subject to a set of parameters,
some of which have already been discussed.  Are the only CRLs you will deal
with ones that "your" CA issued, or do you have to be able to process CRLs
issued by other CAs?  If the former case if the one of interest, the CA can
divide the CRL into pieces by using the CRL distribution piont facility, to
help bound the size of each CRL segment.  The CA also can help minimze CRL
growth by keeping the validity interval shorter, although that creates a
tradeoff between CRL size and frequency of reissue or renewal.

Another approacch to dealing with CRL size concerns is to use a base CRL
and incremental CRLs, but it's not clear that this helps in your case,
because your appliance would need to store the base CRL, even though it
could fetch smaller, incremental CRLs as they are issued.

If you have to accept CRLs from other CAs, you have NO control over any of
these parameters, and thus must be prepared to accept potentially very
large CRLs.

Steve