From: "Julien Stern" <julien.stern@cryptolog.com>
Date: Mon, 22 Mar 2004 17:33:56 +0100
To: ietf-pkix@imc.org
Subject: Current status of CRL validation ?
Message-ID: <20040322163356.GA19867@cryptolog.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.5.1+cvs20040105i
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk


Dear list,

In November 2003, Santosh Chokhani raised a problem in the validation
of CRL paths. I was wondering what was the current status of CRL
validation and also have a few questions:

My current understanding is the following:

We have two different setups
1) direct CRL (signed by the CA itself)
2) Indirect CRL (signed with a certificate signed with the CA itself
	+ a few other bindings in extensions (crlIssuer, etc)

Santosh Chokhani suggested (I'm summarizing, see his post for the exact
words) that the path validating the certificate and the path validating
the CRL should have the same trust anchor and the same Issuer DNs
one-by-one (expect for the last cert in case 2, of course).

Question 1: what is the status of this proposal ?


Question 2: How do you validate the cert path associated to the CRL ?
	Some of the certificates included in this path might have
	been revoked. Do you have to construct a third path to validate
	the CRL which has information on the certificates in the CRL
	validation path ? (And possibly a fourth, a fifth, etc ?)

Do you really have to through all the following to validate
this hypothetical 2 level scheme:

Let us say that I have
- a Trust Anchor (CA1)
- a subCA (CA2)
- user certificates

CA1 -> CA2 -> Cert

To validate the chain, do I really have to:
1) start applying the X509 validation algorithm
2) obtain the CRL for CA2
3) reconstruct the path to validate the certificate which signs it.
4) start applying a new X509 validation algorithm to this new path
	+ the additional Trust Anchor and DN matching rules
5) Possibly repeat steps 3-4 until I find a path that I have already
	fully validated
6) verify the CRL and check that CA2 is not in.
7) obtain the CRL for user certificates
8) reconstruct the path to validate the certificate which signs it.
9) start applying a new X509 validation algorithm to this new path
	+ the additional Trust Anchor and DN matching rules
10) Possibly repeat steps 8-9 until I find a path that I have already
	fully validated
11) verify the CRL and check the certificate is not in.


Question 3: How to you replace CRL processing by OCSP in X509 path
	validation ? In particular, how do you check that the OSCP server
	certificate has not been revoked if it is different that the CA one ?

Thank you very much.

--
Julien