Subject: CRL issuer asserting its own revocation status

From: Thomas Pornin <[email-masked]>
Date: Thu, 10 May 2007 17:08:32 +0200

Hello,

the NIST has produced in 2004 a test suite for X.509 path validation. It
can be downloaded at: http://csrc.nist.gov/pki/PKITesting.html
This suite comprises 224 unit tests.

One of those tests (4.14.30, page 95 in PKITS.pdf) is about this setup:
a CA has issued the EE certificate which we want to validate, and also
another certificate for an entity (let's call it CI) upon which has been
vested the power to issue CRL for the CA. In other words, the entity CI
owns a key pair, the public key of which is in a certificate issued by
the CA, and uses the private key to sign CRL which have all certificates
issued by the CA in its scope.

So far so good. A consequence is that the CRLs issued by CI also have
CI's certificate in their scope. The CA cannot therefore forcibly revoke
CI's certificate without CI's consent, which is quite understandable
since the whole idea is that revocation control has been handed to CI.

Trouble begins when it comes to validating such a path. A CRL can be
used to lookup the revocation status of a certificate only after that
CRL has been validated, i.e. a valid certificate path was built,
beginning with an appropriate trust anchor and ending with a certificate
for the CRL issuer. Here, that path ends with CI. But the validation
process of that second path includes checking the revocation status of
the certificates in the path, hence using the CRL. There is a loop: to
use the CRL, you have to know that the CI certificate is valid, which
entails using the CRL beforehand. In RFC 3280, the relevant steps are in
section 6.3.3, steps "f" to "k", where the validation of the certificate
path for the CRL issuer (step "f") comes before the lookup in the CRL
(step "j").

I understand that if another revocation information source is available
for CI (say another CRL, possibly limited in scope through a
distribution point, or an OCSP response), then there is no problem. But
assuming that an X.509 path validation implementation has access only to
the elements specified in the NIST test 4.14.30 (i.e. the trust anchor,
a CRL issued by the trust anchor, the CA certificate issued by the trust
anchor, the EE certificate, the CI certificate and the CRL issued by CI
and having both CI and EE in its scope), should that implementation
declare that the path to EE is valid ? Or may this implementation
declare the path to be invalid, for lack of proper revocation
information on EE, and still claim to conform to X.509 and/or RFC 3280 ?

From what I read in RFC 3280, the CRL processing should fail in that
situation, because of the loop described above. But the designers for
the NIST test 4.14.30 seem to think otherwise, and they apparently are
quite competent in that domain. Therefore, who is right ?

	--Thomas Pornin

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 10 May 2007 14:06:17 -0400

Thomas,

The question about circular dependencies that are created by situations 
such as the one in test 4.14.30 was discussed at great length at the 
time that PKITS was being developed, but the issue came up rather late 
in the development process (see emails from July and August 2003 with 
the subject "test cases 4.5.4 and 4.5.5" at 
http://cio.nist.gov/esd/emaildir/lists/pkits/maillist.html).  Initially, 
a number of the tests had circular dependencies, but late in the 
development process I made an effort to eliminate any circular 
dependencies from the tests.  On October 10, 2003, I sent a message to 
the PKITS mail list 
(http://cio.nist.gov/esd/emaildir/lists/pkits/msg00059.html) that stated:

      2) I removed the controversial circular dependencies from tests 
4.5.3 -
      4.5.8.  In each case, I did this by adding a distribution point 
CRL to
      the test data that only covers the self-issued certificate in the 
test. 
      The self-issued certificates include cRLDistributionPoints extensions
      pointing to the distribution point CRLs.

      (The indirect CRL test, 4.14.30, has not been changed, even though it
      includes a circular dependency.  Any attempt to remove the circular
      dependency would have resulted in a redundant test.  Until the issues
      surrounding circular dependencies have been resolved, this test is
      deprecated.)

Similarly, in the draft NIST Recommendation for X.509 Path Validation 
(http://csrc.nist.gov/pki/testing/NIST_Recommendation_for_X509_PVMs.pdf), 
test 4.14.30 is listed as "This test does not need to be run."

Dave

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 11 May 2007 19:56:35 +0200

David A. Cooper wrote:
> The question about circular dependencies that are created by 
> situations such as the one in test 4.14.30 was discussed at great 
> length at the time that PKITS was being developed, 
> [...].  Initially, a number of the tests had circular dependencies, 
> but late in the development process I made an effort to eliminate any 
> circular dependencies from the tests.
Why not keep them and just say any result is OK (it's up to the issuer 
not to generate them if he wants predictable results), but they should 
not cause the software to crash / hang ?