Subject: RE: Verify or not verify (OCSP responders): that is the question

From: "Dave Engberg" <[email-masked]>
Date: Mon, 3 Apr 2006 14:25:56 -0400

In a delegated OCSP trust model, you need to confirm that the Responder is
currently trusted by the CA for issuing its responses.
 
First, you confirm that the response was signed by a Responder which has a
certificate signed by the CA with the OCSP-Signing Extended Key Usage flag.
If you don't perform this check, an attacker could intercept client requests
and easily trick you to accepting false responses.  The fact that you ask a
"correct" URL doesn't provide any security protection on the Internet.
 
Second, you want to know whether the Responder's certificate is currently
acceptable.  In theory, you could validate this by performing a revocation
check on the Responder's cert, but this leads to a nasty chicken-and-egg
problem:  Who do you ask about the status of the Responder's cert?  RFC 2560
permits a relying party to skip the revocation check on a Responder's cert
if the CA added the "pkix-nocheck" extension.  Many mature PKIs issue
Responder certs with this extension.  These certificates are issued with a
short "lifetime" so that they will naturally expire if they ever need to be
replaced.

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santoni Adriano
Sent: Monday, April 03, 2006 1:00 PM
To: [email-masked]
Subject: Verify or not verify (OCSP responders): that is the question

Hello all, 

I would like to gather some opinions on the following: does it really makes
any sense - from a pratical point of view - to verify an OCSP responder's
certificate when its address is taken from the AIA extension of an end-user
certificate whose issuing CA is one of my trust points?

I mean, if I am already trusting a certain CA to issue reliable (and of
course properly coded) certificates, why should I bother to verify the
certificate of the OCSP responder referenced in the AIA within the end-user
certificate? 

If I have (well, if my application has) already verified that the end-user
certificate under examination is reliable, then every single piece if
information within it should also be automatically reliable.. or not?

Viewing the issue from the opposite side: if the OCSP responder's
certificate was not reliable, how could I keep on trusting the CA that put
the unreliable AIA in the end-user certificate?

I think the reasoning applies equally to OCSP responders managed by the CA
itself or by any other TTP, regardless. 

TIA for all opinions. 

Adriano 

*******************Internet Email Confidentiality Footer******************* 

Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei suoi
allegati e vietato e potrebbe costituire reato. Se ha ricevuto per errore il
presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una
comunicazione al riguardo e provvedesse nel contempo alla distruzione del
messaggio stesso e dei suoi eventuali allegati. Le dichiarazioni contenute
nel presente messaggio nonche' nei suoi eventuali allegati devono essere
attribuite esclusivamente al mittente e non possono essere considerate come
trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. ACTALIS
S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni,
modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited
and could constitute an offence. If you are not the intended addressee
please advise immediately the sender by using the reply facility in your
e-mail software and destroy the message and its attachments. The statements
and opinions expressed in this e-mail message are those of the author of the
message and do not necessarily represent those of ACTALIS S.p.A. Besides,
The contents of this message shall be understood as neither given nor
endorsed by ACTALIS S.p.A.. ACTALIS S.p.A. does not accept liability for
corruption, interception or amendment, if any, or the consequences thereof.

---

From: "Matt Cooper" <[email-masked]>
Date: Mon, 3 Apr 2006 12:33:35 -0700

Adriano,
 
It is true that you know the AIA is the one placed in the cert by the CA
because you verified the CA signature on the cert.  You also know the
OCSP response was received intact because you verified the signature on
the response using the OCSP responder cert.
 
Now, how do you know the OCSP responder certificate is the right one?
Just because you connected to the AIA URL and got a response?  What if I
poison your DNS server?  What if I inject an OCSP response in your web
proxy cache?
 
The only way we can know if the OCSP responder certificate is valid is
to verify it and check its' properties.  (e.g., does it have OCSP
signing asserted?  etc.)
 
This is exactly the same logic you apply to CRLs.  You can't assume that
just because you download a CRL from the CRL DP that it must be valid.
You verify the signature and the properties of the CRL according to the
standards.  (e.g., is this a full or partial CRL? If it is partial, did
I get the right part? are the this and next update values ok? etc)
 
-Matt

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santoni Adriano
Sent: Monday, April 03, 2006 1:00 PM
To: [email-masked]
Subject: Verify or not verify (OCSP responders): that is the question

Hello all, 

I would like to gather some opinions on the following: does it really
makes any sense - from a pratical point of view - to verify an OCSP
responder's certificate when its address is taken from the AIA extension
of an end-user certificate whose issuing CA is one of my trust points?

I mean, if I am already trusting a certain CA to issue reliable (and of
course properly coded) certificates, why should I bother to verify the
certificate of the OCSP responder referenced in the AIA within the
end-user certificate? 

If I have (well, if my application has) already verified that the
end-user certificate under examination is reliable, then every single
piece if information within it should also be automatically reliable....
or not?

Viewing the issue from the opposite side: if the OCSP responder's
certificate was not reliable, how could I keep on trusting the CA that
put the unreliable AIA in the end-user certificate?

I think the reasoning applies equally to OCSP responders managed by the
CA itself or by any other TTP, regardless. 

TIA for all opinions. 

Adriano 

*******************Internet Email Confidentiality
Footer******************* 

Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei
suoi allegati e vietato e potrebbe costituire reato. Se ha ricevuto per
errore il presente messaggio, Le saremmo grati se ci inviasse, via
e-mail, una comunicazione al riguardo e provvedesse nel contempo alla
distruzione del messaggio stesso e dei suoi eventuali allegati. Le
dichiarazioni contenute nel presente messaggio nonche' nei suoi
eventuali allegati devono essere attribuite esclusivamente al mittente e
non possono essere considerate come trasmesse o autorizzate da ACTALIS
S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei
confronti del destinatario o di terzi. ACTALIS S.p.A. non si assume
alcuna responsabilita' per eventuali intercettazioni, modifiche o
danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is
prohibited and could constitute an offence. If you are not the intended
addressee please advise immediately the sender by using the reply
facility in your e-mail software and destroy the message and its
attachments. The statements and opinions expressed in this e-mail
message are those of the author of the message and do not necessarily
represent those of ACTALIS S.p.A. Besides, The contents of this message
shall be understood as neither given nor endorsed by ACTALIS S.p.A..
ACTALIS S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof.