RE: OCSP Algorithm Agility

Stefan Santesson <stefans@microsoft.com> Tue, 18 September 2007 22:05 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 1IXlCM-0001mn-6Z for pkix-archive@lists.ietf.org; Tue, 18 Sep 2007 18:05:38 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXlC9-0005Cp-Bk for pkix-archive@lists.ietf.org; Tue, 18 Sep 2007 18:05:32 -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 l8IL9QHx036259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2007 14:09:26 -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 l8IL9QdB036258; Tue, 18 Sep 2007 14:09:26 -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 smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8IL9NqH036250 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-pkix@imc.org>; Tue, 18 Sep 2007 14:09:25 -0700 (MST) (envelope-from stefans@microsoft.com)
Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.177.2; Tue, 18 Sep 2007 22:09:22 +0100
Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.50]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Tue, 18 Sep 2007 22:09:22 +0100
From: Stefan Santesson <stefans@microsoft.com>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, pkix <ietf-pkix@imc.org>
Date: Tue, 18 Sep 2007 22:09:20 +0100
Subject: RE: OCSP Algorithm Agility
Thread-Topic: OCSP Algorithm Agility
Thread-Index: Acf0YQuLnpqNTtmVSEemXtokNuJtUwAAJKlAADhP/rQBN68QwAAFd1pQ
Message-ID: <A15AC0FBACD3464E95961F7C0BCD1FF006A264FED7@EA-EXMSG-C307.europe.corp.microsoft.com>
References: <2788466ED3E31C418E9ACC5C31661557C74B@mou1wnexmb09.vcorp.ad.vrsn.com>
In-Reply-To: <2788466ED3E31C418E9ACC5C31661557C74B@mou1wnexmb09.vcorp.ad.vrsn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_A15AC0FBACD3464E95961F7C0BCD1FF006A264FED7EAEXMSGC307eu_"
MIME-Version: 1.0
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: 1ed37b243475b9c4ffb6a3f90050819d

Phil,

Good that you bring this subject on the table again. We have agreed for quite some time that something needs to be done.
Nothing has happened in the absence of any volunteers to actually do the work.

I think it would be great if you want to formalize your proposal in an ID. In the end we need to develop any solution we choose as a PKIX document, if our ADs give us their blessing.
It would be great to know if we now have enough people interested to actually contribute to such an effort.


Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Hallam-Baker, Phillip
Sent: den 18 september 2007 11:53
To: pkix
Subject: OCSP Algorithm Agility

Looking at places where we currently use SHA-1 it appears that there will soon be a need to support SHA-256 in OCSP.

In particular we need a mechanism to allow the requestor to state which algorithms they can accept from the responder. I did a sketch of a scheme (see below).

The question is how best to get this processed. Algorithm agility is one of the issues that is blocking advance of OCSP on the standards track so if this was the only issue that was blocking advancement it would perhaps make sense to rev the OCSP RFC.

Alternatively it might be considered preferable to address algorithms agility 'across the board'. Although the only other protocol that is analagous is SCVP. I don't think the mechanism specified there translates to OCSP.

So I was thinking that a good place to start was probably to submit some variation of the following as a personal ID:
The extension would need to be something like

id-pkix-ocsp-algorithmselectors   OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }

AlgorithmSelectors ::= SEQUENCE OF AlgorithmSelectorEntry

AlgorithmSelectorEntry ::= SEQUENCE {
    SignatureAlgorithm   [0] OBJECT IDENTIFIER OPTIONAL,
    DigestAlgorithm   [1] OBJECT IDENTIFIER OPTIONAL,
    }

The responder SHOULD sign the reponse with a signature algorithm and digest algorithm pair that match one ot the following criteria:

1) The Signature and Digest algorithm both match an algorithm selector entry exactly.

or

2) The Signature Algorithm used matches an algorithm selector entry where only the Signature Algorithm OID is specified and the digest algorithm matches an algorithm selector entry where only the Digest Algorithm OID is specified.


So for example a requestor can stipulate that they will accept any combination of RSA-1024, RSA-2048, SHA-1 and SHA-256 or DSA2 with SHA-256 as follows:

{SignatureAlgorithm   RSA-1024}
{SignatureAlgorithm   RSA-2048}
{DigestAlgorithm      SHA-1 }
{DigestAlgorithm      SHA-256  }
{SignatureAlgorithm   DSA2, DigestAlgorithm      SHA-1 }

The rationale here is that in most cases the signature and digest algorithms are 'mix and match'. But sometimes they are not, in particular if specific signature hardware is to be used.

I note that SCVP does something rather different but I don't see how the scheme specified there would fit OCSP.