Subject: RE: Delta CRL Distribution Points

From: Trevor Freeman <[email-masked]>
Date: Wed, 29 Sep 1999 16:03:37 -0700

Having modest aspirations initially does not exclude the standard evolving
to encompass new features so we can revisit later and add more features. I
am just proposing one level of simplification, that is partition the base
CRL as per 2459, then have a single delta for that partition. If experience
shows we need to partition the delta CRL as well then we can add that later.
We are revising 2459 and delta CRLs are included in 2459, therefore we need
the discussion now.

-----Original Message-----
From: Phillip M Hallam-Baker [mailto:[email-masked]]
Sent: Wednesday, September 29, 1999 1:13 PM
To: Trevor Freeman; Pkix List (E-mail)
Subject: RE: Delta CRL Distribution Points

This is a good point. The FPDAM provides a lot of rope in the CRL area,
it is probably inadvisable to use all of it. On the other hand I see
considerable disadvantages to forbidding use of all of it!

As I see it delta CRLs, and the various scope mechanisms (serial numbers,
CDPs) have a certain degree of overlap. Certainly scopes and delta CRLs
are both a means of keeping the size of the CRL manageable.

I agree that using these mechanisms in conjunction would be complex in
practice. I am not sure that using scopes and delta CRLs is considerably
more complex than delta CRLs alone but it would certainly be a defensible
implementation decision to allow use of one mechanism or the other but
not both.

On the other hand some folk might argue that prohibiting use of both
mechanisms together would introduce complexity. This was the reason
why I raised no objection to the extension of OCDP to cover delta
CRLs.

[Note: in order to avoid starting another CRL arguing match I should
frame the discussion bellow by pointing out that the issues of scale
which I refer to are on the order of 1 million to 1 billion certs.]

I believe that the root of the complexity in this case is attempting to
manage a situation where multiple signed documents issued at different
times must be combined to validate a certificate. This is an intrinsic
problem with both Delta CRLs and Paul Kocher's CRTs. If the voulme of
updates becomes large there is a scalability problem which manifests
itself as a reliability issue as opposed to a performance issue.

[Similar objections were raised when I proposed that the meta-CRLs of
OCDP be infinitely recursive, a proposal which was sensibly reduced
to a comment made for prior art purposes in the public OCDP draft. This
is why the stacking depth of OCDP CRLs was limited to 2!]

Given this intrinsic complexity issue one might well regard the use of
scopes as essential if a large system were to be deployed using delta
CRLs.

I don't see that we need to take a decision on this in PKIX at this point
however. Certainly not until the FPDAM is voted on.

		Phill

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Wednesday, September 29, 1999 3:17 PM
> To: Pkix List (E-mail)
> Subject: Delta CRL Distribution Points
>
>
> I have been looking at the Delta CRL section of 2459 as well as the latest
> X.509 FPDAM, and have a number of issues. So the mail threads don't get
> confusing, I will try to confine each mail to a single topic.
> To implement Delta CRL's, you would need to add a mechanism to 2459 as to
> how\where a client finds a delta CRL. The PDAM defines two mechanisms, one
> of which (Freshest CRL) has the same ASN as an existing 2459 extension
> (CDP). I propose we include the Freshest CRL in the revised 2459 as the
> method to defining the Delta CRL distribution point. This
> extension could be
> used in both the certificate and the CRL itself. My view is that we should
> recommend that the extension be used in the CRL itself and that the
> extension should only contain the list of general names i.e. no other
> qualifiers. This gives a very simple relationship between the
> base and delta
> CRL. If you have already partitioned the base CRL, I don't see much
> advantage in partitioning the delta as well.
> Trevor
>

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Thu, 30 Sep 1999 11:24:28 -0400

I think I have it now, perhaps an example will help clarify things.

Let the initial cert population be {1, 2, 3, 4, 5, 6}

You propose that we allow this to be partitioned into two CDPs, X and Y.
	X = {2, 4 , 5, 6}
	Y = {1, 3}

There are two base CRLs, one per CDP partition.

What you are proposing it appears is that we do not allow someone to
then use the scopes to further partition the delta CRLs. In other
words we would forbid scope partitioning X into {2, 4} and {5, 6}.
Similarly it would be right out to partition the base CRLs as X, Y
and then define scope partitions {1, 2, 3} and {4, 5, 6}.

It seems to me that it is reasonable to advise folk to partition
their delta CRLs in the same manner as their base CRLs. I am not
sure it is possible to require this however.

A CA might issue two separate sets of CRL data for the same cert
population. For example there might be a CDP partitioned CRL
issued for one set of users and a scope partition for another set.

I think it is entirely reasonable for a CA to do this, and prohibiting
a CA from doing so on the grounds of 'simplicity' seems wrong to
me (not to say almost certain to be ignored).

I certainly don't think that a security spec can make any profile
restriction that an application would be wise to rely upon as a
security issue. PKIX applications must be able to tolerate information
produced that is not PKIX profile without disaster. So a PKIX app.
MUST be able to recognise that it has mismatched partitions even if
it is not REQUIRED to understand how to use them.

As I said earlier, delta CRLs are problematic and managing them is
intrinsically complex. Scope CRLs offer considerably more flexibility,
are intrinsically simpler and in many cases address the same need.

What I am not prepared to accept is any suggestion that because
delta CRL + scope CRL appears complex the answer is to exclude the
scope CRL entirely.

		Phill

> Sent: Wednesday, September 29, 1999 7:04 PM
> To: 'Phillip M Hallam-Baker'; Pkix List (E-mail)

---

From: "Peter Williams" <[email-masked]>
Date: Thu, 30 Sep 1999 12:11:43 -0700

> are intrinsically simpler and in many cases address the same need.

Delta CRLs are one mechanism that enable availability security
services for validation and other PKI status services. There are
several emerging security services that
address the availability requirements of PKI validation
services. One can expect a range of application of the delta-CRL technology,
in support of those sevices, much as digital signature mechanisms
supports a range of integrity services. I disagree that they
are intrinsically complex; that's VeriSign marketing hogwash, to use
a term from American-English.

The literature has much recorded know-how on delta handling, appropriate
data structures, and at one level, the PKIX problem is no different
to secure directory replication techniques, that also feature delta-based
synchronization schemes. For example, ValiCert's CRT technologies
uses much of that know-how, with careful security design; so the use
of delta-CRL technology is a good path to follow-up for next generation
validation services using open technology.

What we perhaps need to do as a group is understand the technical
interworking and security properties of proposed schemes. Microsoft has
taken the lead to get the work going, and is to be commended for
that step. I know ValiCert has a certain expertise based on
operating practical availability schemes for PKI status services
(based, in part, on delta-schemes tuned to PKI threats) which can
be fed in via the usual commenting process.

> delta CRL + scope CRL appears complex the answer is to exclude the

Tact, please!

There seems no reason why several delta-CRL schemes cannot support
multiple PKIX-specified availability services tuned to the
status distribution problem, where the proponent can justify the
distinctive properties of each.

Now that the agenda item is up for comment, each party that wishes
to suggest a use of CRL delta scheme can go write an ID. Then, the WG
and list can compare, reuse, discard, or reframe the contributions
into this evolving area of the PKIX architecture.

We can await the complex-scheme ID from VeriSign, I trust.

I am sure you can justify the benefits of your approach
in writing, as can others for their approaches. Once we have
some detailed specifications, we can see what would most
benefit the standard architecture: 1 single solution, or a
range of solutions fitting different requirements addressing
distinct Internet needs.

A minimal technical requirement for delta-CRL syntax handling
(common to all PKIX schemes) may be required; its identification
would be valuable, ...

I suggest.