RE: OCSP Algorithm Agility

"Santosh Chokhani" <chokhani@orionsec.com> Tue, 09 October 2007 16:23 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 1IfHrk-0001R5-KD for pkix-archive@lists.ietf.org; Tue, 09 Oct 2007 12:23:28 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfHra-00044A-6s for pkix-archive@lists.ietf.org; Tue, 09 Oct 2007 12:23:24 -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 l99FG4bh079222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2007 08:16:04 -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 l99FG4it079221; Tue, 9 Oct 2007 08:16:04 -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 l99FG3MR079212 for <ietf-pkix@imc.org>; Tue, 9 Oct 2007 08:16:03 -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: Tue, 09 Oct 2007 08:15:40 -0700
Message-ID: <82D5657AE1F54347A734BDD33637C879096C9ABE@EXVS01.ex.dslextreme.net>
In-Reply-To: <2788466ED3E31C418E9ACC5C316615570536E3@mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: OCSP Algorithm Agility
thread-index: Acf8l4NIxZexIh9rTveKgrEJmUDxVQAAJZEAAlba1eAAAH/7QAEC+OtgACFXyuA=
References: <82D5657AE1F54347A734BDD33637C8790966180C@EXVS01.ex.dslextreme.net> <2788466ED3E31C418E9ACC5C316615570536E3@mou1wnexmb09.vcorp.ad.vrsn.com>
From: Santosh Chokhani <chokhani@orionsec.com>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, ietf-pkix@imc.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l99FG3MR079214
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: 20f22c03b5c66958bff5ef54fcda6e48

The OCSP and SCVP can transition to stronger algorithms any time they
want.

The OCSP can take their clue from the CA or the certID field to decide
the hashing algorithm.  When multiple certID is present, OCSP can take
low water mark of these.

SCVP is no different than a client in terms of validating a path.  In
terms of signing a response, it can take the low water mark of the
hashing algorithms in the certificate chain.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]
On Behalf Of Hallam-Baker, Phillip
Sent: Monday, October 08, 2007 7:27 PM
To: Santosh Chokhani; Andrews, Rick; ietf-pkix@imc.org
Subject: RE: OCSP Algorithm Agility


The objective here is to overcome a real deployment obstacle that
creates a lockstep issue when use of stronger algorithms is attempted.

The CA cannot issue a certificate that employs a new algorithm until it
is known that all clients that might rely on the certificate are capable
of processing the new certificate. Requiring lockstep updates to the
OCSP and SCVP infrastructure to be made at the same time renders
transition to stronger algorithms a much lengthier and much less
practical proposition.


> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org 
> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani
> Sent: Saturday, October 06, 2007 4:12 PM
> To: Andrews, Rick; ietf-pkix@imc.org
> Subject: RE: OCSP Algorithm Agility
> 
> 
> Rick,
> 
> SCVP or other intermediaries are red herring.  Whoever 
> processes the certificate processes the revocation 
> information for that certificate.
> It does not change the following:
> 
> 1.  There is no security benefit in using a stronger 
> algorithm for OCSP
> response than for the certificate in question.   Neither, there is any
> benefit from interoperability viewpoint for these two to be different.
> 
> 2.  If the OCSP Responder does not get a CRL, it can use the 
> same mechanism to get the hashing algorithm used as it uses 
> to get the revocation information. 
> 
> -----Original Message-----
> From: Andrews, Rick [mailto:RAndrews@verisign.com]
> Sent: Wednesday, October 03, 2007 3:29 PM
> To: Santosh Chokhani; ietf-pkix@imc.org
> Subject: RE: OCSP Algorithm Agility
> 
> Santosh,
> 
> Sorry for the long delay in responding - travel and vacation.
>  
> Not all OCSP responders work from CRLs, so they won't take 
> their cue from the CRL. Nor should they take their cue from 
> the signature on the cert in question, I believe. Let me try 
> to restate my argument in a different way.
>  
> With SCVP delegated path validation, the client requesting a 
> cert's status from an OCSP responder will be different from 
> the client at the other end of the SSL connection. Those two 
> clients may have very different capabilities in terms of 
> supported signature and hash algorithms. It's not realistic 
> to expect that all SSL clients, all SCVP servers, and all CAs 
> will be able to upgrade in lockstep to new algorithms as they 
> are developed. Allowing the OCSP client and server to 
> negotiate a mutually-acceptable set of algorithms is 
> essential to the deployment of newer, stronger algorithms.
>  
> Likewise, companies that run large OCSP responders may wish 
> to gradually move to ECC-based signatures for all their OCSP 
> responses, even those for certs with RSA or DSA keys, because 
> ECC signatures are cheaper to produce. If algorithm agility 
> is added to OCSP, those companies can gradually achieve the 
> move to ECC without disrupting the installed base of OCSP 
> clients that don't support ECC.
>  
> -Rick Andrews 
> 
> > -----Original Message-----
> > From: owner-ietf-pkix@mail.imc.org
> > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani
> > Sent: Friday, September 21, 2007 2:45 PM
> > To: Paul Hoffman; Stephen Kent; ietf-pkix@imc.org
> > Subject: RE: OCSP Algorithm Agility
> > 
> > 
> > Paul,
> > 
> > Here are my views on this.
> > 
> > The client should be first asking for the algorithm suite 
> that signed 
> > the certificate in question.  There is no need for the 
> client to ask 
> > for anything stronger.  The client can ask for stronger suites as 
> > secondary, if client has them.
> > 
> > In the scenario you cite, the Responder certificate will 
> not include 
> > RSA with SHA 1 any longer.  So, client will know that 
> Responder only 
> > supported his second choice and he should be ok with it.
> > 
> > -----Original Message-----
> > From: owner-ietf-pkix@mail.imc.org
> > [mailto:owner-ietf-pkix@mail.imc.org]
> > On Behalf Of Paul Hoffman
> > Sent: Friday, September 21, 2007 4:39 PM
> > To: Stephen Kent; ietf-pkix@imc.org
> > Subject: RE: OCSP Algorithm Agility
> > 
> > 
> > At 2:07 PM -0400 9/21/07, Stephen Kent wrote:
> > >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.
> > 
> > Imagine the list of algorithms is RSA-with-SHA1 first and
> > DSA-with-SHA1 second. How does your negotiation work? The 
> client asks 
> > for this message to be signed with RSA-with-SHA1.
> > But the server knows that RSA-with-SHA1 has been 
> compromised since it 
> > got that certificate from the CA. What does the server say to the 
> > client to indicate that it only wants to sign with 
> DSA-with-SHA1? What 
> > prevents Mallory from saying the same thing to the client?
> > 
> > --Paul Hoffman, Director
> > --VPN Consortium
> > 
> > 
> > 
> 
>