Subject: Loop in revocation checking

From: "Peter Lipp" <[email-masked]>
Date: Thu, 15 Sep 2005 08:06:39 +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: Tom Gindin <[email-masked]>
Date: Fri, 16 Sep 2005 00:03:58 -0400

Peter:

        I don't understand the function of the last item in your problem 
statement.  What part of the validation algorithm checks the revocation 
status of a self-signed certificate, which cannot be part of a chain 
except as a trust anchor?  Thus, what difference does it make what 
revocation mechanisms are referenced in the AIA or CRLDP extensions of 
such a certificate?  They should never be executed.
        I would not deny that out of band checks of the revocation status 
of a trust anchor within a store of trust anchors might be useful, but 
such checks are not part of the validation algorithm.  In any case, a 
trust anchor whose revocation can ever be checked should naturally be 
represented by a cross certificate rather than a self-signed one, and the 
corresponding trusted issuer name is the SUBJECT of that cross 
certificate.
        For Todd, I have a different question.  If you have some use cases 
(or paradigms, or workflows) to bring to the WG's attention in this area, 
why don't you do so instead of objecting that standards are being drawn up 
without them?

        Tom Gindin

"Peter Lipp" <[email-masked]>
Sent by: [email-masked]
09/15/2005 02:06 AM
 
        To:     <[email-masked]>
        cc: 
        Subject:        Loop in revocation checking

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

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

                 - can't check revocation status - there is something 
wrong, don't 

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.

---

From: "Peter Lipp" <[email-masked]>
Date: Fri, 16 Sep 2005 08:17:30 +0200

> Thus, what difference does it make what 
> revocation mechanisms are referenced in the AIA or CRLDP 
> extensions of such a certificate?  They should never be executed.
None. I knew that this was irrelevant for the problem itself, but thought it
may illustrate the strangeness... :-)

Peter