Subject: RE: Publishing Base CRL's & replicating publication mechanisms

From: Trevor Freeman <[email-masked]>
Date: Fri, 1 Oct 1999 13:10:50 -0700

As a group of practical people, the futility of mandating creating something
which has no intrinsic benefit is plain for all to see. So I hope we don't
end up there, and I am open to any creative wordsmith input for
alternatives.
I don't know why this has been mandated, and it may be that this kind of
scenario was not foreseen when the stipulation was laid down. 
Multiple servers with replicating information is a proven solution for the
customer need for high availability so I don't think we can back off this
issue.

Original Message-----
From: Phillip M Hallam-Baker [mailto:[email-masked]]
Sent: Friday, October 01, 1999 12:50 PM
To: Trevor Freeman; Pkix List (E-mail)
Subject: RE: Publishing Base CRL's & replicating publication mechanisms

I believe the answer lies in your reading of the term 'published' which
as has previously been established cannot be mandated by the spec.

I believe that last time we looked at this it was decided that the spec
could mandate CREATION of a base CRL each time a delta was created but
could not mandate that it be sent anywhere! So an implementation that
'published' the CRL straight to /dev/null could be seen as 'compliant'!

This tends to support the idea that mandating a base update is not a
reasonable requirement since it cannot be enforced.

I believe that the motivation for this requirement was to allow
implementation of delta CRLs to be made optional since some consider
systems in which two CRLs (base and delta) must be obtained and
corellated to be intrinsically more complicated than systems in which
only one CRL (base) need be obtained.

		Phill

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Friday, October 01, 1999 2:52 PM
> To: Pkix List (E-mail)
> Subject: Publishing Base CRL's & replicating publication mechanisms
>
>
> Partitioned CRL's helps the client out by reducing the size of the
> individual CRL that needs to be downloaded. It may seem an obvious
> observation, but it does nothing to help out the impact on the
> infrastructure if you have a replicating publication mechanism.
> If a CA has
> 100K revocations on its list, then the impact of publishing new revocation
> data on the infrastructure is pretty much the same if you have 1 or 1K
> CRL's. The underlying infrastructure is understandably oblivious to the
> details of the change, only to the fact that a change has been made and
> needs to be replicated.  Publishing a delta CRL without publishing a base
> CRL would address this problem. More current revocation
> information can then
> be published, while minimizing the impact on the infrastructure.
> Therefore my proposal is to remove the current mandate that a base CRL be
> published every time a delta CRL is published.
> Trevor
>

---

From: Ben Laurie <[email-masked]>
Date: Fri, 01 Oct 1999 22:30:40 +0100

> end up there, and I am open to any creative wordsmith input for

Is that really a problem? No-one will buy something that is useless, but
you can't dictate how it should be made useful in this case, so why
worry?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi