Subject: deltaRevocationLists and LDAP

From: "Jochen Keutel" <[email-masked]>
Date: Mon, 13 Sep 1999 13:39:45 +0200

Hello,
  I asked the following on the cert-talk mailing list some days ago but haven't got any response yet ...

Thanks for any hint.

Bye,
		Jochen.
---
Hello,
  following problem:

- On day 1 a CA issues a complete CRL with number 1 and stores it in an LDAP server - Entry "CN=CA,O=company,C=DE", attribute certificateRevocationList (no special crlDistribution points are used).
- On day 2 this CA issues again a complete CRL with number 2 and additionally a deltaRevocationList (number 2, deltaCRLIndicator 1) and stores it in the LDAP server - the attribute value of certificateRevocationList will be overwritten, and the deltaCRL ist stored in the attribute deltaRevocationList
- On day 3 this CA issues again a complete CRL with number 3 and additionally a deltaRevocationList (number 3, deltaCRLIndicator 2) and stores it in the LDAP server - the attribute value of certificateRevocationList will be overwritten, and the deltaCRL ist stored in the attribute deltaRevocationList. So the attribute deltaRevocationList has two values now.

(This problem is simplified, of course - just to demonstrate the problem. E.g. the CRL is assumed to be valid one day.)

What does a PKI user do?

On day 1 it loads the complete CRL from the LDAP server.

On day 2 it checks "next Update" - therefore it has to load either a new complete CRL or the delta. Let's assume the policy is "load deltas". So it performs - in LDAP terms - a
	ldapsearch -h host -p port -b "CN=CA,O=company,C=DE" \
	-s base 'objectClass=*' deltaRevocationList
OK - exactly one deltaCRL is returned.

On day 3 it checks again "nextUpdate" - and again it has to get a new delta from the LDAP server.

Now the question: How can the client specify (in the LDAP protocol - V2 and V3) that it wants to get exactly the DeltaCRL number 3 ???

Next question: Let's assume another client loads the complete CRL on day 1, on day 2 he does nothing (vacations, ...). On day three he wants to load "all Deltas since day 1". Again - how can this be formulated in LDAP terms?

---

I'm familiar with X.500 and LDAP V2 and V3. I know the X.500 search control "matchedValuesOnly"; I know the special matching rules from X.509 (97). Still this problem doesn't seem to be easy.

So: Is there any standard describing the answer? (I haven't found anything in the PKIX RFCs - esp. 2459 and 2559.)
How do implementors of PKI products (which use LDAP) solve this problem?

I guess the problem is not new - the scenario seems very basic, and it should happen quite often at many companies using PKIs ...

Bye,
		Jochen.
---
Jochen Keutel
duerr com.soft, Senior Consultant
"Directory Services and Security Solutions"
Berlin, Germany

---

From: "David Chadwick" <[email-masked]>
Date: Mon, 13 Sep 1999 16:48:24 +0100

From:           	"Jochen Keutel" <[email-masked]>

>   following problem:
Help is on its way. But..
Unfortunately there is no solution for LDAPv2, as it is a "dead 
protocol" i.e. it cannot be extended in any way, and the IETF have 
stopped its standardisation. But there is a solution on its way for 
LDAPv3. A new Internet Draft has been released that gives LDAPv3 
the X.500 DAP matchedValuesOnly facility. See:

<draft-ldapext-matchedval-01.txt>

for details. This will allow you to retrieve a 
single attribute value providing the matching 
rule is fine tuned enough. The matching rule you 
want is the certificateList matching rule. THis 
allows you to select on CRL number. Now whilst 
you cannot select a delta CRL with a particular 
delta indicator (base crl number) and crl number, 
being able to select a delta CRL with a 
particular crl number (or range of numbers) 
should be sufficient. Of course, first you have 
to have an LDAP implementation that supports the 
matching rule (which is currently only defined in 
X.500). My LDAPv3 profile 

<draft-pkix-ldap-v3-01.txt>

has started to define this matching rule in LDAP 
terms, but is not yet complete. Mark Wahl has 
said that he will take this work into the update 
of LDAPv3 when it is issued.

David

David

> - On day 1 a CA issues a complete CRL with number 1 and stores it in an
> LDAP server - Entry "CN=CA,O=company,C=DE", attribute
> certificateRevocationList (no special crlDistribution points are used). -
> On day 2 this CA issues again a complete CRL with number 2 and
> additionally a deltaRevocationList (number 2, deltaCRLIndicator 1) and
> stores it in the LDAP server - the attribute value of
> certificateRevocationList will be overwritten, and the deltaCRL ist stored
> in the attribute deltaRevocationList - On day 3 this CA issues again a
> complete CRL with number 3 and additionally a deltaRevocationList (number
> 3, deltaCRLIndicator 2) and stores it in the LDAP server - the attribute
> value of certificateRevocationList will be overwritten, and the deltaCRL
> ist stored in the attribute deltaRevocationList. So the attribute
> deltaRevocationList has two values now.
> 
> (This problem is simplified, of course - just to demonstrate the problem.
> E.g. the CRL is assumed to be valid one day.)
> 
> What does a PKI user do?
> 
> On day 2 it checks "next Update" - therefore it has to load either a new
> complete CRL or the delta. Let's assume the policy is "load deltas". So it
> performs - in LDAP terms - a
> Now the question: How can the client specify (in the LDAP protocol - V2
> and V3) that it wants to get exactly the DeltaCRL number 3 ???
> 
> Next question: Let's assume another client loads the complete CRL on day
> 1, on day 2 he does nothing (vacations, ...). On day three he wants to
> load "all Deltas since day 1". Again - how can this be formulated in LDAP
> terms?
> 
> ---
> 
> I'm familiar with X.500 and LDAP V2 and V3. I know the X.500 search
> control "matchedValuesOnly"; I know the special matching rules from X.509
> (97). Still this problem doesn't seem to be easy.
> 
> So: Is there any standard describing the answer? (I haven't found anything
> in the PKIX RFCs - esp. 2459 and 2559.) How do implementors of PKI
> products (which use LDAP) solve this problem?
> 
> I guess the problem is not new - the scenario seems very basic, and it
> should happen quite often at many companies using PKIs ...
> 
> Bye,
>   Jochen.
> ---
> Jochen Keutel

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
*NEW* Email [email-masked] *NEW*
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

---

From: "Jochen Keutel" <[email-masked]>
Date: Wed, 15 Sep 1999 01:18:56 +0200

Hello David, hello Peter,
  thanks for your responses. You are proposing different approaches - please let me comment and summarize them:

1. David Chadwick:
- Remark: X.509 (97) defines both matching rules - certificateListExactMatch and certificateListMatch. But - the certificateListMatch is not mentioned in the attribute definition of certificateRevocationList or deltaRevocation List - both have only the equality matching rule. So the X.500 servers I know of have implemented only the equality matching rule for CRLs (or nothing).
- Let's assume we are doing pure X.500 - and the X.500 server supports matchedValuesOnly and all matching rules mentioned above. The solution for my problem would be:

a) A client who wants to retrieve a specific Delta-CRL (with "thisUpdate=nnn") ASN.1-encodes a CertificateListExactAssertion with the correct issuer and "thisUpdate=nnn". It performs a Search (scope baseObject) with filter "deltaRevocationList=<CertificateListExactAssertion>" (using the equality matching rule), matchedValuesOnly=TRUE, requestedAttributes=deltaRevocationList.

