Subject: RE: Two questions on delta-CRL

From: "Mione, Tony" <[email-masked]>
Date: Tue, 2 Jan 2001 09:59:08 -0800

I am not sure what the concern is over needing to publish a 
new base crl with each delta. This makes perfect sense to me.

I think the point of publishing both is so that clients that only
process full CRLs can always come up with the same results as a client
that can process deltaCRLs. Otherwise, the results of a revocation
check will be non-trivial to predict and will vary depending on the
client capability and what the CA is willing to support in terms of
baseCRL availability.

Consider the following:

Time    CA Publishes

t1      baseCRL1

t2      baseCRL1a, deltaCRL1a      (baseCRL1a = baseCRL1+deltaCRL1a)

t3      baseCRL1b, deltaCRL1b      (baseCRL1b = baseCRL1+deltaCRL1b)

t4      baseCRL1c, deltaCRL1c      (baseCRL1c = baseCRL1+deltaCRL1c)

t5      baseCRL2, deltaCRL2        (baseCRL2 = baseCRL1+deltaCRL2)

t6      baseCRL2a, deltaCRL2a      (baseCRL2a = baseCRL2+deltaCRL2a)

etc.

Now client1 that needs the latest crl at time t3 <= t <= t4 retrieves
baseCRL1b (since they can't handle deltaCRLs). client2 fetches
deltaCRL1b and adds its contents to baseCRL1 (since it CAN handle
deltaCRLs). This saves bandwidth when client2 needs a crl. However,
both clients come up with the same answer.          

> -----Original Message-----
> From: David Cross [mailto:[email-masked]]
> Sent: Tuesday, January 02, 2001 8:36 AM
> To: 'Denis Pinkas'; Sam Schaen
> Cc: IETF-PXIX
> Subject: RE: Two questions on delta-CRL
> 
> 
> I think the important distinction is to ensure that a valid 
> base CRL always
> exists.  A client 1) may not understand a dCRL or 2) a client may not
> already have the base CRL that the dCRL is derived from.
> 
> The way I read the RFC is that a valid base CRL must exist 
> when the dCRL is
> published.  This does not necessarily mean that the base CRL must be
> re-published every time a dCRL is published.
> 

Actually, I think it means a revised baseCRL (which consists of the
contents of the deltaCRL added to the original baseCRL) should be published.
The baseCRL on which the delta is based should also be available from the CA
but does not get republished. My understanding of publishing CRLs is that
the CA makes them available in a directory.

> If a base CRL is re-published at the same interval as the 
> dCRL, the value of
> dCRLs diminishes as the cost and latency of base CRL 
> publication is much
> higher for the network. 
> 

I don't quite follow this. Little network bandwidth is consumed
moving a new baseCRL to a CAs directory. I believe that is all that
is involved in publication of the CRLs.

> David B. Cross

Take care.

Tony Mione                          Senior Software Engineer
RSA Security, Inc, 2955 Campus Dr. Suite 400, San Mateo, Ca. 
+1 650/295-7585                       [email-masked]

---

From: David Cross <[email-masked]>
Date: Tue, 2 Jan 2001 18:26:17 -0800

If a full CRL MUST be published every time a delta CRL is published, it
diminishes the value of publishing delta CRLs.  Replicating full CRLs can be
an expensive process depending on the size of the CRL and delta CRLs were a
solution to alleviate that.

Saying that both the delta aware and non-delta aware clients should have the
same information is an invalid argument.  That would mean that OCSP and
non-OCSP aware clients should have the same info which is simply not true.

The requirement should be relaxed.

David B. Cross

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]]
Sent: Tuesday, January 02, 2001 6:05 PM
To: 'Denis Pinkas'; Sam Schaen
Cc: IETF-PXIX
Subject: RE: Two questions on delta-CRL

I, too, would like to see the requirement relaxed to a full CRL SHOULD be
published when a delta CRL is issued.

If I remember correctly, this was discussed on the list. I believe PKIX has
it because X.509 had it. Also, in the past, the discussion indicated that a
CA might publish a new full CRL and then send it to /dev/null, so the full
CRL was only published in principal.

It would be good to get a definitive answer to how real the requirement for
the full CRL is.

