Subject: OCSP Responder Status

From: "Mauricio Balassiano" <[email-masked]>
Date: Mon, 24 Nov 2008 15:02:03 -0200

Hi,

In a model where the OCSP Responder certificate is issued by the same CA who
issues the end entity certificates, isn’t it a disadvantage to use the OCSP
service when CRL is used for checking the validity status of the OCSP
Responder certificate ?
 
The OCSP RFC says that a CA may specify how the responder's certificate be
checked for revocation. This can be done using CRL Distribution Points if
the check should be done using CRLs or CRL Distribution Points, or Authority
Information Access if the check should be done in some other way.

Which other way, other than CRL, could a OCSP Responder certificate be
checked considering that OCSP No Check extension is not an option ? 

Thanks,

  _____  

 <http://www.certisign.com.br>  <http://www.certisign.com.br/> CERTISIGN
<http://www.certisign.com.br> Mauricio Schueftan Balassiano
Departamento de Normas e Gerência de PKI
(21) 4501 1850

Certisign Certificadora Digital
certisign.com.br <http://www.certisign.com.br>

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 25 Nov 2008 14:47:08 +0100

Mauricio,

> checked considering that OCSP No Check extension is not an option ?

An alternative could be another OCSP-Repsponder specified in the first OCSP responders certificate. For establishing
trust in this second responder, there are the three option mentioned in RFC 2560:
- It uses the CA signing key to sign the OCSP responses (
- It's certificate has also been issued by the CA that issued the certificate of the first responder. This only
transfers the problem to the second responder
- It's certificate has been issued by another CA, e.g. a root CA. In this case, the clients must be locally configured
to trust the responders replies.

At the top level of this OCSP hierarchy you will face the problem that unless you are willing to trust the top-level
responder's certificate without revocation checking (e.g. by using OCSP No Check), or to use a CA key to sign the
top-level OCSP responses, you must switch to CRLs. I agree that this in not satisfactory in many circumstances.

For CRLs you'll face a similar problem at the top of the "CRL hierarchy": RP have to trust the top level CRL signer
without revocation checking. But if you are not willing to issue directs CRLs (e.g. because the root CA is operated
offline and you wish to avoid daily access to it) then your top level CRL signer will constitute a kind of second trust
anchor, at least with respect to revocation status checking.

Johannes

--
Johannes Merkle
secunet Security Networks AG
www.secunet.com

---

From: "Liaquat Khan" <[email-masked]>
Date: Tue, 25 Nov 2008 19:15:45 +0400

The problem with your option 3 is that RFC2560 doesn't explain how a client
can check that the second responder is acting on behalf of the first CA.
I.e. it may chain to a trust anchor, allowing you to verify the signature on
the OCSP response, but how do you know that the original CA actually
authorised this second responder to provide status information on the first
responder's certificate? 

If you are happy to live without this check then this can work, however I
have not really seen this method actual used (probably because it introduces
more complexity than the benefit it offers).  

The main method I have seen is the use of CRLs (e.g. Adobe CDS certificates
generally use this to verify the OCSP responder certificate status, or use
the no-check option). 

The other approach I have seen is the IdenTrust one with OCSP responder
hierarchies, but this is one where even the first responder is not certified
by the CA for which it responds, so doesn't apply to scenario described in
the original email. 

Regards,
LK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Johannes Merkle
Sent: 25 November 2008 17:47
To: Mauricio Balassiano
Cc: [email-masked]
Subject: Re: OCSP Responder Status

Mauricio,

> checked considering that OCSP No Check extension is not an option ?

An alternative could be another OCSP-Repsponder specified in the first OCSP
responders certificate. For establishing
trust in this second responder, there are the three option mentioned in RFC
2560:
- It uses the CA signing key to sign the OCSP responses (
- It's certificate has also been issued by the CA that issued the
certificate of the first responder. This only
transfers the problem to the second responder
- It's certificate has been issued by another CA, e.g. a root CA. In this
case, the clients must be locally configured
to trust the responders replies.

At the top level of this OCSP hierarchy you will face the problem that
unless you are willing to trust the top-level
responder's certificate without revocation checking (e.g. by using OCSP No
Check), or to use a CA key to sign the
top-level OCSP responses, you must switch to CRLs. I agree that this in not
satisfactory in many circumstances.

For CRLs you'll face a similar problem at the top of the "CRL hierarchy": RP
have to trust the top level CRL signer
without revocation checking. But if you are not willing to issue directs
CRLs (e.g. because the root CA is operated
offline and you wish to avoid daily access to it) then your top level CRL
signer will constitute a kind of second trust
anchor, at least with respect to revocation status checking.

Johannes

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 25 Nov 2008 10:11:53 -0500

You have to careful regarding the third option of trust: "- It's
certificate has been issued by another CA, e.g. a root CA. In this case,
the clients must be locally configured to trust the responders replies."

Some of the widely deployed OCSP clients interpret the local policy
option in RFC 2560 to simply mean explicitly trusted Responder.  Thus,
Responder certificate signed by Root will not work for checking the
status of certificates issued by some other CA.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Johannes Merkle
Sent: Tuesday, November 25, 2008 8:47 AM
To: Mauricio Balassiano
Cc: [email-masked]
Subject: Re: OCSP Responder Status

Mauricio,

> checked considering that OCSP No Check extension is not an option ?

An alternative could be another OCSP-Repsponder specified in the first
OCSP responders certificate. For establishing
trust in this second responder, there are the three option mentioned in
RFC 2560:
- It uses the CA signing key to sign the OCSP responses (
- It's certificate has also been issued by the CA that issued the
certificate of the first responder. This only
transfers the problem to the second responder
- It's certificate has been issued by another CA, e.g. a root CA. In
this case, the clients must be locally configured
to trust the responders replies.

At the top level of this OCSP hierarchy you will face the problem that
unless you are willing to trust the top-level
responder's certificate without revocation checking (e.g. by using OCSP
No Check), or to use a CA key to sign the
top-level OCSP responses, you must switch to CRLs. I agree that this in
not satisfactory in many circumstances.

For CRLs you'll face a similar problem at the top of the "CRL
hierarchy": RP have to trust the top level CRL signer
without revocation checking. But if you are not willing to issue directs
CRLs (e.g. because the root CA is operated
offline and you wish to avoid daily access to it) then your top level
CRL signer will constitute a kind of second trust
anchor, at least with respect to revocation status checking.

Johannes

---

From: "Liaquat Khan" <[email-masked]>
Date: Tue, 25 Nov 2008 21:59:37 +0400

See below

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Timothy J. Miller
Sent: 25 November 2008 21:18
To: Liaquat Khan
Cc: 'Johannes Merkle'; 'Mauricio Balassiano'; [email-masked]
Subject: Re: OCSP Responder Status

> authorised this second responder to provide status information on the
first

That's what client configuration control is for.  :)  That's the whole 
point of the trusted responder model--trust in that responder is 
established out-of-band (i.e., not part of the OCSP protocol).

[LK:] :-) of course anything is possible with configuration but the
situation can become quite complex for even administrators to follow,
especially if multiple CAs are being handled.  E.g. our ARP-OCSP client
supports the capability to use AIA extension to locate responders and also
locally configured responder addresses, with the order of which method is to
be used being configurable.   There is also possibility to configure
separate trust anchor sets per CA etc, so that it can be controlled which
CAs trust which responders. Only issue is that generally speaking no one
really uses these advanced features and instead opts for simpler models
(CRLs or no-check).   

> more complexity than the benefit it offers).  

The DoD OCSP service uses the trusted responder model.  It's a real PITA 
to manage; you have to make sure all the RPs are properly configured. 
Key changing under this model is even worse; the hoops we had to jump 
through were seriously sick.

We're now migrating to the CA designated model.  The CA-issued OCSP 
signing certs will be short-lived certs with longer-lived keys (IIRC, 30 
day cert life with renewal allowed for some period of time).

[LK:] OK sounds interesting, so responder cert will have "no-check" option
and lifetime of 30 days.  Sounds like quite a long lifetime for a
certificate which is supposed to be short-lived :-). 
  
-- Tim

---

From: "Timothy J. Miller" <[email-masked]>
Date: Tue, 25 Nov 2008 11:17:54 -0600

-- Tim