Correct?

b) A client who wants to retrieve all Delta-CRLs since CRLnumber n ASN.1-encodes a CertificateListAssertion with the correct issuer and CRLnumber=n. It performs a Search (Scope Base) with filter "deltaRevoctionList matches <CertificateListAssertion> using certificateListMatch", matchedValuesOnly=TRUE, requestedAttributes=deltaRevocationList.

Correct?

- Let's assume the LDAP protocol and the LDAP servers have implemented matchedValuesOnly and the matching rules mentioned above. Then the scenario would be like X.500 - the only difference would be (following draft-pkix-ldap-v3-01.txt) that the Search filter in LDAP wouldn't be a ASN.1-encoded structure but a $-separated string.

Correct?

2. Peter Williams:

You are proposing to store each deltaRevocationList as a single-valued attribute of different entries. E.g. if we have "CN=CA,O=company,C=DE" as the CA entry then we could create
- "CN=deltaCRL 1,CN=CA,O=company,C=DE" holding as single-valued attribute the deltaCRL with number 1
- "CN=deltaCRL 2,CN=CA,O=company,C=DE" holding as single-valued attribute the deltaCRL with number 2
- ...
Each of these entries could have an additional indexed attribute "deltaCRLNumber" to make searches simple.

Directory administrators can easily manage that old entries (holding deltaCRLs with CRLnumber less than n) will be removed.

Correct? (Have I interpreted your proposal correctly?)

---

My opinion:
- Peter's proposal works well with any directory - LDAP V2, LDAP V3, X.500 (88), ...
- David's proposal doesn't work with any of currently existing directories.

But: Peter's solution is a good workaround for current directory deficits - but it's not standard. You have to extend the schema (at least with a new structure rule, name form and object class (or content rule)). And X.509 defines objects holding what we need.
  So I'd really like to see a standard solution.

Is it possible that you (LDAPEXT, PKIX) not only define "matchedValuesOnly" and the X.509(97) matching rules but that you (PKIX) define also the complete LDAP V3 protocol how clients should retrieve specific CRLs? I think that would make interoperability much easier.

Bye,
  Jochen.

P.S. My problem ist that I need a solution NOW. (I'm having a customer with about 70000 certificates circulating.) And I don't like the idea of implementing Peter's logic into the clients NOW and implementing other logics some months later.
Are there any other PKI vendors who could describe what they are doing today in their products regarding deltaCRLs?

---
Jochen Keutel