RE: OCSP Algorithm Agility

"Santosh Chokhani" <chokhani@orionsec.com> Mon, 08 October 2007 00:15 UTC

Return-path: <owner-ietf-pkix@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IegHD-0000b3-Vg for pkix-archive@lists.ietf.org; Sun, 07 Oct 2007 20:15:15 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IegH8-0004rj-MP for pkix-archive@lists.ietf.org; Sun, 07 Oct 2007 20:15:11 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l97NJK5V077374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Oct 2007 16:19:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l97NJKXi077373; Sun, 7 Oct 2007 16:19:20 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l97NJJuM077365 for <ietf-pkix@imc.org>; Sun, 7 Oct 2007 16:19:20 -0700 (MST) (envelope-from chokhani@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: OCSP Algorithm Agility
Date: Sun, 07 Oct 2007 16:18:56 -0700
Message-ID: <82D5657AE1F54347A734BDD33637C879096618AD@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: OCSP Algorithm Agility
thread-index: Acf8g+lSm4OdXAknTt2BXwIpRJkp9QAAN7VQAyzHXAA=
References: <2788466ED3E31C418E9ACC5C3166155703DF57@mou1wnexmb09.vcorp.ad.vrsn.com> <p0624080ec319a977190d@[165.227.249.200]> <p0624050dc319b62dedaf@[128.89.89.71]>
From: Santosh Chokhani <chokhani@orionsec.com>
To: Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l97NJKuM077368
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d

Steve,

Another way to do this securely is to let the client signal in the hash
algorithm field of the certID.  This will not be vulnerable to MITM
attack since the client can check the hashing algorithm used to sign the
response matches the hashing algorithm in the certID field.

It also provides security since if an hashing algorithm is good enough
for certificate, it is good enough for OCSP response.

It provides interoperability for the client since the client has to have
the hashing algorithm for certificate signature verification.
 
-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]
On Behalf Of Stephen Kent
Sent: Friday, September 21, 2007 2:08 PM
To: ietf-pkix@imc.org
Subject: RE: OCSP Algorithm Agility


Folks,

How about defining an extension to be included in the cert issued to 
an OCSP responder by a CA.  The extension would have an ordered list 
of algorithms (hash and signature if we want to address more than the 
hash agility issue) accepted by the OCSP responder.  An OCSP client 
can use this info to determine what is the "best" algorithm (or alg 
pair) that it and the responder share. The combination of this 
extension and an OCSP negotiation procedure will allow the client to 
detect MITM downgrade attacks. In fact, if the client acquires the 
responder's cert prior to making a request, there would not even be a 
need for real negotiation, since the client would know what alg to 
request in a response.

Steve