Subject: RE: delta-CRLs (was Re: Last Call:draft-ietf-pkix-new-part1-06.tx t comments)

From: Ambarish Malpani <[email-masked]>
Date: Sat, 21 Apr 2001 18:03:06 -0700

Russ, the problem with this is that CAs might be unwilling to issue
delta-CRLs because issuing a full CRL every time is too
burdensome.

The net result is that *nobody* has access to the latest
revocation information - not even the smart clients who can
understand delta CRLs.

I would prefer that we drop that requirement that a full CRL
be published whenever a new delta CRL is published.

Regards,
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: Housley, Russ [mailto:[email-masked]]
> Sent: Friday, April 20, 2001 1:26 PM
> To: [email-masked]
> Subject: Re: delta-CRLs (was Re: Last
> Call:draft-ietf-pkix-new-part1-06.txt comments)
> 
> 
> 
> > >In the third paragraph the first sentence (still) says:
> > >
> > > >    When a conforming CA issues a delta CRL, the CA MUST 
> also issue a CRL
> 
> 
> Originally, this sentence was placed in RFC 2459 to ensure 
> that simple 
> clients are able to get the best possible revocation 
> information.  We did 
> not want to require CAs or clients to support delta-CRLs, but 
> if a CA chose 
> to support delta-CRLs, we did not want to penalize clients.
> 
> I do not see that either of these desires has changed.
> 
> Russ
> 
>

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 22 Apr 2001 07:06:07 -0700

>delta-CRLs because issuing a full CRL every time is too

Could you describe how it is "too burdensome"? Maybe I'm being naive, 
not being a CA, but asking a CA to sign a second document (the full 
CRL) at the time that it signs the first document (the delta-CRL) 
really doesn't seem that onerous.

I think the current requirement is fine.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Michael Myers" <[email-masked]>
Date: Sun, 22 Apr 2001 18:13:27 -0700

Ambarish, Paul:

I must second Paul's concern.

If you work through what it takes for to implement both "full" and "delta"
CRL capabilities (i.e. CRON-driven sweeps across a database, formatting the
relevant info into 2459-compliant syntax, signing the result and pushing it
out to wherever or whomever) the software-level requirements to produce a
delta are pretty close to identical to those for a full.  Basically, it's
just another crontab entry with perhaps a different period.

But another thing bothers me in this dialog.  The notion of a full
backup/baseline in conjunction with (perhaps) more frequent deltas is a very
well known and highly advised practice, for an obvious set of reasons.  We
should be thinking more about how this general principle applies in this
instance.  PKI is not so unique in its nature that this standard database
maintenance practice does not apply.

Mike

> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: Sunday, April 22, 2001 7:06 AM
> To: [email-masked]
> Subject: RE: delta-CRLs (was Re: Last

---

From: Eric Rescorla <[email-masked]>
Date: 22 Apr 2001 18:20:12 -0700

> delta-CRLs because issuing a full CRL every time is too
Ambarish, could you explain why the cost of issuing a full
CRL is too burdensome? Surely it's not the cost of the signature
itself you're concerned with.

-Ekr

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 23 Apr 2001 12:50:32 -0400

Paul,

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

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

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.

Dave K

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 23 Apr 2001 11:30:39 -0700

Dave,

But in a broader sense, isn't that precisely the problem directory
replication is all about?

It would be useful to hear of empirical studies establishing the extent to
which PKI information management today dominates directory (X.500, LDAP)
operations.  I advocate that we need to know what today's ground truth tells
us before we flip this parity bit; else wiggle the text as I proposed and so
provide everybody the tuning knobs they want to tailor the standard to local
needs.

More tactically, one could produce a full CRL as a "backup" but let the
delta practice take the burden of timeliness and bandwidth efficiency.  But
in all cases where non-repudiation becomes a true (vice theoretical) issue,
there MUST be a full CRL around somewhere that cleanly establishes a
context.  Else one is faced with reconstituting the full context via
re-accumulation of all the relevant deltas.  Not an easy task either, and
one prone to error.  Given the ease with which a full CRL can be produced
(assuming mechanisms are in place to produce deltas), just crontab two
periods:  a "full" production and a "delta" production, with the period of
the latter shorter than the former.  You don't have to push the full CRL all
over the place, but at a minimum certainly have it available.

A systems-level tradeoff, as always.  But dumping full CRLs entirely and
trusting deltas exclusively isn't something I'd advocate to any enterprise
concerned about its risk management practices.

Mike

> From: [email-masked]
> . . .

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 23 Apr 2001 11:51:18 -0700

>    distributed to be "issued".

I think we are splitting hairs on what "distributed" means.

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

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

>Ambarish that the requirement to "issue" a full CRL for every delta

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

---

From: "Carlin Covey" <[email-masked]>
Date: Mon, 23 Apr 2001 11:47:13 -0700

Russ,

A CA might wish to generate a dCRL simply for the purpose of
handing it off to an OCSP responder, with no intention of the
dCRL falling into the hands of RPs.  Since the CA does not
"issue" the dCRL, apparently the CA does not need to generate
a full CRL?

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of David P. Kemp
Sent: Monday, April 23, 2001 9:51 AM
To: [email-masked]
Subject: Re: delta-CRLs (was Re:
LastCall:draft-ietf-pkix-new-part1-06.txt comments)

Paul,

Dave K

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 23 Apr 2001 15:07:28 -0400

Carlin:

By my reading of RFC 2459, the CA must generate and make publicly available 
a CRL every time that it generates a delta-CRL.

Russ

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 23 Apr 2001 15:44:26 -0400

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

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

> better yet, tell them to get the delta CRL; that is why you issued

[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