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

From: "Santoni Adriano" <[email-masked]>
Date: Mon, 3 Apr 2006 18:59:30 +0200

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: "Michael Myers" <[email-masked]>
Date: Mon, 3 Apr 2006 11:15:27 -0800

Verify or not verify (OCSP responders): that is the questionAdriano,

The digital signature on an authoritative OCSP response should be traced
back to a trusted public key in the same fashion as the digital signature on
an equivalent CRL.

Mike
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Santoni Adriano
  Sent: Monday, April 03, 2006 9:00 AM
  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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 3 Apr 2006 14:55:20 -0400

At 6:59 PM +0200 4/3/06, Santoni Adriano wrote:
>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
>

The info in the AIA extension is just a URL or 
similar pointer. It provides no secure binding to 
the cert of a purported OCSP server. If you have 
multiple TAs configured, then a cert traceable to 
one of them could be labelled as suitable for 
OCSP responses (via the KeyUsage extension) and 
with a MITM attack, you could be spoofed.

Steve

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 03 Apr 2006 13:07:13 -0400

> Hello all,

Hi,

> I would like to gather some opinions on the following: does it really 
[...]
> certificate of the OCSP responder referenced in the AIA within the 

The AIA carries only informations of the URL of the OCSP responder, nothing
more. Therefore the OCSP certificate could be revoked (because it has been
compromised). Man in the middle or DNS poisoning attacks could be used to
redirect your application to the fake OCSP responder which uses the compromised
secret key.

> piece if information within it should also be automatically reliable…. 
> or not?

As I said, the URL might be reliable (well, extensions has the problem that
are too static, so if the OCSP has been moved to a different address, you'll
still use the old one present in the EE certificate...) but the server
might not, so you should check its validity.

> put the unreliable AIA in the end-user certificate?

Trust in CA and certificate extension are two separate matters because of the
reasons I reported above: there could be different reasons for the AIA to be
still valid while the certificate's server is not.

Moreover in case the OCSP responder has been moved to a different URL it is
REALLY unlikely that a CA would revoke and re-issue all the valid certificates
because the AIA contents is no more aligned. It should, but it usually won't
happen (and this holds for all extensions in the certificate which are not
felt to be very important).

Still I understand that to verify the OCSP certificate you would need to use a
validation service, and most likely you'll end up by using a CRL. But if you need
a CRL then why using OCSP ?

Practice is usually quite different from theory, and this is the case here.
IMHO to overcome this chicken-and-egg problem, my understanding is that usually OCSP
responder certificate should use the id-pkix-ocsp-nocheck extension to allow clients
to trust the responder certificate for the entire validity period. This could be
dangerous if the key-pair is compromised, though.
Anyway if the extension is not present, in order to verify the signature of the
OCSP response, you should verify the responder's certificate up to the root or a
trust anchor.

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 062                        Work Phone: +1 (603) 646-9226
--o------------------------------------------------------------------------