Subject: Loop in revocation checking

From: "Peter Lipp" <[email-masked]>
Date: Thu, 15 Sep 2005 07:49:34 +0200

Folks, Experts, Friends.... 

We are faced with a situation, where a certification service plans to use
the following scenario:

- A self-signed root CA, as usual.
- A CRL issuer, using the indirect CRL mechanism.
- An OCSP responder.
- The Certificate for the CRL issuer contains an AIA-extension pointing
  to the OCSP-responder.
- The Certificate for the OCSP responder contains a
  CRL-Distribution-Point pointing to the CRL issuer.
- The certificates for OCSP-Responder and CRL issuer both contain
  an AIA extension pointing to the OCSP responder and the CRL
  distribution point.
- The self signed certificate contains both an AIA-extension pointing
  to the OCSP-responder and a CRL distribution point pointing to the CRL
  issued by the CRL issuer.

If I now go and use standard validation algorithms, it hopefully will detect
there is a loop and has to make a decision. (Basically this could also
happen if the OCSP-responder certificate points to the same responder or in
other cases).

Now we observe, that

- we have never seen such a construction (and were not looking for one
  so far)
- it seems as if none of the current standards mention, discourage or
  even prohibit such a construction. Nor does any of them recommend it.

In our discussion we came to a deadlock, where everybody was convinced to be
right - deadlock. We have decided to post this here to this distinguished
community... 

Assuming that this service will serve a pontentially very large user base,
we have asked ourselves (and now you :-) the following questions:

- if any implementation detects the loop, what would the logical
  decision to be taken be (assuming that we get "not revoked" responses):
	- don't know, ask policy
	- can't check revocation status - there is something wrong, don't 
	  accept certificate
	- didn't see revocation, so certs must be ok
- if any of the two services has the others certificate revoked, we
  have a case where we have a lier and a truthsayer and don't know
  which is which - so we wouldn't accept the certificate, would we?
- if you have your own implementation, have you considered that case
  and what would happen?
- any other opinion that you wish to offer (besides security issues
  like what happens if the revocation service (OCSP and CRL) gets hacked)?

The argument of the service implementers is: "it is obvious how to interpret
the situation - any decent implementation will detect the loop and Consider
the status of the certificate as 'not revoked'" and since standards don't
prescribe different things, they may implement it that way (and clients will
be flexible enough to adapt if not).

The idea behind the concept is that this way the root CA never has to issue
a CRL while the service is operating and keeps administration effort low.

I am looking forward to your distinguished opinions ...

---

From: [email-masked]
Date: Thu, 15 Sep 2005 14:12:46 +0000

Peter - this question of yours documents WHY "user use paradigm's" and workflow's are needed for ANYTHING this organization wants to proffer. Especially if its to be accepted under the SOX reporting requirements.

Todd Glassey
 -------------- Original message ----------------------
From: "Peter Lipp" <[email-masked]>

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 19 Sep 2005 14:10:30 +0200

> We are faced with a situation, where a certification service plans

ok, first of all I would like to "confess" that I am one of the
designers of this "weird" PKI architecture.

>   issued by the CRL issuer.

In order to focus on the core of the problem , I describe a much
simpler scenario, where the problem is already present:

- A trusted root-CA, which does not issue CRLs
- A CRL signer that issues indirect CRLs for that CA.
- The certificate of the CRL signer is issued by the Root-CA.
- The certificate of the CRL signer contains a CRL Distribution
point identifying the CRL signr as the issuing authority.

According to RFC 3280 a validation algorithm should check the
revocation status of all certificates in the validation path, i.e.
for all certificates except the trust anchors (in our scenario the
self-signed root certificate). Consequently revocation status is
checked for the CRL signer certificate as well. However, this ends
up in a loop. So I only see two possible solutions:

1. Avoid such architectures, precisely, (on the top level of the
hierarchy) employ only CRL signers with self-signed certificates,
i.e CRL signers which are trust anchors. The drawback of such an
approach is that either this trust anchor must be permanently in
operation and "online" (i.e. connected to the repository which is
online), or you would have to manually and periodicaly generate and
transfer new CRLs. For high security demands you would certainly
want to lock away your trust anchor's private keys most of the time
and employ relatively short CRL issuing intervals.

2. The validation algorithm detects the loop assumes that the CRL
signer certificate is valid. This is justified by the fact that -
according to the CRL distribution point information - there is no
superior authority from which revocation status can be obtained. So
the CRL signer must be a "trust anchor for revocation status".

I know that this interpretation is not implied by any of the PKIX
documents but rather by the awareness that indirect CRLs issued by
CRL signers with certificates issued by the root CA will inevitably
cause such validation loops. On the other hand, I have never seen
any requirement or recommendation saying that signers of indirect
CRLs must have self-signed certificates.

With OCSP responders the situation is similar. It is not a good idea
 to use self-signed certificates for the responder, because then an
attacker could try to redirect the requests to its own responder. On
the other hand, if there is no superior OCSP-Respoder or CRL in the
PKI hierarchy, checking of revocation status of the reponder
certificate does make any sense.

Yes, the extension OCSPNoCheck provides a way to prevent validation
loops, but there is no equivalent extension for CRL. Furthermore, in
the presence of both, OCSP responder AND CRL, the security can be
greatly enhanced if the CRL signer propagates the revocation status
of the OCSP reponder and vice versa: A key compromise of only one
those two can be detected using the status information provided by
the other one.

I think, the standard behaviour for validation algorithms detecting
loops while checking status information of CRL signer / OCSP
reponder certificates should be defined in future PKIX documents.

Regards,
Johannes