Subject: RE: Loop in revocation checking

From: "Piyush Jain" <[email-masked]>
Date: Mon, 19 Sep 2005 10:08:27 -0700

Comments inline.

>>>-----Original Message-----
>>>From: [email-masked]
[mailto:[email-masked]]
>>>On Behalf Of Johannes Merkle
>>>Sent: Monday, September 19, 2005 5:11 AM
>>>To: [email-masked]
>>>Subject: Re: Loop in revocation checking
>>>
>>>
>>>> We are faced with a situation, where a certification service plans
>>>> to use
>>>> the following scenario:
>>>
>>>ok, first of all I would like to "confess" that I am one of the
>>>designers of this "weird" PKI architecture.
>>>
>>>
>>>> - 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.
>>>
>>>
>>>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.
>>>

This scenario is okay. The only issue is - how to perform revocation
status check on CRL signer. 
Usually it is solved by the root CA issuing a small long lived CRL and
having the CRL signer distribution point pointing to this CRL.
OCSP solution is slightly different. CA's can issue short lived OCSP
responder certificates with ocspNoCheck extensions. This tells the
clients that no revocation status check needs to be performed on
responder's certificate
>>>
>>>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".

Assuming that a certificate is valid - is incorrect in this case.
I'm not sure why an extension similar to ocspNocheck is not defined for
CRL signers. May be the experts thought that it would be redundant, as
this problem can be solved my making use of a distribution point ( See
above).
>>>
>>>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.
>>>
ocspNoCheck with short lived responder certificates solves this.
The other alternative is to sign the OCSP responses using CA key.

>>>Yes, the extension OCSPNoCheck provides a way to prevent validation
>>>loops, but there is no equivalent extension for CRL. 

I'm not sure why there is no equivalent extension for CRLs. In my
opinion it would provide similar benefits as it does for OCSP.

>>>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.
>
OCSP responder's reply cannot be trusted until CRL signer's status is
verified.
CRL signer's CRL cannot be trusted unless OCSP responder's status is
verified.
You need the root CA to provide the status of at least one of them to
make a decision one way or other.
Alternatively, you can directly trust the CRL signer.

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

Cheers
Piyush

"Tumbleweed E-mail Firewall <tumbleweed.com>" made the following
 annotations on 09/19/05 10:16:38
------------------------------------------------------------------------------
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: Johannes Merkle <[email-masked]>
Date: Tue, 20 Sep 2005 13:34:11 +0200

Piyush,

I understand your objections against this setting and my suggestion
for an algoithm behaviour in case of loops. However, I feel that all
other solutions are not optimal.

> having the CRL signer distribution point pointing to this CRL.

Th problem with long lived CRLs (which are updated after
revocations) is that the verifier can't be sure whether he has
obined the latest version. An attacker could have replaced the
current CRL with an old one, which has (according to the nextupdate
date) not yet expired.

> clients that no revocation status check needs to be performed on

This is also a compromise betwen security and usability.

> The other alternative is to sign the OCSP responses using CA key.

This means that the CA key is in operation on a publicly accessible
server. This doesn't seem to be a perfect solution either.

> CRL signer's CRL cannot be trusted unless OCSP responder's status is

Which means that revocation status checking has come to a dead end.
This is a similar situation as with self-signed certificates.
However, for self-signed certificates a standard behavior is defined
for validation algorithms.

My point is that such a standard behaviour definition is missing in
the PKIX documents for revocation checking loops. A postulated
validity in case of such loops would allow more secure and flexible
provision of revocation status.

Regards,
Johannes