RE: Current status of CRL validation ?

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

Julien:

See responses in-line in [].

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of Julien Stern
Sent: Monday, March 22, 2004 11:34 AM
To: ietf-pkix@xxxxxxx
Subject: Current status of CRL validation ?



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

[My impression from informal discussions with RFC 3280 authors is that they
plan to add the text to 3280.  I am also drafting amendment to X.509 Annex
B]

 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)

[The indirect CRL issuer need not be issued a certificate by the CA that
issued the certificate whose status is being checked]

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).

[The same "trust anchor" should be changed to "the subject DN of the trust
anchors in the two paths should be identical.  This is to account for when
root uses separate keys for signing certificates and CRLs and o account for
root key rollover]

[The one-by-one matching should ignore self-issued certificates]

["except for last certificate" should be replaced with the logic that
terminates the name matching when one of the path ends.  This permits the CA
to create subordinates for CRL issuance and permits CA to nominate a higher
authority to issue CRL]

Question 1: what is the status of this proposal ?

[See previous answer]

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 ?)

[Certification path development and validation for CRL is no different than
path development for anything else.  Unless you can get an authenticated
public key to verify signature on a CRL, you are out of luck]

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.

[I do not have time to review if you listed everything, but the idea is that
you do need to develop paths for CRL.  There are efficiency techniques one
can use]

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
?

[It is not different from other certification path validation issues.  Your
local policy decides whether OCSP needs to start with the same root.  The
revocation status of OCSP server itself can be ignored if no-check extension
is present in the OCSP server certificate]

Thank you very much.

--
Julien