Subject: RE: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt comments)

From: Ambarish Malpani <[email-masked]>
Date: Mon, 23 Apr 2001 13:02:53 -0700

Hi Paul,
    Even if you are requiring clients to pull the CRLs from your
directory, you still need to have enough bandwidth to and replication
of the directory to support all the clients who need to pull the
new CRL every time it is issued.

Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: Monday, April 23, 2001 11:51 AM
> To: David P. Kemp; [email-masked]
> Subject: Re: delta-CRLs (was Re:
> LastCall:draft-ietf-pkix-new-part1-06.txt comments)
> 
> 
> At 12:50 PM -0400 4/23/01, David P. Kemp wrote:
> >I'll refer you to Russ' message of Jan 18 "Re: Two questions 
> on delta-CRL":
> >
> >   "I think we may be splitting hairs on the term "issue". I am not
> >    sure that I would consider a CRL that was generated but not
> >    distributed to be "issued".
> 
> I think we are splitting hairs on what "distributed" means.
> 
> >The problem is not that it is too burdensome for a CA to 
> have a cron job
> >that sweeps the database and signs a full CRL every time it 
> signs a delta.
> >The problem is that once the full CRL is signed, it is 
> transmitted across
> >the network to directory/database/repository replicas and to clients.
> 
> "Transmitted"? The only common form of "push" on the Internet is 
> email, and I know of no CRL-over-email distribution schemes. Much 
> more common is that the CA simply puts the newly-issued CRL on its 
> FTP/web server and waits for people who want the CRL to come to them.
> 
> Some people have automated jobs that mirror the CRLs every day or 
> even more often; these folks have already calculated the cost of 
> mirroring so often (and of not using delta CRLs).
> 
> >If you are a PKI provider (as I am), and you have to provision 3.5
> >million subscribers, the cost of that provisioning with full CRLs is
> >prohibitive, whereas the cost of provisioning with deltas is not.
> 
> You do not have to provision them with the latest CRL; you simply 
> need to let them get the latest CRL when they feel like it. Or, 
> better yet, tell them to get the delta CRL; that is why you issued 
> it, yes?
> 
> >If Russ (i.e. the PKIX WG) would make a clear statement that "issue"
> >means "sign and place in one repository", vice "sign and distribute
> >to all RPs", then I would have no problem with the current MUST
> >requirement.  But if a CRL is not deemed to be "issued" unless it is
> >available to all, then I strongly agree with Trevor, David Cross, and
> >Ambarish that the requirement to "issue" a full CRL for every delta
> >must be relaxed.
> 
> We agree here, other than I would say "issue" means "sign and place 
> in at least all the repositories that are pointed to in any CRL 
> Distribution Point URI."
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
>

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 23 Apr 2001 16:20:54 -0700

>new CRL every time it is issued.

The alternative is that some users would have a different (that is, 
better) list of what is in the CRL than others, and those others 
would have no way of knowing that their list of revoked certificates 
is incomplete. That seems pretty awful to me. To be a bit crass, if 
you don't have the bandwidth, force your users use delta CRLs, or 
don't be a CA.

If for some reason the wording in son-of-2459 goes towards not 
requiring a new CRL being issued, there also needs to be a fairly 
stern warning both in the delta CRL section and in the security 
considerations section saying that some users will have different 
views of what certificates have been revoked, and that they won't 
know it.

--Paul Hoffman, Director