Ambarish

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

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Tuesday, January 02, 2001 6:37 AM
> To: Sam Schaen
> Cc: IETF-PXIX
> Subject: Re: Two questions on delta-CRL
> 
> 
> Sam,
> 
> Thanks for attempting to answer the question. One possible
> answer would be
> to prevent people using delta-CRLs to get an advantage over 
> people using
> regular CRLs. The text used to write RFC 2459 was written at 
> a time where
> OCSP servers did not existed. However, clients now using OCSP 
> servers may
> get such an advantage, i.e. fresher information about 
> revocation status. 
> 
> Would the following scenario (currently forbidden by RFC
> 2459) makes sense ?
> 
> The full CRL is issued every day, and a delta CRL is issued
> every hour. 
> 
> I was wondering whether it would be possible to relax this
> rule, and thus
> have e.g.:
> 
> When a delta-CRL is issued, the CAs SHOULD also issue a complete CRL.
> 
> However, before doing so, we must understand the original
> rational and all
> the implications. To understand the original rational I would expect a
> response from one of the authors of RFC 2459. However, for 
> the second part
> of the question (i.e. all the implications) the discussion is open.
> 
> Denis
> 
>  
> > I believe the requirement for issuing a complete CRL when a
> delta CRL is
> > released makes sense.  It permits applications that don't
> understand delta
> > CRLs to obtain the most recent information.  Overall
> network bandwidth usage
> > is still reduced to the extent that other delta-CRL-capable
> applications do
> > make use of the delta CRL rather than retrieving a full CRL.  The 
> > availability of a current full CRL also allows an application to 
> > resynchronize at any point.
> > 
> > Denis Pinkas wrote:
> > 
> > > In section 5.2.4 (Delta CRL Indicator), RFC 2459 states:
> > >
> > >   The delta CRL indicator is a critical CRL extension
> that identifies a
> > >   delta-CRL.  The use of delta-CRLs can significantly improve
> > >   processing time for applications which store revocation
> information
> > >   in a format other than the CRL structure.  This allows
> changes to be
> > >   added to the local database while ignoring unchanged
> information that
> > >   is already in the local database.
> > >
> > >   When a delta-CRL is issued, the CAs MUST also issue a
> complete CRL.
> > >
> > >   (...) Again, a delta-CRL MUST NOT be issued without a
> corresponding
> > >   complete CRL.
> > >
> > > The two questions are the following:
> > >
> > > 1) What is the rational for mandating the issuance of a
> complete CRL each
> > > time a delta-CRL is issued ?
> > > 2) Under which conditions could this requirement be relaxed ?
> > >
> > > Denis
>

---

From: [email-masked]
Date: Wed, 3 Jan 2001 10:22:37 -0500

Hi Denis,

If you look at Annex C of X.509 (2000) on Examples of Delta CRL Issuance,
you will see that a full CRL does NOT need to be issued with each Delta CRL.

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Tuesday, January 02, 2001 6:25 AM
To: IETF-PXIX
Subject: Two questions on delta-CRL

  The delta CRL indicator is a critical CRL extension that identifies a
  delta-CRL.  The use of delta-CRLs can significantly improve
  processing time for applications which store revocation information
  in a format other than the CRL structure.  This allows changes to be
  added to the local database while ignoring unchanged information that
  is already in the local database.

  When a delta-CRL is issued, the CAs MUST also issue a complete CRL.

  (...) Again, a delta-CRL MUST NOT be issued without a corresponding 
  complete CRL. 

1) What is the rational for mandating the issuance of a complete CRL each
time a delta-CRL is issued ?
2) Under which conditions could this requirement be relaxed ?

Denis

---

From: Simon Tardell <[email-masked]>
Date: Wed, 3 Jan 2001 16:21:13 +0100

> is involved in publication of the CRLs.

Some directories we've tried become very tired when you write large objects
to them (megabyte and up) and to some extent when reading the same large
objects. It is not a question of bandwidth, but rather of how the directory
vendors tune their apps (then again, maybe there was a knob to tweak that I
didn't see). 

Simon.

Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
[email-masked]
Work smarter! http://www.smarttrust.com/career

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 03 Jan 2001 09:19:52 -0700

Simon,

Without intending to set off any vendor bashing, it might be nice to know
the directory you were using, so others could help determine whether
that is a common problem or not.

By "tired" I assume you mean there was a lot of grinding caused by garbage
collection or moving files around when writing the data.  In the best of all worlds
that would be undesirable, of course, but I suppose it could happen.  II it
also made retrievals considerably more "painful" (since we are anthropomorphizing,)
that would be worse, of course.  But some data, rather than generalizations,
would be helpful.

Of course a different issue would be why, given the CRLDistributionPoint facility
which could be use to segment a CRL into a set of more reasonable size sub-CRLs,
you needed to have a megabyte CRL in the first place?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software

>>> Simon Tardell <[email-masked]> 01/03/01 08:21AM >>>

Simon.

---

From: David Cross <[email-masked]>
Date: Wed, 3 Jan 2001 08:26:24 -0800

It is a problem in any large distributed directory, web farm, or complex CDP
infrastructure.  It is more of an issue of the infrastructure design and not
a particular product(s).

It is easy to get multi-MB CRLs if you have large numbers of revocations
(corporate layoffs, etc) that occur from a single CA. 

David B. Cross

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 8:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Two questions on delta-CRL

Simon,

By "tired" I assume you mean there was a lot of grinding caused by garbage
collection or moving files around when writing the data.  In the best of all
worlds
that would be undesirable, of course, but I suppose it could happen.  II it
also made retrievals considerably more "painful" (since we are
anthropomorphizing,)
that would be worse, of course.  But some data, rather than generalizations,
would be helpful.

Of course a different issue would be why, given the CRLDistributionPoint
facility
which could be use to segment a CRL into a set of more reasonable size
sub-CRLs,
you needed to have a megabyte CRL in the first place?

Bob

Robert R. Jueneman
Security Architect

Simon.