Re: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txtcomments)

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

Paul Hoffman / IMC wrote:
> 
> "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.

[dpk] Push or pull, smtp or ftp or http or ldap, the bits are carried
across the net in some manner.  The bits are what I'm talking about,
not the protocol.

> 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).

[dpk] Great! That's what I'd like to see to reduce latency below what
you'd get from a pure (client-demand-driven) pull architecture.  But by
"more often", do you mean every hour, for 3.5 M subscribers, 3 year
certificate validity, and 22% per year revocation rate?  Do the math,
and you'll see what I mean.

> 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?

[dpk] Yes, that's the point.  And if clients can get delta CRLs every
hour, what's the reason for PKIX requiring CAs to "issue" full CRLs
every hour?

I agree completely with Mike Myers - no one is suggesting getting rid
of full CRLs; deltas can't work without first being initialized by a
full.  But PKIX should say that clients that can't handle deltas are
stuck with whatever fulls are available (24 hours) instead of promising
those clients that they can have 1 hour fulls regardless of the cost
to the infrastructure.

Dave