Subject: RE: Loop in revocation checking

From: "Piyush Jain" <[email-masked]>
Date: Thu, 15 Sep 2005 12:14:45 -0700

Peter,

A few more questions on your trust model
- You mentioned that you are using the indirect CRL mechanism. Is the CRL issuer also self signed and directly trusted by clients and OCSP responder? 
If not, then how do you trust the indirect CRL signer?
- Is the OCSP responder cert self signed or is it issued by the self signed CA?

Now going back to your original questions :
Q1) if any implementation detects the loop, what would the logical  decision to be taken be (assuming that we get "not revoked" responses):
A. An intelligent software will detect and break the loop. This implies that the status of certificate could not be determined. So you must try to obtain the status using other means (possibly an alternative AIA), failing which the status must be treated as unknown.

Q2) 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?
A.) If you encounter a revoked status  then the certificate must not be accepted. Efficient softwares will stop processing when they encounter a revoked status. So ther won't be any loop in this case.

Q3) if you have your own implementation, have you considered that case and what would happen?
A.) If you are running into this issue in a closed PKI then it would usually point to an incorrectly deployed validation infrastructure. You need to revisit how you estblish trust in your OCSP responders and CRLs.

Q4) any other opinion that you wish to offer (besides security issues like what happens if the revocation service (OCSP and CRL) gets hacked)?
A.) Its typical for CAs to issue short lived responder certificates with a nocheck extension. This implies that revocation status check is not required on OCSP responder's certificates.

Piyush
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Peter Lipp
Sent: Wednesday, September 14, 2005 11:07 PM
To: [email-masked]
Subject: Loop in revocation checking

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:

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

"Tumbleweed E-mail Firewall <tumbleweed.com>" made the following
 annotations on 09/15/05 12:27:53
------------------------------------------------------------------------------
This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed.  If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
==============================================================================

---

From: "Peter Lipp" <[email-masked]>
Date: Thu, 15 Sep 2005 21:56:23 +0200

> A few more questions on your trust model
No, it's not our, it's their trust model :-) I just wanted to make this
point.

> - You mentioned that you are using the indirect CRL mechanism. Is the 
> CRL issuer also self signed and directly trusted by clients and OCSP 
> responder?
No.

> If not, then how do you trust the indirect CRL signer?
It gets a certificate from the root.

> - Is the OCSP responder cert self signed or is it issued by 
The latter.

> This implies that the status of certificate could not be 
> determined. So you must try to obtain the status using other 
> means (possibly an alternative AIA), failing which the status 
> must be treated as unknown.
I agree. But does this follow from some standard text or is this just common
knowledge that never has made it to a standard or ....

Peter