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

From: "Santoni Adriano" <[email-masked]>
Date: Tue, 4 Apr 2006 08:40:21 +0200

Thanks for all opinions.
 
Of course my posting was a little bit mischievous...
 
I was not suggesting that checking an OCSP responder's certificate is not needed, in the more general case. And I was not seeking explanations on what to check and how. The RFCs are not being questioned, here.
 
What I have in mind is a very specific context, wherein I am still convinced checking the OCSP responder certificate is a largely redundant operation, if it was not for the risk of "man in the middle" or DNS poisoning attacks.
 
Assume the relying party runs a web server, controlling access to protected areas with SSL client auth. The server handles many transactions per unit time, and check the revocation status of all client certificates via OCSP, getting the responder's URL from the AIA extension. Also assume the server only accepts SSL client certs from a small number of well know CAs, all following very similar policies. And further assume each of those CAs run its own OCSP responder, closely following the applicable RFCs.
 
Under the above conditions, I think the only real risk is "man in the middle" or DNS poisoning.
 
In case of an OCSP responder's key compromise, it is much more likely the owning CA shuts down its OCSP service momentarily, while renewing the compromised key and certificate.
 
Adriano

	-----Messaggio originale-----
	Da: Matt Cooper [mailto:[email-masked]] 
	Inviato: lunedì 3 aprile 2006 21.34
	A: Santoni Adriano; [email-masked]
	Oggetto: RE: Verify or not verify (OCSP responders): that is the question

	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. 

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

Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei suoi allegati è 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.